ZFX + Developia

Laut AMD's (Corporate-)Vize-Präsident im Bereich Global Channel Sales wird es in Zukunft keine neue DirectX-Version mehr geben:

http://www.heise.de/newsticker/meldung/ ... 35338.html

Mich würd ja interessieren, was Herr Taylor wirklich gesagt hat und inwiefern es sich da einfach nur um eine (möglicherweise nicht ganz unabsichtlich) unglückliche Übersetzung handelt. Die nächste Generation an Grafik APIs kommt bestimmt. Ich hab zwar das Gefühl, dass Microsoft gern hätte, dass D3D11 das nächste D3D9 wird, aber ich kann mir fast nicht vorstellen, dass das so funktionieren wird...

Vielleicht weil das in DirectX Blue umbenannt wird?

Sehr gut, dein Recherche-Web-Service ist wie immer unschlagbar. Danke! (Cryoschlaf bis 2015, anyone? :()

Danke fürs Lob, aber bedenkt, dass das immernoch fudzilla ist; und das FUD steht eben für fear, uncertainty and doubt. ;)

Aber der werte Herr hat mich auch beinahe bis ans Ausrasten gebracht, als er innerhalb wenigen Sätzen von „Aber es wird kein DirectX 12 kommen. Das war's.“ zu „never settle“ gewechselt hat.

Bisherige Zwitscher-Resonanz war ungefähr Null. Habe beide Links mal rumgezwitschert und hoffe auf eventuelle Antwort.

Laut der Chip Online-Meldung vom 04.04.2013 verriet Frank X. Shaw, Kommunikations-Chef bei Microsoft, dass Windows Blue wohl
unter einem anderen Namen erscheinen wird: "Die Chance, dass es tatsächlich unter diesem Namen herauskommt, liegen nahe Null", schrieb Shaw:

http://www.chip.de/news/Windows-Blue-Of ... 58655.html

Auf der BUILD 2013-Konferenz am 26. bis 28. Juni wird man laut Steve Guggenheimer, der bei Microsoft für Entwickler zuständig ist,
neues über die zukünftigen Microsoft-Pläne erfahren.

Dies bedeutet, so wie ich das verstehe, dass weder AMD noch nVIDIA zur Zeit Informationen über ein zukünftiges DirectX haben
(als Grafikkarten-Hersteller müssen die das eigentlich als erstes von Microsoft erfahren), und deshalb beide Hersteller
an eigenen Grafikkarten-Features arbeiten werden.

Bei Hardware-Infos.com gibt es dazu noch genauere Informationen:

http://www.hardware-infos.com/news/4352 ... mmen..html

http://www.hardware-infos.com/news/4352/amd-es-wird-kein-directx-12-kommen..html hat geschrieben:Alle irgendwann einmal gefassten Ziele erfüllt der momentane DirectX-Standard. Es gibt aktuell keine weiteren Visionen für eine neue Version. Die Aussage, dass zum Status quo nichts über DirectX 12 bekannt ist und wohl auch nicht erscheinen werde, ist somit nachvollziehbar.

Ja klar. Nur, dass bereits 2006 eine ganze Latte von Features vorgestellt wurden, welche die aktuellen Fähigkeiten von WDDM 1.2 und Direct3D 11.1 um einiges übersteigen. Und bevor einer sagt, dass es da ja nur um WDDM geht: So krasse Änderungen brauchen eine Änderung der Direct3D-API, um die benutzbar zu machen (das sah man ja schon an Direct3D 11.1, welches zwingend WDDM 1.2 voraussetzt).

http://www.hardware-infos.com/news/4352/amd-es-wird-kein-directx-12-kommen..html hat geschrieben:Branchen-Kenner vermuten, dass Microsoft lediglich mit neuen DirectX-Updates einige Parameter anheben könnte und gegebenenfalls Nebentechnologien wie TressFX hinzufügen könnte.

