ZFX + Developia

Nvidias Kepler-GPUs nicht vollständig zu DirectX 11.1 kompatibel:
http://www.heise.de/newsticker/meldung/ ... 54119.html

meh.

Keine UAVs außerhalb von Pixel Shaders? Ich dachte via GL Extension konnte das schon die 500-Serie in Geometry Shaders. Lehren? OpenGL langsam alternativlos? Neue Technik frühestens in 2-3 Jahren?

Ja das schockiert mich auch, denn das war wohl von vornherein eine eher künstliche Einschränkung und das wäre für mich wohl eines der wichtigsten D3D11.1 "Features" (Goodbye Stream Output Stage). Ich würde aber mal davon ausgehen, dass viele dieser Dinge eher ein Driver Issue sind, als eine tatsächliche hardwareseitige Einschränkung...

Btw: Was genau ist da mit "UAV-only rendering" gemeint? Rendern ohne Rendertarget nur mit UAVs, tu ich in meiner aktuellen Anwendung irgendwie schon rein in D3D11 seit längerer Zeit...

dot hat geschrieben:Ja das schockiert mich auch, denn das war wohl von vornherein eine eher künstliche Einschränkung und das wäre für mich wohl eines der wichtigsten D3D11.1 "Features" (Goodbye Stream Output Stage). Ich würde aber mal davon ausgehen, dass viele dieser Dinge eher ein Driver Issue sind, als eine tatsächliche hardwareseitige Einschränkung...

Hoffen wir es, ohne ordentliches Dynamic Dispatch oder wahlsweise ordentlichen UAV-Access wird Innovation die nächsten Jahre echt mühsam.

dot hat geschrieben:Btw: Was genau ist da mit "UAV-only rendering" gemein? Rendern ohne Rendertarget nur mit UAVs, tu ich in meiner aktuellen Anwendung irgendwie schon rein in D3D11 seit längerer Zeit...

Auch gerade gestutzt, es bezieht sich wohl auf die Möglichkeit, auch ohne Render Targets einen bestimmten Sample Count zu erzwingen.

Naja, also ich kann mir jetzt echt keinen Grund vorstellen, wieso z.B. Partial constant buffer updates technisch nicht realisierbar sein sollten, von da her würd ich mal ziemlich sicher davon ausgehen, dass das rein am Driver liegt. Ich denk, das sollte eigentlich selbst auf D3D10 Hardware kein Problem sein...

Das ist ein ziemlicher Schlag ins Kontor; ich hoffe mal auch, dass das als Treiberupdate nachgeliefert wird; zumindest sehe ich gerade keine konzeptionellen Schwierigkeiten darin.

dot hat geschrieben:wieso z.B. Partial constant buffer updates technisch nicht realisierbar sein sollten

Die werden ja gerade unterstützt. Auch bezieht sich 16-faches MSAA bestimmt nicht nur auf Direct3D.

eXile hat geschrieben:

dot hat geschrieben:wieso z.B. Partial constant buffer updates technisch nicht realisierbar sein sollten

Die werden ja gerade unterstützt. Auch bezieht sich 16-faches MSAA bestimmt nicht nur auf Direct3D.

Oh, lol, falsch geschaut...

Auch fällt mir gerade auf: Man hätte das schon im März wissen können.

Und die Feature-Liste liest sich komplett gleich. Also komplett Wort-für-Wort gleich. Als ob das ein Marketing-Typ kopiert hätte. Auch: Was soll überhaupt der „Orthogonal Line Rendering Mode“ sein? Das klingt fast so, als ob The Onion das geschrieben hätte.

WTF passiert eigentlich mit DXGI, wenn man in ein minimiertes Fenster zeichnet?! Bei mir dreht die GPU auf volle Pulle auf und das System reagiert nur noch mit einer Sekunde Verzögerungen auf alles. Wenn ich es dann nach 30 Sekunden endlich geschafft habe, das Fenster wiederherzustellen, stabiliert sich das langsam. Hm.

Krishty hat geschrieben:WTF passiert eigentlich mit DXGI, wenn man in ein minimiertes Fenster zeichnet?! Bei mir dreht die GPU auf volle Pulle auf und das System reagiert nur noch mit einer Sekunde Verzögerungen auf alles. Wenn ich es dann nach 30 Sekunden endlich geschafft habe, das Fenster wiederherzustellen, stabiliert sich das langsam. Hm.

Sicher, dass es die GPU ist, und nicht die CPU ungebremst mit Present() == Occluded o.ä. volle Pulle durchheizt?

