ZFX + Developia

kaiserludi hat geschrieben:Wieso poppt eigentlich bei jedem zweiten Handyhersteller beim updaten eine Warnung auf, dass das Device unbrauchbar wird, wenn man es während dem Update vom Rechner trennt?
Haben die alle noch nie was davon gehört, dass es auch sowas wie Stromausfälle oder plötzliche Abstürze gibt?
Kann doch wohl nicht sein, dass man mit dem Gerät dann zum Hersteller muss, ums zu resetten.

Mein Windows Update warnt mich auch immer davor. Ist ja nicht so, dass mein Rechner wichtig wäre. Aber was Microsoft von Produktivanwendern hält, sieht man ja an Windows 8.

BTW: Ich habe gehört, das neue Mac OS X soll auch nicht der Brüller sein. Wenn die zwei so weiter machen, muss Linux gar nicht mehr besser werden, die Konkurrenz erledigt sich einfach von selbst. OpenGL 4.3 sieht jedenfalls recht vielversprechend aus. Angesichts der Tatsache, dass die DirectX-Umgebung derart verbuggt, das SDK praktisch tot und DX 11.1 obendrein schon wieder strikt plattformgebunden ist, wird ein Umstieg auf OpenGL in den nächsten 2 Jahren womöglich ohnehin unumgänglich, API hin oder her.

http://www.heise.de/developer/artikel/C ... 61014.html

Irgendwie beschreiben die hier nur Techniken, die Freepascal schon seit 10 Jahren hat. Plattformunabhängig.

CodingCat hat geschrieben:OpenGL 4.3 sieht jedenfalls recht vielversprechend aus. Angesichts der Tatsache, dass die DirectX-Umgebung derart verbuggt, das SDK praktisch tot und DX 11.1 obendrein schon wieder strikt plattformgebunden ist, wird ein Umstieg auf OpenGL in den nächsten 2 Jahren womöglich ohnehin unumgänglich, API hin oder her.

Also so wie ich das gerade sehe: Sie haben eingesehen, dass der OpenGL-OpenCL-Interop anscheinend Schrott war, und sind jetzt in Richtung Direct3D marschiert. Bindless Textures sind ja nicht neu hinzugekommen, aber das wäre ein Grund, warum man sich über Direct3D ärgern kann. Eine Sache, die du dir aber einhandeln könntest, ist der Umstieg von Bugs, die bei allen GPUs auftauchen, zu Bugs, die GPU-spezifisch sind, eben weil es keine Bytecode-Stufe wie bei Direct3D gibt. Ansonsten sehe ich eher Extensions, die zu den vorhandenen \($n$\) Wegen, etwas anzustellen, nun einen \($(n + 1).$\) Weg hinzugesellen.

Oh und die API haben sie immer noch nicht aufgeräumt bekommen. Fazit: Alles scheiße, egal wohin man schaut. Dafür ist man auch die Speerspitze des Fortschritts. :?

(Was ich gerade bemerke: Der Grund, warum keine bindless Textures in Direct3D 11.1 gekommen sind, könnte sein, dass mit Direct3D 12 anständige virtuelle Speicherverwaltung eingeführt wird, und damit fast alles bindless wird. Das ist aber nur meine Spekulation.)

eXile hat geschrieben:Also so wie ich das gerade sehe: Sie haben eingesehen, dass der OpenGL-OpenCL-Interop anscheinend Schrott war, und sind jetzt in Richtung Direct3D marschiert. Bindless Textures sind ja nicht neu hinzugekommen, aber das wäre ein Grund, warum man sich über Direct3D ärgern kann. Eine Sache, die du dir aber einhandeln könntest, ist der Umstieg von Bugs, die bei allen GPUs auftauchen, zu Bugs, die GPU-spezifisch sind, eben weil es keine Bytecode-Stufe wie bei Direct3D gibt. Ansonsten sehe ich eher Extensions, die zu den vorhandenen \($n$\) Wegen, etwas anzustellen, nun einen \($(n + 1).$\) Weg hinzugesellen.

Dazu müssten die DirectX-Tools erstmal zuverlässig korrekten Bytecode liefern. Davon abgesehen sind eigentlich alle meine Bugs bereits jetzt nicht nur GPU-, sondern auch treiberversionsspezifisch, in dieser Beziehung ändert sich also womöglich gar nichts. Ich arbeite z.B. gerade mit der nV-Treiber-Generation 2XX, weil dort oben beschriebener Bug glücklicherweise noch nicht auftrat. Aber wie soll das gehen, wenn du tatsächlich für die Massen produzierst?

