ZFX + Developia

Ja, das ist tatsächlich Religion. Ich bin ständig am Eclipse bashen und benutze VS für C# und QtCreator für C++ (VS für C++ nur mit Visual Assist X).

Chromanoid hat geschrieben:Irre wie sich da die Geister scheiden, ich würde XCode nicht mal mit der Kneifzange anfassen :)

Xcode ist in den letzen Jahren deutlich besser geworden.

Artificial Mind hat geschrieben:Ja, das ist tatsächlich Religion. Ich bin ständig am Eclipse bashen und benutze VS für C# und QtCreator für C++ (VS für C++ nur mit Visual Assist X).

Ich ziehe selbst VC++ Express um Längen genüber QTCreator vor, aber VAX befördert VS natürlich noch mal in eine neue Dimension.

kaiserludi hat geschrieben:

Artificial Mind hat geschrieben:Ja, das ist tatsächlich Religion. Ich bin ständig am Eclipse bashen und benutze VS für C# und QtCreator für C++ (VS für C++ nur mit Visual Assist X).

Ich ziehe selbst VC++ Express um Längen genüber QTCreator vor, aber VAX befördert VS natürlich noch mal in eine neue Dimension.

1. Wenn man mit Qt arbeiten muss, ist VC relativ undankbar (bzw. die Integration von Qt im QtCreator ist halt ungeschlagen)
2. Mich stört diese "Filter"-Struktur, statt einer "Ordner"-Struktur in VC++
3. QtCreator kommt besser mit CMake-Projekten klar
4. Linux (ja, ich muss auch auf/für Linux entwickeln)

Ein sauberes C++ Projekt, das mit Visual Studio erstellt ist (lies: kein CMake-Generat), kein Qt beinhaltet und für Windows ausgelegt ist, würde ich wahrscheinlich tatsächlich eher in VC++ schreiben, da das VC++-Intellisense nur unter genau diesen Bedingungen gut funktioniert. (VAX lässt es in der Tat eine Liga aufsteigen, aber das ändert meist nichts an den kaputten CMake-VC-Solutions und schon lange nichts an Linux)

Der QtCreator ist mittlerweile echt ganz gut, die Autovervollständigung ist noch nicht perfekt, aber wenigstens berechenbar.

Hieran sieht man glaube ich ganz gut, dass es stark von den Umständen abhängt.

PS: Ich habe momentan ein C++ Projekt, dass auf Windows 7 ausgelegt ist und das wir in VS 2012 mit VAX entwickeln. Wir benutzen sogar C++/CLR und arbeiten mit WPF im C++ Code und es ist immer noch angenehmes Programmieren.

Ich will dann auch mal meinen Senf dazu schreiben. Ich bin mit Visual Studio eigentlich zufrieden. Visual Assist habe ich mal ausprobiert, aber es hat mich nicht wirklich überzeugt, weil ich die meisten Features nicht gebraucht habe, und gerade das Nützliche, nämlich das lokale Code-Refactoring, bei stark getemplateten Code doch relativ häufig versagt hat.

Das scheint auch irgendwie der Nemesis dieser ganzen Refactoring-Tools zu sein: Kaum sind sie mal mit turing-vollständigen Templates konfrontiert, kollabieren sie zu einem kleinen Häufchen rauchender Asche.

Bei C++/CLR kommt ja eh nur VS infrage. Wobei ich ja immer noch auf objC++/CLR warte. Die Syntax wäre einfach der Hammer ;-)
1. QT setzen wir nicht ein. Daher fällt der Punkt für mich flach. Der QTCreator würde aber wohl auch seinen Namen nicht mehr verdienen, wenn er nicht den besten QT-Support haben würde.
2. Ist mir bisher nicht wirklich negativ aufgefallen.
3. CMake-Projekte rühre ich nur an, wenn es keinen Weg gibt, das ganze nicht auch als natives Projekt der jeweiligen IDE aufzusetzen.
4. Habe auch mal für ein Mobile Linux (Meego) entwickelt. Daher kenn ich den QTCreator. Ich habe diese IDE schnell zu hassen gelernt: Verbuggt und schneckenlahm. Projektsettings ändern: 30Sekunden Wartezeit nach jedem Klick, bevor die IDE wieder reagiert hat. Nun änder da mal 4 Setting pro Konfiguration bei 8 Konfigurationen pro Projekt und 6 Projekten. Schön wars auch immer, wenn der Projektsettingsidalog sich horizontal auf 3 fache Screenauflösung vergrößert hat und man ihn nicht mehr kleiner bekam: Lustiges hin und herschieben. Dazu sind QTCreator-Projektdateien inkompatibel zu sauberer Versionsvewaltung, weil Projekteinstellungen und Sachen wie Timestamps des letzten Öffnens des Projektes in der selben Datei gespeichert werden.