Es gibt kein Occluded mehr. Seit Vista SP1 habe ich es nicht mehr geschafft, diesen Present State zu reproduzieren.

Mehr zu Kepler und dem Direct3D-11.1-Drama:

Timothy Lottes auf https://twitter.com/TimothyLottes/status/271335581819224065 hat geschrieben:Target Independent Raster (for 2D font rendering) is a required 11.1 feature. DX feature level 11.1 might be "all or nothing".

Es kann also an politischen Gründen liegen. Weil ein Teil-Feature von Direct3D 11.1 nicht unterstützt wird, wird eben das ganze Feature-Level nicht unterstützt. Bis das jemand mal getestet hat, sage ich aber nichts definitives dazu. Nur leider hat niemand (genau wie ich) dazu Zeit.

http://stats.grok.se/de/latest90/Umschalttaste
WTF is wrong with 9-11

Hat es irgendjemand von euch schonmal geschafft, __declspec(noalias) eine Wirkung nachzuweisen?

Dass es unter x64 wirkungslos ist (wie auch __restrict und __declspec(restrict)) ist mir schon länger bekannt. Ich habe aber dennoch interessehalber ein Experiment gestartet – nämlich mit externen Funktionen:

Gemäß der MSDN wird __declspec(noalias) eingesetzt um dem Compiler zu verklickern, dass eine Funktion nicht den globalen Programmzustand verändert, sondern nur ihre direkten Parameter. Man deklariert damit also eine Pure Function.

Auch die WinAPI bietet solche Pure Functions an (wenn auch in geringer Zahl). Beispiele sind QueryPerformanceFrequency(), das für die Systemlaufzeit stets dieselbe Zahl zurückgibt; oder GetProcessHeap(), das für die Prozesslaufzeit stets dasselbe Handle zurückgibt.

Weil die Funktionen extern sind (genauer gesagt: extern "C" __declspec(dllimport)), hat der Compiler keine Möglichkeit, festzustellen, dass sie wirkungsfrei sind. Der folgende Text:
    HeapAlloc(GetProcessHeap(), 0, 123);
    HeapAlloc(GetProcessHeap(), 0, 123);
bewirkt also vier Funktionsaufrufe, weil der Compiler nicht feststellen kann, dass GetProcessHeap() beide Male dasselbe Handle zurückgibt.

Ich wollte also clever sein und habe GetProcessHeap() mit __declspec(noalias) dekoriert; in der Hoffnung, dass nun nur noch drei Funktionen aufgerufen würden.

Arschlecken! Visual C++ 2012 x86 kümmert sich einen Scheiß darum. x64 konnte ich nicht testen, weil ich hier keine entsprechende CPU habe.

Also nochmal: Hat irgendjemand diesem Schlüsselwort irgendwann mal eine Wirkung nachgewiesen?

MSDN hat geschrieben:The visible global state is the set of all data that is not defined or referenced outside of the compilation scope, and their address is not taken.

;)

Wow. Also wieder ein Schlüsselwort für den Popo.

__declspec(dllimport) bewirkt übrigens auch nichts; ich werde den Thread entsprechend aktualisieren.

align, allocate, noinline, noreturn, nothrow (meist überflüssig, weil man das auch anders ausdrücken kann), novtable, selectany und thread sind damit die einzigen __declspecs, die in nativem C++ eine Wirkung haben. Der Rest sind Plazebos.

Inwiefern bewirkt __declspec(dllimport) nichts!?

Ups: Für Funktionen bewirkt es nichts. Sorry.

Das Special-Member-Function-Chaos durch den schleichenden Übergang von C++03 zu C++11 könnte wirklich nicht mehr größer sein. Das Fehlen von implizit definierten Move-Konstruktoren und Move-Assignment-Operatoren führt dazu, dass diese IMMER von Hand deklariert werden müssen. Die (zukünftigen) Regeln von C++11 führen dazu, dass dann auch Copy- und Assignment-Operatoren von Hand deklariert werden müssen. Das Fehlen von default führt dazu, dass all diese Funktionen auch noch vollständig ausgeschrieben werden müssen.

Fazit: Es gibt im Moment effektiv überhaupt keine implizit definierte Kopier- und Verschiebefunktionalität. All mein Code, der im Moment aus Bequemlichkeit nur Movement definiert, wird in Zukunft mit einem C++11-konformen Compiler kaputt sein, weil er dann Kopien vollständig verbietet. Wollte ich ihn jetzt schon konform schreiben, würde er vor Redundanz explodieren.