http://www.hardware-infos.com/news/4352/amd-es-wird-kein-directx-12-kommen..html hat geschrieben:Echte Neuerungen sind allerdings wie gesagt nicht in Sicht, weil man schlichtweg mit dem aktuellen DirectX schon alles zur Hand hat, um Spiele fotorealistisch darzustellen.

Wartewarte. 2006 haben die schon über WDDM 2.1+ philosophiert, und haben es in den sieben Jahren TROTZ dem ganzen Bruch durch Windows 8 nicht geschafft, überhaupt bis WDDM 2 zu kommen?! Ich dachte, da wären wir längst! Fuck

Und ich hatte in naiver Verstimmung letztens noch gefragt, wann Direct3D endlich virtuellen VRAM kann …

Wenn ich mir was wünschen dürft, dann wär das C++ auf der GPU anstatt Tupperwareshadersprachen, Hardwarefeatures in Form von Libraries/Intrinsics exposed, Unified Memory. Ich frag mich ja, ob ich das noch erleben werd...

dot hat geschrieben:C++ auf der GPU anstatt Tupperwareshadersprachen

Nein danke; bitte nicht noch eine Plattform, auf die wir die Legacy-Scheiße, das bekloppte Aliasing-Verhalten und die anderen Leistungsbremsen und Programmierqualen rüberschleppen. Wenn ich mir anschaue, was für Maschinentext Visual C++ generiert, und das mit der recht hochwertigen Ausgabe des HLSL Compilers vergleiche, wäre mir sogar GPU-Java noch lieber. Du willst irgendeine Tuppersprache wo du die verschiedenen Parallelisierungsarten und Cache-Hierarchien mit steuern kannst.

@GPU-Java: schon mal http://rbcompiler.com/ gesehen? :D Achja Aparapi gib't ja auch noch https://code.google.com/p/aparapi/

Was ihr mal für C++ bauen könntet, wäre ne kleine nette Metasprache. Bei AS3 klappt das ganz gut, vielleicht geht's ja auch gut mit C++. Da kann man dann auch gleich einen Optimizer mit einbauen. Also mit Metasprache meine ich eine C++ Bibliothek mit der man ein Miniprogramm schreiben kann, das den Shader bei Ausführung aufbaut. Hier sieht man das für Flash / AGAL: https://github.com/Barliesque/EasyAGAL/ ... cRender.as

Chromanoid hat geschrieben:Also mit Metasprache meine ich eine C++ Bibliothek mit der man ein Miniprogramm schreiben kann, das den Shader bei Ausführung aufbaut.

Wozu? Üblicherweise liegt der Shader doch schon als kompilierter und optimierter Bytecode vor.

Dann kann man das ganze in C++ entwickeln, kann zur Laufzeit den Shadercode sehr angenehm zusammenstecken (einfach mit C++ programmieren), hat IDE Unterstützung und ist recht unabhängig von der darunterliegenden Shadersprache. Wenn der Schritt von Shadersprache zu Shaderprogramm recht langwierig ist, macht das natürlich weniger Sinn. Wirklich praktisch ist es wohl eher bei Assembler artigen Sprachen wie AGAL.

Den Shader zu programmieren ist für mich ein statisches Problem; kein Laufzeitproblem. Ich fange ja auch nicht erst an, mir mein Programm zusammenzustecken, wenn es schon ausgeführt wird.

Naja des Öfteren braucht man doch Permutationen des gleichen Shaders... Sowas wie unterschiedliche Beleuchtungsqualitäten etc. das kann man so ganz gut abhandeln.

Wenn ich unterschiedliche Beleuchtungsalgorithmen brauche, muss ich die auch mehrfach schreiben; egal, ob mit C++ oder HLSL. Und wenn ich nur andere Beleuchtungsparameter für denselben Algorithmus brauche, übergebe ich dem Shader einfach unterschiedliche Parameter; dafür muss ich nichts kompilieren.

Mir ging es eigentlich weniger drum, einzelne Shader in C++ zu programmieren, sondern die ganze Pipeline... ;)