eXile hat geschrieben:(Was ich gerade bemerke: Der Grund, warum keine bindless Textures in Direct3D 11.1 gekommen sind, könnte sein, dass mit Direct3D 12 anständige virtuelle Speicherverwaltung eingeführt wird, und damit fast alles bindless wird. Das ist aber nur meine Spekulation.)

Aber wann soll DirectX 12 kommen? Mit Windows 9? Und dann vermutlich Windows-9-only? Mit einem neuen, noch überladeneren und folgerichtig noch fehlerhafteren Shader-Compiler, der dann wieder erst in 5 Jahren, und womöglich nur durch einen noch instabileren, ersetzt wird? Außerdem ist Windows 7 gerade erst in der breiten Masse angekommen, was soll ich da mit einem Windows-8-only DX 11.1? Ich sehe da kaum eine Alternative zu einem Umstieg aufs neue OpenGL, sobald das einigermaßen zuverlässig läuft.

CodingCat hat geschrieben:Aber wie soll das gehen, wenn du tatsächlich für die Massen produzierst?

Antwort: Wenn man tatsächlich für Massen von Konsumenten kommerziell produziert, hat man einen direkten Draht zu nVidia und kriegt eine priorisierte Bug-Behebung.

CodingCat hat geschrieben:Aber wann soll DirectX 12 kommen? Mit Windows 9? Und dann vermutlich Windows-9-only? Mit einem neuen, noch überladeneren und folgerichtig noch fehlerhafteren Shader-Compiler, der dann wieder erst in 5 Jahren, und womöglich nur durch einen noch instabileren, ersetzt wird? Außerdem ist Windows 7 gerade erst in der breiten Masse angekommen, was soll ich da mit einem Windows-8-only DX 11.1? Ich sehe da kaum eine Alternative zu einem Umstieg aufs neue OpenGL, sobald das einigermaßen zuverlässig läuft.

Und was ist, wenn die Zeit, zu der OpenGL anständig läuft, genauso wenig kommt, wie die Zeit, zu der Direct3D anständig läuft? Beim HLSL-Compiler kann man wenigstens versuchen, Microsoft den Bug zu melden. Ansonsten muss man sich in beiden Fällen an die IHVs wenden, in beiden Fällen juckt es die einen feuchten Scheißdreck, wenn man als einzelne Person einen Bug meldet, in beiden Fällen muss man das Glück haben, dass irgendein kommerzieller Spielehersteller das gleiche Problem hatte und dein Problem so zufällig gefixt wird. Ich glaube nicht, dass die GLSL-Shadercompiler in den Treibern von besserer Qualität sind als der HLSL-zu-Bytecode-Compiler von Microsoft und die Bytecode-Compiler in den Treibern.

Bei den Release-Dates habe ich keine Ahnung. Aber dein Projekt ist doch aktuell ein Forschungsprojekt? Da ist es ziemlich egal ob das auf dem Median-System der Steam-User läuft oder auf einer SGI-Workstation mit 3dfx Voodoo 5 6000. Das Problem, dass die GPU am Ende auch die OpenGL-Extensions überhaupt unterstützen muss, bzw. das jeweilige Direct3D-Feature-Level haben muss, kriegt man ja auch nicht einfach weg. Aber ich gebe dir recht: Wenn Microsoft in der Tat meint, WDDM 1.2 so langsam wie WDDM 1.0 einzuführen, könnte das ziemlich beschissen werden.

Dass CUDA + Direct3D/OpenGL und OpenCL + OpenGL, also mögliche Interops, Probleme bereiten – ich glaube, dazu braucht man keine Kristallkugel. Ich bleibe dabei: Es ist alles Scheiße.

Um auch etwas konstruktives beizutragen: Bei deinen früheren HLSL-Problemen – hilft es da, wenn du den HLSL-Compiler aus dem Windows SDK Release Preview (mit Versionsnummer 9.30.960.8400) nimmst?

Also ich hab zwar mit DirectCompute noch keine wirkliche Erfahrung, aber wenn ich dir eines sagen kann, dann dass OpenCL kein schöner Ort ist und ich mir kaum vorstellen kann, dass DirectCompute schlimmer ist. CUDA ist meiner Erfahrung nach dem Rest um Lichtjahre voraus und immer noch Mist...

