farewell, directx?
-
Also "bare metal" ist sicher keine Lösung. Dann müsste jedes Game min. 3 verschiedene Rendering-Backends haben: 1x für ATI, 1x für Nivea und 1x D3D für den Rest.
Und dann ändert sich mal was in der Art wie ATI/Nivea Karten angesprochen werden, und die Games laufen nimmer. Was sofort mit der nächsten Chip Generation passieren wird.Die Graka-Hersteller sollen also aufhören rumzujammern, und lieber selbst eine vernünftige (gemeinsame) API definieren. Und Microsoft "zwingen" das Treibermodell soweit anzupassen, dass diese alternative API auch sinnvoll mit den bestehenden Grafik-APIs unter Windows koexistieren kann.
Oder, wenn es wirklich so wichtig ist: es gibt immer noch Linux, da können sie so viele Treiber und APIs entwickeln und integrieren wie sie wollen. Wenn es dann wirklich mal soweit ist, dass Games auf Linux 2x so schnell laufen wie auf Windows, dann wird MS vermutlich auch reagieren müssen, da dann die Hardcore Gamer langsam aber sicher abwandern werden.
BTW: sind Draw-Calls mit D3D 11 denn immer noch "so langsam"?
-
hustbaer schrieb:
Die Graka-Hersteller sollen also aufhören rumzujammern, und lieber selbst eine vernünftige (gemeinsame) API definieren. Und Microsoft "zwingen" das Treibermodell soweit anzupassen, dass diese alternative API auch sinnvoll mit den bestehenden Grafik-APIs unter Windows koexistieren kann.
Auf der anderen Seite beschwert man sich, dass die OpenGL-Spec nur noch DirectX hinterher läuft und bei OpenGL haben die Graka-Hersteller ja ein größeres Mitspracherecht und könnten die Innovationen einbringen, die sie einbringen möchten.
-
Solche Reden sollte man erst schwingen wenn man am Treiber nichts mehr zu verbessern hat...
-
Nochmal zu dem Artikel... was mir da komisch vorkommt:
Of course, the ability to program direct-to-metal (directly to the hardware, rather than going through a standardised software API) is a no-brainer when it comes to consoles
Geht das denn mit der XBOX 360? Würde mich einigermassen wundern, ich dachte da gäbe es auch eine API von MS die man verwenden muss.
Vielleicht könnte jmd. der schonmal für die XBOX 360 (mit dem SDK, nicht mit XNA) programmiert hat diesbezüglich Klarheit schaffen, das wäre cool.
----
Achja, mein letzter Beitrag war diesbezüglich sehr unglücklich formuliert: Ich wünsche mir nicht dass die Hersteller eine eigenen API zusammenbrauen. Ich würde vorziehen dass eines der folgenden Dinge passiert:
* sie machen endlich mal mit OpenGL was vernünftiges
* sie setzen sich mit MS an einen Tisch und sehen zu dass bei D3D 12 was vernünftiges rauskommt
* nur wenn diese beiden Optionen - warum auch immer - scheitern: sie definieren selbst eine eigene (gemeinsame) APIIch sehe auch keinen Grund, warum das ein Problem bleiben muss. D3D hat mit der Fixed-Function Pipeline angefangen. Dann kamen Pixel- und Vertex-Shader, bessere Pixel- und Vertex-Shader, Instancing und schliesslich Geometry-Shader. Die Shader-Architektur hat im Prinzip die ganze Fixed-Function Sache über den Haufen geworfen. Danach wurde sie nur erweitert.
Wieso nicht als nächsten Schritt wieder alles über'n Haufen werfen, und eine ganze andere API definieren? Eine die die Möglichkeiten der aktuellen Hardware besser (direkter) zugänglich macht? Bzw. die Möglichkeiten der Hardware die gerade in Planung ist.
----
Oder, anderer Vorschlag: ist zwar auch nur geraten, aber ich könnte mir vorstellen dass eins was bei D3D mächtig und unnötig bremst das ganze Reference-Counting ist. Dass ein Interlocked-Befehl anfällt sobald man selbst ein Objekt (Textur, Shader, ...) anlegt ist ja noch OK. Aber bei jedem SetTexture/SetShader/... - das ist IMO pure Verschwendung und auch nicht nötig. Hier mit den üblichen COM Regeln zu brechen würde u.U. einiges bringen. z.B. halte ich es nicht für nötig, dass das D3D Device die Texturen/Shader etc. selbst referenziert. Es würde reichen wenn das Device mitbekommt wenn diese gelöscht werden während sie selektiert sind, damit es den entsprechenden Textur/Shader/...-Slot einfach auf NULL setzt.
Wenn man geeignete Regeln zur Thread-Safety definiert müsste das auch gehen ohne irgendwas grossartig zu bremsen.
Theoretisch könnte man sogar verbieten dass eine Anwendung das letzte "Handle" auf eine Resource freigibt, so lange diese noch selektiert ist.Mit solchen oder ähnlichen Anpassungen müsste man IMO noch einiges rausholen können, ohne gleich die komplette D3D API über den Haufen zu werfen.
----
Weil es auch erwähnt wurde: wo in D3D überall noch Kernel-Calls "zwingend" sind weiss ich nicht. Wenn das wirklich noch für jeden DrawXxx Call der Fall ist, dann gehört da auch mal nachgebessert. (Mit "zwingend" meine ich dass der Treiber-Hersteller keine Möglichkeit hat es abzuwenden. Wenn nur eine Default-Implementierung von MS besteht die das so macht, der Hersteller diese aber "überschreiben" kann ist das ja kein Problem.)
-
Ich kann dir zwar nicht sagen ob dafür ein Kernel-Call notwendig ist, aber ich habe letztens in einer Präsentation (hier: http://www.slideshare.net/DICEStudio/directx-11-rendering-in-battlefield-3) gelesen, dass Draw-Calls immer noch ein Problem sind und da einiges unternommen wurde um diese von 7K auf ~2K zu minimieren.
Edit: Wow, kennt jemand von euch http://software.intel.com/en-us/articles/practical-game-performance-analysis-using-intel-graphics-performance-analyzers/ ? Top-Software...
MfG SideWinder
-
Ich finde auch, dass DirectX zuviel Abstraktion bietet. OpenGL ist hier viel direkter und einfacher zu verwenden. Zumindest ich verstehe die OpenGL API besser als die DirectX API. Es sind nicht viele Funktionen, leisten aber genau das, was man braucht.
DirectX ist IMHO in den letzten Jahren ein wenig zur Bloatware geworden. Und man sieht auch auf Steam, dass mit OpenGL Games gemacht werden. Es gibt derzeit einige Spiele wo dabeisteht: OpenGL3 compatible Graphicscard required.AMD und NV sollten einen Gegenpol zu Microsoft bilden und OpenGL mehr den Herstellern anpreisen. Ich meine, der Support von OpenGL seitens dieser Firmen ist ja vorhanden, auch in SDK's und Beispielen etc.
Aber ich bin halt ein hoffnunsloser Idealist :D.
-
Scorcher24 schrieb:
Ich finde auch, dass DirectX zuviel Abstraktion bietet. OpenGL ist hier viel direkter und einfacher zu verwenden. Zumindest ich verstehe die OpenGL API besser als die DirectX API. Es sind nicht viele Funktionen, leisten aber genau das, was man braucht.
DirectX ist IMHO in den letzten Jahren ein wenig zur Bloatware geworden. Und man sieht auch auf Steam, dass mit OpenGL Games gemacht werden. Es gibt derzeit einige Spiele wo dabeisteht: OpenGL3 compatible Graphicscard required.Das nenn ich doch mal eine sachlich fundierte Aussage.
Wenn ich schon wieder so einen Quatsch von einem OpenGL Fanboy lese...Endet doch eh wieder nur einem DX vs OGL Flamewar.
-
Also ich habs nur überflogen aber wenn du mich fragst ist der Artikel ziemlicher Schwachsinn.
-
Das ist kein Schwachsinn.
DirectX ist jeglicher Innovation im Weg. Denn alle Welt muss warten bis M$ sich bequemt und ein neues Feature einbaut, welches Karten evtl. bereits anbieten. Bei OpenGL ist das anders. Da kann ATI die Funktionalität sofort selbst anbieten über eine OpenGL-Extension. NVIDIA kann dann diese auch implementieren und auch anbieten über die Treiber oder eventuell auch neuere Hardware. Und irgendwann kann das in den Core gehen. Ja es gibt einige Funktionen die ich unter OpenGL vermisse, wie das Auflisten der Grafikkarten oder die Wahl eines Pixelformates ohne ständig Canvase erzeugen und wieder zerstören zu müssen. Oder abfragen von günstigen Auflösungen etc ohne auf OS-Funktionen zurückgreifen zu müssen.
Trotzdem.
OpenGL ist und bleibt flexibler für alle.
Die Spielehersteller sollten mMn einfach mal OpenGL nutzen. Viele nutzen es ja sogar als alternativen Renderpfad wie Valve (-gl) oder Blizzard. Nur, warum wird dann trotzdem DirectX genutzt? Die Spiele sehen in beiden Renderpfaden genau gleich aus.
-
In der Theorie vielleicht, die Praxis sieht anders aus...genau das ist ja auch der Grund warum D3D im Moment so populär ist...