Nachtrag: Um trotzdem weiterhin von impliziter Kopierfunktionalität Gebrauch machen zu können, hilft ein Präprozessormechanismus, der konkret auf diese desaströse Situation zugeschnitten ist. Da die MS-Compiler, die noch keine impliziten Move-Konstruktoren kennen, momentan genauso wenig die Regeln zur Abschaltung der impliziten Kopierfunktionalität bei explizit definierten Move-Konstruktoren kennen, lässt sich für diese Compiler ein Schalter NEED_EXPLICIT_MOVE definieren, der dort die händisch definierte Movefunktionalität aktiviert, diese in zukünftigen konformen Compilern hingegen einfach komplett aus dem Code entfernt (dort wird sie dann durch die impliziten Funktionen ersetzt). Vorsicht ist geboten, dies nicht in Situationen zu tun, in denen auch in Zunkunft keine implizite Movefunktionalität eingefügt wird.

 


 


 


 







 


Falls sich irgendwann nochmal jemand wundert, warum ich alles selber schreibe:

because FUCK YOU

that's why

Sagmal, dieser ganze Move-Kram ist doch neu in C++11, ja? Und verhindert massenweise Objektkopierungen. Gibt es etwas vergleichbares schon in anderen Sprachen, oder kann man C++ jetzt noch effektiver programmieren? Und gibt es Zahlen, in wie weit sich das überhaupt lohnt, also dass eine durchschnittliche Anwendung mit sämtlichen Move-Optimierungen sagen wir 5% schneller wird?

Jonathan hat geschrieben:Gibt es etwas vergleichbares schon in anderen Sprachen, oder kann man C++ jetzt noch effektiver programmieren?

Die meisten Sprachen umgehen das Problem, indem alle Objekte einfach nur per Zeiger (Referenzen) herumgereicht werden. Bei einfachen Zeigerkopien gibt es logischerweise nicht mehr viel zu optimieren, schneller wirds nicht. Dafür brauchen diese Sprachen die gängigen Mechanismen für Shared Ownership, also Garbage Collection, Reference Counting o.ä., und bieten weniger/keine Kontrolle über das Speicherlayout.

Jonathan hat geschrieben:Und gibt es Zahlen, in wie weit sich das überhaupt lohnt, also dass eine durchschnittliche Anwendung mit sämtlichen Move-Optimierungen sagen wir 5% schneller wird?

Wo es auf Performance ankam, hat man diese Kopien in C++03 einfach anderweitig umgangen. Ausgabeparameter via veränderlichen Referenzen/Zeigern, Swaptimization und andere Hässlichkeiten lassen grüßen. Der eigentliche Gewinn von Move Semantics ist die Möglichkeit, Objekte logisch verschieben zu können. Damit lassen sich auch komplexe Objekte ganz einfach per Rückgabewert zurückgeben, Eignerschaft lässt sich an Smart Pointer in Containern übertragen etc. Move Semantics sind also in erster Linie eine elegante Mechanik zur intuitiven Codegenerierung in Fällen, in denen die Sprache zuvor zu umständlichen Umwegen zwang oder ekelhafte Redundanzen wie ptr_container-Wrapper hervorrief.

Eigentlich wollte ich für meinen zwölfjährigen Neffen Minecraft kaufen, weil er zu Weihnachten einen kleinen eigenen Rechner bekommt und sich das Spiel seit Ewigkeiten wünscht. Man sollte meinen, dass das machbar ist. Ist es aber nicht.

Ich muss:
- einen Mojang-Account anlegen, um überhaupt kaufen zu dürfen
- dabei Name, Adresse, EMail und DREI Sicherheitsfragen eingeben
--- mein Neffe hat nichtmal eine EMail-Adresse
--- und jeder Zugriff von einem neuen Rechner muss authentifiziert werden
- und dann soll ich noch einen Spielernamen festlegen
- der sich nie wieder ändern lässt.
- um sich dann bei jedem Start mit EMail-Adresse und Passwort einzuloggen

... bevor man das erste Mal das Spiel starten darf. Was zur Hölle ist in diese Pfeiffen gefahren, dass sie so einen Aufstand wegen einem VERDAMMTEN SPIEL machen?

Schrompf hat geschrieben:Eigentlich wollte ich für meinen zwölfjährigen Neffen Minecraft kaufen, weil er zu Weihnachten einen kleinen eigenen Rechner bekommt und sich das Spiel seit Ewigkeiten wünscht. Man sollte meinen, dass das machbar ist. Ist es aber nicht.