eXile hat geschrieben:Antwort: Wenn man tatsächlich für Massen von Konsumenten kommerziell produziert, hat man einen direkten Draht zu nVidia und kriegt eine priorisierte Bug-Behebung.
[...]
Ansonsten muss man sich in beiden Fällen an die IHVs wenden, in beiden Fällen juckt es die einen feuchten Scheißdreck, wenn man als einzelne Person einen Bug meldet, in beiden Fällen muss man das Glück haben, dass irgendein kommerzieller Spielehersteller das gleiche Problem hatte und dein Problem so zufällig gefixt wird. Ich glaube nicht, dass die GLSL-Shadercompiler in den Treibern von besserer Qualität sind als der HLSL-zu-Bytecode-Compiler von Microsoft und die Bytecode-Compiler in den Treibern.

Das ist mir durchaus klar, dennoch besteht mittlerweile ein entscheidender Unterschied: Auch Bugfixes für große Hersteller kommen bei DirectX 11 inzwischen einfach gar nicht mehr in der Öffentlichkeit an. Im Fall von OpenGL hingegen bekommst du immerhin noch aktuelle Treiber. Neue Treiber gibt es bald alle paar Wochen, ein neues DirectX voraussichtlich nur noch alle 5 Jahre. Bei DirectX 11 hilft es dir also nicht mal mehr, wenn andere das Problem bereits hatten.

eXile hat geschrieben:Das Problem, dass die GPU am Ende auch die OpenGL-Extensions überhaupt unterstützen muss, bzw. das jeweilige Direct3D-Feature-Level haben muss, kriegt man ja auch nicht einfach weg. Aber ich gebe dir recht: Wenn Microsoft in der Tat meint, WDDM 1.2 so langsam wie WDDM 1.0 einzuführen, könnte das ziemlich beschissen werden.

Unterhalb von Windows 8 bekomme ich aktuelle Features mit DirectX aber eben nicht mal mehr, wenn sie da sind.

eXile hat geschrieben:Dass CUDA + Direct3D/OpenGL und OpenCL + OpenGL, also mögliche Interops, Probleme bereiten – ich glaube, dazu braucht man keine Kristallkugel. Ich bleibe dabei: Es ist alles Scheiße.

OH JA. Aktuell raubt mir cudaGraphicsMapResources aus unerfindlichen Gründen einfach so pauschal 500 ms, selbst wenn ich nichts tue.

eXile hat geschrieben:Um auch etwas konstruktives beizutragen: Bei deinen früheren HLSL-Problemen – hilft es da, wenn du den HLSL-Compiler aus dem Windows SDK Release Preview (mit Versionsnummer 9.30.960.8400) nimmst?

Habe ich mich nicht getraut, weil einige berichtet haben, dass sich damit nicht mal mehr einfachste Compute Shaders korrekt kompilieren lassen. Im Moment komme ich mit einigermaßen wenigen Workarounds aus.

Ich könnte mir außerdem vorstellen, dass OpenGL langfristig unter Windows keine Option mehr sein wird. Mit Windows 8 ist es ja bereits auf Desktopanwendungen beschränkt...

Bevor ich meinen Desktop aufgeben muss, wechsle ich ohnehin zu Linux. Eine ordentliche IDE für clang müsste man noch schreiben. Am besten gleich mit ordentlichem UI Framework, zwei der größten Mängel in der Industrie mit einer Klappe beseitigt. Wahnsinn, dann hätte man endlich auch funktionierende Codegenerierung.

Es geht nicht darum, dass du deinen Desktop aufgeben sollst. Auch wenn man auch als Entwickler sicherlich weiterhin am Desktop entwickeln wird, so handelt es sich ja bereits jetzt schon bei einem großen Teil der entwickelten Anwendungen eben nicht um Desktopanwendungen. Und in Zukunft werden das sicherlich nicht weniger werden...

Ich weiß, aber für Metro-Billigkram braucht man den ganzen Schlamassel sowieso nicht. Auf anderen mobilen Endgeräten dürfte ohnehin GL ES Standard sein?

Und: Jetzt habe ich ein echtes Problem bezüglich Treiber: Im neuen Treiber gibts Fehler ohne Ende (siehe oben), der alte Treiber bremst mich dafür mit CUDA-Interop auf 1 s + X Framezeit.

CodingCat hat geschrieben:Ich weiß, aber für Metro-Billigkram braucht man den ganzen Schlamassel sowieso nicht. Auf anderen mobilen Endgeräten dürfte ohnehin GL ES Standard sein?