Ich entwickle derzeit für AndroidNDK (VS mit VAX, VS-android und WinGDB), Blackberry (QNX Momentics (gleiche UI wie Eclipse - würg)), iOS (Xcode), Marmalade (VS und Xcode), OS X (Xcode) und Windows (VS) und habe in den letzen Jahren auch für Brew (VS), Meego (QTCreator - argh) und Windows Mobile (VS) entwickelt. Der Code ist über alle Plattformen zu 99% identisch, das bischen plattformabhängiges sauber weggekapselt, aber da eh jede Plattform ihre eigenen Projekte braucht, nehme ich auch die jeweils meinem Empfinden nach brauchbarste kompatible IDE. 95% der Zeit kann ich mich auf VS und Xcode beschränken, wenn VC++ (VS), GCC (VS und Xcode) und Clang (Xcode), die ich damit abdecke, mit dem Code klar kommen, muss ich fast immer nur noch die Projektfiles im Falle neuer Datein anpassen und testweise einen "Build SDKs for all Platfroms" anschmeißen, dann passt alles, zumindest seit wir kein Brew mehr unterstützen. Das war die Hölle: Testdevices nur per Remotezugriff in Übersee, riesige Unterschiede zwischen Devices und Simulator und nur eingeschränkter C++ Support (keine Namespaces und auch Templates nur sehr rudimentär) und nur für die Sprache selbst, die Standardlib wurde einfach mal zu 0(!)% unterstützt.

Wow. Ich habe es eben zum ersten Mal seit Krishtygedenken geschafft, Windows 7 blauzuschirmen – indem ich in meiner Hauptschleife DispatchMessage() vergessen habe. Ich vermute, der Intel-Grafiktreiber mochte das nicht so.

Und die Tastensperre meines Handys lässt sich einfacher lösen, während jemand versucht, eine Bluetooth-Verbindung herzustellen.

Ist doch alles Müll.

Nachtrag: Nach dem Absturz sind alle meine Visual-C++-Einstellungen zurückgesetzt. Waaaaaaaaaah

Ich habe seit Jahren keinen Blue Screen mehr gesehen, dafür verursacht OS X gerne mal Regenbogenscreens: Das ganze Screen ist ein plötzlich einziger riesiger Farbverlauf. Das mitten bei der Arbeit einfach mal der Screen einfriert, kommt auch häufiger vor. Spätestens seit Vista ist Windows meiner Erfahrung nach um Welten stabiler als OS X, wenn auch die aktuellen OS X (seit Leopard, ältere habe ich nie verwendet) immer noch weit stabiler sind als Windows 98.

kaiserludi hat geschrieben:Ich habe seit Jahren keinen Blue Screen mehr gesehen, dafür verursacht OS X gerne mal Regenbogenscreens: Das ganze Screen ist ein plötzlich einziger riesiger Farbverlauf. Das mitten bei der Arbeit einfach mal der Screen einfriert, kommt auch häufiger vor. Spätestens seit Vista ist Windows meiner Erfahrung nach um Welten stabiler als OS X, wenn auch die aktuellen OS X (seit Leopard, ältere habe ich nie verwendet) immer noch weit stabiler sind als Windows 98.

Das würde ich mal checken lassen... ich quäle mein MacBook täglich mit CPU- und RAM-intensiver Klangbearbeitung und Sampling - und dass es mir wirklich abschmiert, passiert äußerst selten. Vielleicht einmal im halben Jahr. Und schon gar nicht mit "Regenbogenscreen".

kaiserludi hat geschrieben:4. Habe auch mal für ein Mobile Linux (Meego) entwickelt. Daher kenn ich den QTCreator. Ich habe diese IDE schnell zu hassen gelernt: Verbuggt und schneckenlahm. Projektsettings ändern: 30Sekunden Wartezeit nach jedem Klick, bevor die IDE wieder reagiert hat. Nun änder da mal 4 Setting pro Konfiguration bei 8 Konfugurationen pro Projekt und 6 Projekten. Schön wars auch immer, wenn der Projektsettingsidalog sich horizontal auf 3 fache Screenauflösung vergrößert hat und man ihn nicht mehr kleiner bekam: Lustiges hin und herschieben. Dazu sind QTCreator-Projektdateien inkompatibel zu sauberer Versionsvewaltung, weil Projekteinstellungen und Sachen wie Timestamps des letzten Öffnens des Projektes in der selben Datei gespeichert werden.