Ich muss:
- einen Mojang-Account anlegen, um überhaupt kaufen zu dürfen
- dabei Name, Adresse, EMail und DREI Sicherheitsfragen eingeben
--- mein Neffe hat nichtmal eine EMail-Adresse
--- und jeder Zugriff von einem neuen Rechner muss authentifiziert werden
- und dann soll ich noch einen Spielernamen festlegen
- der sich nie wieder ändern lässt.
- um sich dann bei jedem Start mit EMail-Adresse und Passwort einzuloggen

... bevor man das erste Mal das Spiel starten darf. Was zur Hölle ist in diese Pfeiffen gefahren, dass sie so einen Aufstand wegen einem VERDAMMTEN SPIEL machen?

Ich rate von einem Kauf ab! Der verkackte Dreckssupport existiert nicht *fluch*! Ich kann nur jedem raten kein Mojang Produkt zu erwerben, denn die kümmern sich um ihre Kunden nicht.

Früher hat man einfach sich einen Account angelegt und per PayPal überwiesen. Das war allerdings vor diesen Mojang-Accounts. Ich hab nichtmal so ein Teil :D

Man meldet sich im Spiel selbst übrigens mit dem Spielernamen an, nicht mit der E-Mail-Adresse.

Andre hat geschrieben:Früher hat man einfach sich einen Account angelegt und per PayPal überwiesen. Das war allerdings vor diesen Mojang-Accounts. Ich hab nichtmal so ein Teil :D

Man meldet sich im Spiel selbst übrigens mit dem Spielernamen an, nicht mit der E-Mail-Adresse.

Das wurde geändert. Mit dem Mojang Account kann man sich nur noch mit Email anmelden. Wer das aber aus irgendwelchen omniösen Gründen aber nicht kann, weil Mojfuck es verkackt hat und auf Supportanfragen nicht reagiert, kann man das Spiel nicht mehr Online spielen.

Biolunar hat geschrieben: Das wurde geändert. Mit dem Mojang Account kann man sich nur noch mit Email anmelden. Wer das aber aus irgendwelchen omniösen Gründen aber nicht kann, weil Mojfuck es verkackt hat und auf Supportanfragen nicht reagiert, kann man das Spiel nicht mehr Online spielen.

Wenn das so weiter geht kann ich ja vielleicht doch noch irgendwann von dem Vorteil meines Alpha-Accounts gebrauch machen, dass ich alle zukünftigen Updates umsonst bekomme. Wenn das erste DLC kommt meine ich :P

Erinnert ihr euch noch an den total lächerlichen Bug, dass VC nicht optimiert, wenn eine Klasse einen Destruktor hat (sogar einen leeren)?

Wie es aussieht, gibt es einen ebenso lächerlichen Weg, das wieder geradezubiegen: Der Klasse einen Konstruktor verpassen!
http://stackoverflow.com/questions/1173 ... -trivial-c

I don't want to live on this planet any more.jpg

Krishty hat geschrieben:Erinnert ihr euch noch an den total lächerlichen Bug, dass VC nicht optimiert, wenn eine Klasse einen Destruktor hat (sogar einen leeren)?

Ja, an diesen Post kann ich mich noch erinnern.
War das nicht sogar so, dass wenn der Destruktor in der Basisklasse virtuell war, und man überschreibt ihn in einer abgeleiteten Klasse mit einem leeren Konstruktor?

Nachdem ich nun eine Stunde damit verbracht habe, mich durch die MSBuild Files von CUDA 4.2 zu wühlen, um ein Gefühl für diese ganze MSBuild-Umgebung zu bekommen, sehe ich langsam ungefähr die Konzepte und Funktionsweise dieses undurchdringlichen Dickichts von XML. Noch immer frage ich mich bei einem großen Teil des Codes, warum dieser überhaupt da ist, aber ich konnte immerhin einige hilfreiche Elemente entdecken, die ich in der offiziellen MSBuild-Referenz überhaupt nicht finde. Fündig wurde ich hier in einem MSBuild-Namespace namens XAMLTypes, der offenbar weitaus vollständiger dokumentiert ist als die XML-Äquivalente. Der Eindruck einer großen Undurchsichtigkeit scheint damit vorerst bestätigt, aber vielleicht bin ich morgen immerhin in der Lage, der Build-Umgebung einfache Dinge wie die Ausführung der vielzähligen Qt-Compiler beizubringen.