Auf Andoid und iOS, auf Windows nicht. Auch wenn Windows Phone noch vernachlässigbaren Marktanteil hat, würde ich mich nicht drauf verlassen, dass das so bleibt. Ich erwarte mir ehrlich gesagt sogar, dass Windows in absehbarer Zeit mit Android gleichziehen wird...

dot hat geschrieben:

CodingCat hat geschrieben:Ich weiß, aber für Metro-Billigkram braucht man den ganzen Schlamassel sowieso nicht. Auf anderen mobilen Endgeräten dürfte ohnehin GL ES Standard sein?

Auf Andoid und iOS, auf Windows nicht. Auch wenn Windows Phone noch vernachlässigbaren Marktanteil hat, würde ich mich nicht drauf verlassen, dass das so bleibt. Ich erwarte mir ehrlich gesagt sogar, dass Windows in absehbarer Zeit mit Android gleichziehen wird...

Man kann GLES-Code problemlos gegen OpenGL linken und alles funktioniert.

dot hat geschrieben:Ich könnte mir außerdem vorstellen, dass OpenGL langfristig unter Windows keine Option mehr sein wird. Mit Windows 8 ist es ja bereits auf Desktopanwendungen beschränkt...

Valve sieht in Windows 8 sogar eine Bedrohung (wohl wegen dem Store), weshalb sie jetzt den Treiberstack von Linux etwas pushen und PR machen. Denen ist wohl eine offene Plattform als Endnutzersystem auch lieber. Windows war ja mal eine recht offene Plattform, bis sie angefangen haben, von Apple Ideen zu klauen.

Manchmal, wenn ich lange im Debugger Dinge ein und ausschalte, funktioniert für einige Sekunden zufällig alles einigermaßen reibungslos:
Kurz darauf, ohne dass sich die Datenmenge groß geändert hätte, blockiert CUDA-Interop wieder alles (sowohl CUDA-Calls als auch anschließende Direct3D-Calls) und die Shader kriechen vor sich hin:
Ich habe gerade wieder einen aktuellen Treiber installiert, dieser verhält sich jedoch genauso, nur dass er zusätzlich oben beschriebene Pipeline-Hazards einführt. :evil:

Mehr sinnlose Reflexionen:

isnan() gibt false zurück, wenn ich mir die Daten auf die CPU hole, steht QNAN drin.

CodingCat hat geschrieben:isnan() gibt false zurück, wenn ich mir die Daten auf die CPU hole, steht QNAN drin.

Dann gibt isqnan() bestimmt true zurück :mrgreen:

Nope, es gibt nur isnan(), was laut Doku auf beides prüft. Nach Berechnungen funktioniert es übrigens. Der Compiler nimmt wohl an, dass im Speicher niemals NANs liegen, und optimiert es deshalb einfach mal weg.

Der Optimizer an sich funktioniert ja gar nicht mal so schlecht (wobei Krishty uns hier auch schon eines Besseren belehrt hat, so genau schaue ich da lieber gar nicht erst hin). Aber die Annahmen über den Wertebereich einzelner Variablen sind oftmals schlichtweg falsch, womit ein korrektes Ergebnis bei komplexeren Shadern zur reinen Glückssache wird. Ich muss mittlerweile an einigen Stellen eine Shader-Konstante namens Zero addiere, nur um diesen Wertebereich zu brechen und so vollständigen und korrekten Code zu erzwingen.

CodingCat hat geschrieben:Eine ordentliche IDE für clang müsste man noch schreiben. Am besten gleich mit ordentlichem UI Framework, zwei der größten Mängel in der Industrie mit einer Klappe beseitigt.

Da mich Eclipse mit CDT immer mehr ankotzt (das Ding kann genauso "viel" wie Notepad ...): Was waeren da deine Wunsch-Features und Vorstellungen?
Vielleicht auch in einem extra Thread. Ich hab angefangen, mir libclang in (g)vim zu integrieren fuer Code Parsing und Completion :mrgreen:

Einfach clang als wählbare Compileroption bei VS reinhängen.

kaiserludi hat geschrieben:Einfach clang als wählbare Compileroption bei VS reinhängen.

Das sollte ja einfach gehen. Man kann schliesslich auch den ICC ins VS integrieren. Hab VisualStudio schon Ewigkeiten nicht mehr benutzt...