Ah, du hast eine ewig alte Version vom QtCreator benutzt, richtig? Der war früher tatsächlich eine Katastrophe. Seit 2.x ist der mir noch nie richtig eingefroren (einzige Ausnahme: wenn man in GLSL Code den ternären ?-Operator benutzt friert das Programm zuverlässig ein. Das liegt aber eher am GLSL-Plugin und nicht an der IDE denke ich).

EDIT: Achja, und das hauseigene Projektformat nutzen wir auch nicht, sondern nur CMakeLists.txt, was sehr gut funktioniert.

Hmm, die Version, die ich benutz habe, ist jetzt vielleicht 1, maximal 1,5 Jahre alt.

Ich arbeite erst seit einem halben Jahr wieder mit QtCreator, das könnte vielleicht echt der Punkt sein. Aber so wie du deine Anwendungsfälle schilderst, bist du mit einem VS mit VAX wahrscheinlich besser bedient. Bei mir an der Uni ist Linux nunmal Pflicht und bei uns ist auch alles in CMake-Projekten, deswegen gibt es nicht so viele Alternativen und von denen ist der QtCreator mMn die Beste.

Krishty hat geschrieben:Das scheiß Find & Replace-Fenster von Visual C++ 2010 ist saulahm. Ich klicke auf den Solution Explorer – sofort da. Ich klicke Strg+F – drei Sekunden Verzögerung, während sich das Fenster langsam aufbaut, das aus nichts besteht als aus einem Eingabefeld, einem Auswahlfeld, zwei Checkboxen und zwei Knöpfen. Mitunter ist Go to Definition schneller. WTF, Microsoft. WTF.

Also bei VIM öffnet sich das Eingabefeld zum Suchen immer ziemlich flott. Vielleicht solltest du umsteigen ;)

JAXB Namecollisions auflösen für w3c-erzeugte xsd-Dokumente ist nervig, vorallem wenn JAXB einem Fehlermeldungen mit geringem Informationsgehalt gibt und man selber neu in dem Thema ist. :x

Korrekt: Nach 15 Frames mit CUDA-Interop (irgendwas, muss nicht mal ein CUDA-Kernel laufen, nur Resource Mappings): Mit CUDA Interop (auf vollkommen anderen Ressourcen!) gehen ganz offensichtlich die D3D11 Atomics auf (bestimmten?) Ressourcen einfach kaputt.

Warum erst nach 15 Frames? Wie es aussieht werden Shader vom Treiber mit Verzögerung nachoptimiert. Die Heuristiken für die Nachoptimierung von Shadern sind alleine eine (vollkommen undokumentierte) Wissenschaft für sich. Wenn man Pech hat, kann einen schon das sämtliche Performance kosten:

Alexandre Mutel hat geschrieben:Funny, discovering how drivers are delaying shader optim ~ if time(shader_non_opt) > time(delay_between_gpu_calls) then optimize_shader();
meaning that if a non optimized shader is taking 100ms and you call it every 200ms, It won't be optimized (optim shader is 6ms)
So It seems that shaders need to be warmup x times consecutively before actually using them in order for the driver to bother optimize them
It's on a GTX580, latest drivers. With compute shaders for bitonic sort, drivers compiles only after 4-6 sorts on 1M particles 1/2
If I put a CPU sleep of more than 100ms (with readback of results) between each sort, the shaders will never get optimized.
- https://twitter.com/xoofx

Meine Schlussfolgerung ist nun, dass CUDA Interop auch die Nachoptimierung von D3D11 Shadern beeinflusst, so dass am Ende vollkommener Müll dabei herauskommt. Workaround? Hab ich immer noch keinen.

Mit vergleichbarem Schwachsinn beschäftige ich mich nun schon seit Wochen, ohne in der eigentlichen Sache groß voranzukommen. Diese ganzen General-Purpose-DirectX-Erweiterungen erscheinen mir inzwischen mangels funktionierender Tools (kaputter Shader-Compiler, kaum Diagnosemöglichkeiten, kaputtes PIX, kaputtes nSight) und mangels funktionierender Treiber wie nutzloses Spielzeug, und ich bin froh, wenn ich diesen Mist für eine Weile nicht mehr sehen muss.

Neben den dicken Fehlern kommt übrigens jede Minor-Treiber-Version auch noch mit einer ganz eigenen Palette von "Eigenheiten".

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.

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.