glassbear hat geschrieben:

kaiserludi hat geschrieben:Einfach clang als wählbare Compileroption bei VS reinhängen.

Das sollte ja einfach gehen. Man kann schliesslich auch den ICC ins VS integrieren. Hab VisualStudio schon Ewigkeiten nicht mehr benutzt...

GCC geht auf alle Fälle, wird z.B für Android NDK Enwtwicklung in VS ia. vs-android und/oder winDBG oder auch vom Marmalade SDK so für die ARM-builds gemacht, da VC++ nicht für ARM baut. Wenn GCC geht, sollte auch clang machbar sein und schon hat man die beste IDE am Markt mit einem Compiler wie GCC oder Clang kombiniert, der auch für unixoide bauen kann. Einziger Haken ist dann noch, dass man auch die Entwicklung für OS , Linux, BSD und andere Unixe unter Windows machen muss, weil VS nicht wo anders läuft, aber zumindest bei mobilen Zielplatformen läuft die IDE ja eh so oder so nicht auf der Zielplatform.

Naja, ich will clang eigentlich gar nicht so dringend als Compiler, sondern wegen der vielen cooles Features die die IDE damit so einfach umsetzen kann. Damit man für C++ das hat, was Eclipse für Java ist. Ich kann es schon gar nicht mehr abwarten, so etwas endlich in die Finger zu bekommen, seit ich dieses libclang Werbevideo (http://devimages.apple.com/llvm/videos/Libclang.mov - hab ich zwar schonmal gepostet, aber was solls, bevor noch einer suchen muss :D ) gesehen habe.

NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Chromanoid hat geschrieben:NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Funktioniert gar nicht in Eclipse :lol: Zumindest nicht bei 150MiB Source Code (= nur ein Teil unseres Systems). Da funktioniert dann nichtmal mehr einfachste Funktionsaufloesung oder irgendetwas... Die ganzen 1.5GiB will er dann gar nicht erst indizieren, auch mit 16GiB RAM nicht. Netbeans ist ein bischen besser, aber auch nicht wirklich gut...

Jonathan hat geschrieben:Naja, ich will clang eigentlich gar nicht so dringend als Compiler, sondern wegen der vielen cooles Features die die IDE damit so einfach umsetzen kann. Damit man für C++ das hat, was Eclipse für Java ist. Ich kann es schon gar nicht mehr abwarten, so etwas endlich in die Finger zu bekommen, seit ich dieses libclang Werbevideo (http://devimages.apple.com/llvm/videos/Libclang.mov - hab ich zwar schonmal gepostet, aber was solls, bevor noch einer suchen muss :D ) gesehen habe.

Interessanterweise wollen alle Javaentwickler und ehemaligen Javaentwickler die ich kenne, Eclipse nicht mal mit Schutzhandschuhen anfassen.

glassbear hat geschrieben:

Chromanoid hat geschrieben:NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Funktioniert gar nicht in Eclipse :lol: Zumindest nicht bei 150MiB Source Code (= nur ein Teil unseres Systems). Da funktioniert dann nichtmal mehr einfachste Funktionsaufloesung oder irgendetwas... Die ganzen 1.5GiB will er dann gar nicht erst indizieren, auch mit 16GiB RAM nicht. Netbeans ist ein bischen besser, aber auch nicht wirklich gut...

:shock: 15 GiB Code? Ich glaub ihr macht da was ziemlich falsch. :D

BeRsErKeR hat geschrieben:

glassbear hat geschrieben:

Chromanoid hat geschrieben:NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Funktioniert gar nicht in Eclipse :lol: Zumindest nicht bei 150MiB Source Code (= nur ein Teil unseres Systems). Da funktioniert dann nichtmal mehr einfachste Funktionsaufloesung oder irgendetwas... Die ganzen 1.5GiB will er dann gar nicht erst indizieren, auch mit 16GiB RAM nicht. Netbeans ist ein bischen besser, aber auch nicht wirklich gut...

:shock: 15 GiB Code? Ich glaub ihr macht da was ziemlich falsch. :D

1.5GiB, nicht 15, ist natürlich immer noch eine riesige Menge. Das müsste ja locker in der Größenordnung von 100 Millionen Zeilen Code sein.

One does not simply use vector<bool>...

Gibt es denn keine Möglichkeit direkt an eine char*-Repräsentation von einem vector<bool> zu kommen?

&v[0]

Jep, oder ab C++11 die Methode data().