> > > > Ashes of the Singularity mit DirectX 12 und Asynchronous Shaders im Benchmark-Vergleich

Ashes of the Singularity mit DirectX 12 und Asynchronous Shaders im Benchmark-Vergleich

DruckenE-Mail
Erstellt am: von

Seite 1: Ashes of the Singularity mit DirectX 12 und Asynchronous Shaders im Benchmark-Vergleich

Ashes of the SingularityDirectX 12 dürfte in diesem Jahr mehr als nur eine Software-Theorie bleiben. Mit Ashes of the Singularity erscheint am 22. März ein erstes Spiel, welches mit der vollständigen Unterstützung von DirectX 12 daher kommt. Hitman ist ein zweiter Kandidat und zur GDC Mitte März werden noch weitere Ankündigungen erwartet. Heute schauen wir uns aber erst einmal die aktuelle Beta von Ashes of the Singularity an und vergleichen den Stand der Implementierungen zwischen AMD und NVIDIA, werfen aber auch einen Blick auf spezielle Funktionen wie die Asynchronous Shaders sowie verschiedene Multi-GPU-Implementierungen.

Seit mehr als zwei Jahren beschäftigen wir uns immer wieder ausgiebig mit dem Thema DirectX 12. Zu Anfang waren Microsoft und die weiteren beteiligten Unternehmen aber noch nicht sonderlich auskunftsfreudig und so sollte es bis September 2014 dauern, bis Microsoft und NVIDIA auf dem Launch-Event zur Maxwell-Architektur in Form der GeForce GTX 980 und 970 erste Details preisgaben. Darauf folgten immer wieder einige Updates und es war abzusehen, dass DirectX 12 auch bei AMD vor der Mantle-API den Vorzug bekommen wird. AMD konnte sich aber zu diesem Zeitpunkt bereits auf die Fahnen schreiben, eine Diskussion angestoßen zu haben, die letztendlich zu einer Umsetzung führt, von der alle profitieren sollen.

Die Einführung zahlreicher Grafik-APIs in den vergangenen Jahren hat gezeigt, dass gerade bei der Softwareschnittstelle zwischen Hard- und Software noch einiges Potenzial vorhanden ist. AMD macht mit Mantle den Anfang, DirectX 12 ist mit Windows 10 eingeführt worden, bei OpenGL ist erst kürzlich die Version 1.0 der Vulkan-API veröffentlicht worden und Apple brachte den Denkanstoß mit Metal in den mobilen Bereich. Bisher war bei diesen Optimierungen meist nur von den sogenannten Draw Calls die Rede, deren Overhead in den Berechnungen des Prozessors reduziert wurde. Der API Overhead Test als neuer Feature-Test des Futuremark 3DMark zeigte an dieser Hinsicht wieder das Potenzial auf.

Die Asynchronous Shaders

Es bedarf also nicht immer neuer Hardware, um deutlich mehr Leistung aus bestehenden Produkten zu kitzeln - so die Botschaft hinter den Erwartungen an DirectX 12. AMD spricht nun erstmals über ein Feature, welches sich eigentlich schon seit Einführung der "Graphics Core Next"-Architektur in den aktuellen GPUs befindet. Die sogenannten Asynchronous Shader sollen die Art und Weise, wie Engine, Treiber und Hardware miteinander sprechen und die Aufgaben verteilen, verbessern. Mit dem Launch der ersten Grafikkarten auf Basis der "Hawaii"-GPU sprach AMD aber noch von Verbesserungen beim GPU-Computing für die asynchrone Compute Engines. Jede GPU mit GCN-Architektur verfügt aber über diese speziellen Hardware-Einheiten. Was damals noch als ein reines Compute-Feature angesehen wurde, soll nun DirectX 12 bei Spielen auf die Sprünge helfen.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Bei den Betrachtungen einer GPU-Architektur erwähnen wir auch immer die einzelnen Funktionsblöcke, deren Funktionsweise und Verwendungszweck. Dabei zeigt sich, dass viele dieser Funktionseinheiten unabhängig voneinander arbeiten können, aufgrund des Rendering-Prozesses aber nicht in der Lage sind, so zu arbeiten, sondern meist linear nur eine sogenannte Queue abgearbeitet wird. Dieses schrittweise Abarbeiten versuchen die in allen Architekturen vorhandenen Scheduler zu optimieren, in dem sie die Aufgaben möglichst gleichmäßig verteilen, dies gelingt allerdings nur bis zu einem gewissen Grad.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Mit DirectX 12 verändert sich die Art und Weise der Zugriffe auf die API durch die Programmierer. Sie haben viel mehr Einfluss auf die Arbeitsschritte, sodass sich bestimmte Arbeitsprozesse besser organisieren lassen. Eine bessere Multi-Thread-Skalierung, Pipelines States und Work Submissions sind dabei die drei wichtigsten Werkzeuge, um den Rendering-Prozess entsprechend zu optimieren. In einer recht frühen Vorstellung von DirectX 12 durch Microsoft sind wir bereits darauf eingegangen.

Obiges Bild stellt die Abarbeitung der verschiedenen Rendering-Prozesse in DirectX 12 dar, während im Bild darüber die Arbeitsweise von DirectX 11 zu sehen ist. Die verkürzte Renderzeit äußert sich natürlich in höheren Frames pro Sekunde und reduziert auch die Latenzen, was in einigen Bereichen wie den VR-Brillen ebenfalls einen positiven Aspekt darstellt.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Nun können Entwickler die Aufgaben nicht beliebig verteilen, sondern müssen sich an gewisse Vorgaben der APIs halten. Moderne Spiele-Engines erlauben dazu eine Aufteilung in vordefinierte Queues, die unabhängig voneinander abgearbeitet werden können. In diesem Beispiel werden die Aufgaben in eine Grafik-, Compute- und Copy-Queue verteilt. Die API, hier DirectX 12, verteilt die Queues auf die zur Verfügung stehenden Ressourcen der GPU.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Was im Ansatz einfach klingt, ist in der Praxis aber weitaus komplizierter, denn auch diese verteilten Queues müssen auf die freien Ressourcen der GPU umgelegt werden. AMD erklärt einen Rendering-Prozess anhand eines Beispiels aus dem Autoverkehr. Die Kreuzung und Zusammenführung zweier Fahrspuren auf eine Spur mithilfe einer Ampel entspricht dabei der zu bewältigenden Aufgabe. Die Ampel ist dabei der Scheduler, der entscheiden muss, wann welcher Prozess in die Rendering-Pipeline eingeführt wird. Alle Schritte besitzen dabei die gleiche Priorität. Das Warten auf freie Ressourcen sowie das Umschalten benötigen also Zeit, die nicht sinnvoll genutzt wird.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Eine Möglichkeit diesen Prozess zu verbessern, sind die Pre-Emptions. Dabei werden einige Aufgaben priorisiert. Wieder am Beispiel des Autoverkehrs wird die blaue Queue angehalten, der höher priorisierte Prozess (lila) kann dann in den Rendering Prozess eingefügt werden. Allerdings findet auch hier ein Umschalten zwischen den verschiedenen Queues statt und auch die Effizienz wird nicht wesentlich erhöht.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Bei AMD kommen nun die asynchronen Compute Engines (ACE) ins Spiel. Diese mehrfachen Command Queues können gleichzeitig abgearbeitet und daher effizienter in den Rendering-Pipelines zusammengeführt werden. Damit das Beispiel des Autoverkehrs funktioniert, muss man vielleicht noch einfügen, dass es sich um einen getakteten Autoverkehr handelt, bei dem die Fahrzeuge einer bestimmten Reihenfolge und bestimmten Abständen folgen. Arbeiten die Command Queues alle mit dem gleichen Takt, kommt es eventuell zu Kollisionen. Die ACEs sollen dies verhindern, in dem sie die Commands unabhängig von einem Takt in die Queue einfügen. So lassen sich freie Lücken und damit brachliegendes Leistungspotenzial besser nutzen. Weiterhin möglich ist aber auch die Priorisierung bestimmter Prozesse.

Asynchronous Shaders sind bereits ein Teil der GCN-Architektur und es ist auch nicht weiter verwunderlich, dass eine GPU-Architektur derart vorausberechnend entwickelt wird. Die Ingenieure bei allen CPU- und GPU-Herstellern arbeiten sozusagen immer vorausschauend und planen bereits mit Softwareumsetzungen, die erst in einigen Jahren Anwendung finden werden.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Die ACEs sind bereits Bestandteil der "Graphics Core Next"-Architektur. Im Falle der "Hawaii"-GPU sind acht ACEs, mit der Möglichkeit jeweils acht Queues abzuarbeiten, vorhanden. Alle Grafikkarten aus dem Hause AMD mit GCN-Architektur sollen über diese ACEs verfügen, wobei sich die Anzahl natürlich abhängig vom Ausbau der Architektur unterscheidet.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Acht asynchrone Compute Engines (ACE) stehen in der "Hawaii"-GPU zur Verfügung, die allesamt unabhängig voneinander arbeiten können. Jede dieser ACEs kann wiederum acht unabhängig voneinander arbeitende Queues aufbauen. Für den schnellen Zugriff auf Daten können alle ACEs direkt auf den L2-Cache zugreifen. Über die Dual-DMA-Engine ist dies auch auf den Arbeitsspeicher möglich. Mit 16 GB pro Sekunde wird die volle Bandbreite von PCI-Express-3.0 ausgenutzt.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Asynchronous Shader sollen aber nicht nur die grundsätzliche Performance aktueller Architekturen und Arbeitsweisen von Render-Engines verbessern, sondern auch in speziellen Themenfeldern Verbesserungen herbeiführen. Das Aufkommen der VR-Technologie stellt alle damit beteiligten Hersteller vor neue Herausforderungen, denen prinzipiell auf eine ähnliche Art und Weise begegnet wird - egal ob von AMD oder NVIDIA. Um die Immersion, also das Eintauchen in eine virtuelle Welt störungsfrei gestalten zu können, müssen verschiedene Faktoren übereinstimmen.

Eine möglichst hohe Auflösung der Displays bei einer möglichst hohen Bildwiederholungsrate sind eine Herausforderung an die Rechenleistung als solches. Eine Auflösung von UltraHD pro Auge bei 90 Bildern pro Sekunde gelten momentan als das vorläufige Optimum. Die dazu notwenige Rechenleistung soll durch die Asynchronous Shader bereitgestellt werden. Zusätzlich reduziert sich die Latenz zwischen Eingabe durch den Nutzer und Darstellung auf dem Display, was für die Immersion ein entscheidender Faktor ist.

Mit den Asynchronous Shader ermöglicht werden auch weitere Technologien. Auf die Funktionsweise von Image Warping und (Asynchronous) Timewarp sind wir in anderen Artikeln schon genauer eingegangen. Die Herausforderungen und Lösungsansätze sind bei AMD und NVIDIA vergleichbar bzw. sogar identisch.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

Nun darf man sich sicherlich die Frage stellen, wann und wie sich konkrete Vorteile für Spieler aus den Asynchronous Shader ergeben. Praxisbeispiele sind derzeit noch nicht anzuwenden und auch die bisherigen DirectX-12-Benchmarks sind allenfalls Orientierungen, da sie nur Teilbereiche der Render Pipeline beleuchten können. Bestes Beispiel sind wieder einmal die Draw Calls, deren Anzahl sich im Vergleich zwischen DirectX 11 und Mantle/DirectX 12 dramatisch erhöhen, deren Auswirkungen auf die komplette Render Pipeline aber noch nicht abzuschätzen sind.

Wir werden uns wohl noch gedulden müssen, bis die ersten echten DirectX-12-Anwendungen verfügbar sind, um die Auswirkungen nachvollziehen zu können. Wie groß der Einfluss der Asynchronous Shader dabei ist, versucht AMD in eigenen Benchmarks nachvollziehbar zu machen. Dabei soll in einem Beispiel aus dem LiquidVR-SDK die Leistung ohne Asynchronous Shader mit zugeschalteten Post-Processing-Effekten von 245 auf 158 fps sinken. Werden die Asynchronous Shader nun wieder aktiviert, erreicht die Leistung wieder ein Niveau wie ohne die Post-Processing-Effekte.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

AMD hat nun also in der Theorie erklärt, wie ein Teil des Leistungs-Zugewinns mit DirectX 12 bei bestehender Hardware erreicht werden soll. Weiterhin schuldig bleibt man aber den konkreten Nachweis. Synthetische Benchmarks sind das eine und sprechen von einem Plus von teilweise mehreren hundert Prozent. Dabei werden aber nur Teilaspekte und niemals ein eventuelles Leistungsplus der kompletten Plattform beleuchtet. Dabei ergeht es allerdings nicht nur AMD so, sondern auch allen Anbietern vermeintlicher DirectX-12-Hardware. Mit der Windows 10 Technical Preview sowie den dazugehörigen Treibern wären die notwendigen Voraussetzungen in technischer Hinsicht erreicht, nun fehlt es noch an der Software.

Bei der Frage nach der Unterstützung durch die Hardware sind aber ebenso noch einige Fragen offen. Vermutlich wird es wieder unterschiedliche Ebenen für die Unterstützung von DirectX 12 geben. Mit unterschiedlichen Feature-Leveln hatten wir bereits bei DirectX 11 zu kämpfen und daran wird sich wohl auch mit DirectX 12 nichts tun. Sowohl AMD als auch NVIDIA benennen zumindest ihre letzten beiden GPU-Generationen als kompatibel zu DirectX 12. Im welchem Umfang dies der Fall sein soll, ist derzeit aber noch nicht bekannt.

Mit den Asynchronous Shader gibt AMD einen interessanten Einblick in das Verbesserungspotenzial durch DirectX 12. Die dazugehörige Hardware vorausgesetzt besteht also großes Potenzial für Leistungsverbesserungen, die nun allerdings noch umgesetzt werden müssen. Vermutlich werden wir erst im Sommer und mit ersten DirectX-12-Updates der Spiele (oder reinen DirectX-12-Engines) das Ergebnis der Anstrengungen durch AMD und NVIDIA sehen.

Welche GPUs die Asynchronous Shader nun in welcher Form genau unterstützen, erläutert folgende Tabelle:

Support der Asynchronous Shader
Architektur Mixed-Mode GPU-Computing
AMD GCN 1.2 (R9 285) 1x Grafik + 7x Compute 8x Compute
AMD GCN 1.1 (R9-290-Series) 1x Grafik + 7x Compute 8x Compute
AMD GCN 1.1 (R7-260-Series) 1x Grafik + 1x Compute 2x Compute
AMD GCN 1.0 (HD-7000- und restliche 200-Series) 1x Grafik + 1x Compute 2x Compute
NVIDIA Maxwell 2. Generation (GTX-900-Series) 1x Grafik + 31x Compute 32x Compute
NVIDIA Maxwell 1. Generation (GTX-750-Series) 1x Grafik 32x Compute
NVIDIA Kepler (GK110) 1x Grafik 32x Compute
NVIDIA Kepler (GK10x) 1x Grafik 1x Compute

Natürlich arbeitet auch NVIDIA an einer ähnlichen Technologie bzw. hat diese mit HyperQ bereits 2012 für den professionellen Bereich vorgestellt. Gegenüber "Fermi" ließ sich "Kepler" mit mehr als nur einer Work-Queue füttern. Bis zu 32 virtuelle GPU-Kerne können so erstellt und mit Daten versorgt werden. Die Implementierung unterscheidet sich allerdings bei AMD und NVIDIA, sodass die absoluten Zahlen sich nicht direkt vergleichen lassen.

AMD erklärt die Funktionsweise der Asynchronous Shader und einen Demo-Vergleich in zwei Videos:

 

Social Links

Seitenübersicht

Kommentare (141)

#132
Registriert seit: 10.12.2009
Schweiz
Kapitän zur See
Beiträge: 3702
Zitat YB0b;24391455
die GameWorks-manipulationen sein lassen.


Manipulationen?
GameWorks ist auf Nvidia optimiert. Das weiss auch jeder Spiele-Entwickler. Aber vorallem die AAA Studios haben gar keine Lust auf eigene Performance-Optimierungen, da muss einfach möglichst schnell der 60 Teil von CoD, BF, Fifa,... rauskommen. AMD könnte sowas auch anbieten und den Entwicklern zur Verfügung stellen. Man sollte den Fehler nicht immer bei den Anderen suchen.
#133
customavatars/avatar117663_1.gif
Registriert seit: 04.08.2009

Bootsmann
Beiträge: 574
Aha Nvidia's Manipulationen sind jetzt also "AMDs eigene Fehler".
Du hast keine Ahnung wovon du redest. AMD bietet sowas an (OpenGPU mit TressFX etc), mit dem Unterschied, dass es OpenSource ist und nicht die GPUs der Konkurenz einbremst.
#134
Registriert seit: 30.12.2014

Oberbootsmann
Beiträge: 868
Zitat
AMD bietet sowas an (TressFX), mit dem Unterschied, dass es OpenSource ist und nicht die GPUs der Konkurenz einbremst.

Doch, aber nur genauso wie die eigene.
#135
Registriert seit: 05.03.2016

Banned
Beiträge: 2
Zitat YB0b;24391757
Aha Nvidia's Manipulationen


Das ist keine Manipulation sondern Marktwitschaft
Ein Hersteller möchte seine Konkurennten um jeden preis ausschalten, und das wird auch AMD passieren wenn die sich nicht was einfallen lassen.

Sind im Prinzip selbst dran schuld, dass sie im high end gaming Bereich nichts konkurenzfähiges haben.
#136
customavatars/avatar22571_1.gif
Registriert seit: 06.05.2005

Korvettenkapitän
Beiträge: 2536
Zitat YB0b;24391757
Aha Nvidia's Manipulationen sind jetzt also "AMDs eigene Fehler".
Du hast keine Ahnung wovon du redest. AMD bietet sowas an (TressFX), mit dem Unterschied, dass es OpenSource ist und nicht die GPUs der Konkurenz einbremst und alle nicht mehr aktuelle Nvidia Architekturen.


Ich habe den Satz mal korrigiert. ;)

Zitat mike star;24391854
Sind im Prinzip selbst dran schuld, dass sie im high end gaming Bereich nichts konkurenzfähiges haben.

Das lustige ist, die Meisten gucken auf die Titan und kaufen dann doch nur eine GTX960... ;)
#137
customavatars/avatar43872_1.gif
Registriert seit: 31.07.2006

Fregattenkapitän
Beiträge: 2773
Zitat blubb0r87;24391660
Manipulationen?
GameWorks ist auf Nvidia optimiert. Das weiss auch jeder Spiele-Entwickler. Aber vorallem die AAA Studios haben gar keine Lust auf eigene Performance-Optimierungen, da muss einfach möglichst schnell der 60 Teil von CoD, BF, Fifa,... rauskommen. AMD könnte sowas auch anbieten und den Entwicklern zur Verfügung stellen. Man sollte den Fehler nicht immer bei den Anderen suchen.

Nein können sie nicht, da das mit großer Marktmacht einhergeht. AMD bleibt nichts anderes, als ähnliche Features für OpenSource zur Verfügung zu stellen, damit die Spieleentwickler das selbst weiterentwickeln können, eben wie TressFX -> PureHair, was deutlich effizienter arbeitet als die GW-Variante. Proprietär ist immer Mist für den Konsumenten, siehe beispielweise GSync. Würde NV auch den VESA-Standard AdapticeSync nutzen, gäbe es nicht dieses Monitorchaos.
Es gibt von dieser Regel nur eine Ausnahme: Wenn man etwas Neues starten möchte und viel Geld in die Verbreitung einer neuen Technologie stecken will, so wie Glide damals - oder Mantle (-> Vulkan) heute. Das trifft aber weder auf GW noch auf GSync zu, das sind reine Gelddruckmaschinen, weil man die Marktdominanz hat der geneigte User das mitmacht.
Für die Studios ist es billig, weil man konsolenoptimierte Titel schnell und billig mit GW-BlingBling aufwerten kann, damit man dranschreiben kann, dass man sich für PC extra viel Mühe gegeben hat. So macht das jedenfalls Ubi. AMD könnte sowas gar nicht leisten, weil man a.) nicht die Marktmacht hat, die würden fast kein Studio überzeugen und b.) weil sowas auch teuer ist und nur bei NV entsprechend Ertrag bei den Verkäufen bringt.
Langfristig werden sich aber auch in der Spielebranche OpenSorce-Bibliotheken für die Entwickler mehr und mehr durchsetzen, da das im Endeffekt massiv Kosten spart und der Kostendruck allgemein immer weiter wächst, während sich die Grafikqualität immer weniger durch immer aufwendigere Eigenentwicklungen abhebt. Schon bei den neuen APIs wie DX12 mit seinen erheblich gestiegenen Freiheitsgraden werden OpenSource-Bibs schon etliches an Entwicklungszeit einsparen und gleichzeitig als Basis für eigene neue Effekte dienen.
#138
customavatars/avatar117663_1.gif
Registriert seit: 04.08.2009

Bootsmann
Beiträge: 574
Zitat [HOT];24392407
Nein können sie nicht, da das mit großer Marktmacht einhergeht. AMD bleibt nichts anderes, als ähnliche Features für OpenSource zur Verfügung zu stellen, damit die Spieleentwickler das selbst weiterentwickeln können, eben wie TressFX -> PureHair, was deutlich effizienter arbeitet als die GW-Variante. Proprietär ist immer Mist für den Konsumenten, siehe beispielweise GSync. Würde NV auch den VESA-Standard AdapticeSync nutzen, gäbe es nicht dieses Monitorchaos.
Es gibt von dieser Regel nur eine Ausnahme: Wenn man etwas Neues starten möchte und viel Geld in die Verbreitung einer neuen Technologie stecken will, so wie Glide damals - oder Mantle (-> Vulkan) heute. Das trifft aber weder auf GW noch auf GSync zu, das sind reine Gelddruckmaschinen, weil man die Marktdominanz hat der geneigte User das mitmacht.
Für die Studios ist es billig, weil man konsolenoptimierte Titel schnell und billig mit GW-BlingBling aufwerten kann, damit man dranschreiben kann, dass man sich für PC extra viel Mühe gegeben hat. So macht das jedenfalls Ubi. AMD könnte sowas gar nicht leisten, weil man a.) nicht die Marktmacht hat, die würden fast kein Studio überzeugen und b.) weil sowas auch teuer ist und nur bei NV entsprechend Ertrag bei den Verkäufen bringt.
Langfristig werden sich aber auch in der Spielebranche OpenSorce-Bibliotheken für die Entwickler mehr und mehr durchsetzen, da das im Endeffekt massiv Kosten spart und der Kostendruck allgemein immer weiter wächst, während sich die Grafikqualität immer weniger durch immer aufwendigere Eigenentwicklungen abhebt. Schon bei den neuen APIs wie DX12 mit seinen erheblich gestiegenen Freiheitsgraden werden OpenSource-Bibs schon etliches an Entwicklungszeit einsparen und gleichzeitig als Basis für eigene neue Effekte dienen.

Danke für diesen guten Beitrag, HOT; ein Lichtblick in diesem Ottoforum.
Proprietär ist nicht nur Mist für den Konsumenten, sondern auch für den Entwickler. Es gibt keinen Grund, warum ich als Entwickler vorkompilierte Biblitheken offenenem Quellcode bevorzugen würde.
Sehr seltsam, dass Nvidia 1. dennoch lizensierte dlls anstatt source code schickt und 2. trotz AMDs offensiver Beschuldigungen die Verträge nicht offen legt.
Ein Schelm wer böses denkt....:rolleyes:
#139
customavatars/avatar3377_1.gif
Registriert seit: 15.11.2002
www.twitter.com/aschilling
[printed]-Redakteur
Tweety
Beiträge: 28806
Diskussionen aus der Vergangenheit und Benchmarks zum GeForce 364.47 (DX11, DX12, Asynchronous Shaders ein/aus): NVIDIA: Asynchronous Shaders sollen funktionieren, sind derzeit aber deaktiviert - Hardwareluxx
#140
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31094
Zitat YB0b;24393185
Proprietär ist nicht nur Mist für den Konsumenten, sondern auch für den Entwickler. Es gibt keinen Grund, warum ich als Entwickler vorkompilierte Biblitheken offenenem Quellcode bevorzugen würde.
Sehr seltsam, dass Nvidia 1. dennoch lizensierte dlls anstatt source code schickt und 2. trotz AMDs offensiver Beschuldigungen die Verträge nicht offen legt.
Ein Schelm wer böses denkt....:rolleyes:


Ich glaube, man redet hier immernoch aneinander vorbei...
Das Problem ist doch, der Jenige, der die "Sache" liefert, entscheidet, ob das nun OpenSource, ClosedSource, Lizenz xy oder weis der Geier was ist. Das ist sein gutes Recht, denn er hatte damit die Arbeit und kein Anderer.
Wie kommt man aber bitte darauf, einem Entwickler diese Entscheidung verbieten zu wollen? (OK verbieten ist das falsche Wort, aber darauf willst du doch im Endeffekt hinaus) -> man stellt sich hier hin und meint, ohne OpenSource geht nix. Dabei ist der Knackpunkt weiterhin, DU musst es doch nicht nutzen... Es hindert dich keiner daran, einfach selbst Code zu schubsen.

Mal ganz davon ab, unmittelbar nach Release von TW3, als AMD sich beschwerte von wegen, kein Einblick in die Gameworks Bibliotheken -> Es finden sich glaubhafte Interviews im Netz mit der Aussage seitens NV, CDP hätte doch die Lizenzen zur Codeeinsicht erstehen können -> hat man aber nicht. Heist unterm Strich, CDP hat die Blackbox erstanden und damit AMD (und natürlich sich selbst) die Optimierungsmöglichkeiten massiv verschwert. Die Frage weiterhin, was kann NV dafür?
Es ist nunmal einfach nicht so, dass der Code absolut gar nicht einsehbar wäre... Das trifft bestenfalls auf Teile zu. Nur ist es eben nicht für lau. Und das scheint hier einigen nicht zu schmecken...

Aber ich merke schon, so schlecht kann Gameworks ja nicht sein, wenn es offenbar hier alle haben wollen (den Code) :fresse:
Vielleicht fängt ja mal jemand an eine vollwertige Alternative als OpenSource anzubieten. AMD kommt dem schon ein Stück weit nahe -> nur ist neben bisschen visuellem Zeugs und eben TressFX (seit sechs Tagen sogar in v3!) da noch ne ziemlich große Lücke...

Zitat [HOT];24392407
Für die Studios ist es billig, weil man konsolenoptimierte Titel schnell und billig mit GW-BlingBling aufwerten kann, damit man dranschreiben kann, dass man sich für PC extra viel Mühe gegeben hat. So macht das jedenfalls Ubi. AMD könnte sowas gar nicht leisten, weil man a.) nicht die Marktmacht hat, die würden fast kein Studio überzeugen und b.) weil sowas auch teuer ist und nur bei NV entsprechend Ertrag bei den Verkäufen bringt.
Langfristig werden sich aber auch in der Spielebranche OpenSorce-Bibliotheken für die Entwickler mehr und mehr durchsetzen, da das im Endeffekt massiv Kosten spart und der Kostendruck allgemein immer weiter wächst, während sich die Grafikqualität immer weniger durch immer aufwendigere Eigenentwicklungen abhebt. Schon bei den neuen APIs wie DX12 mit seinen erheblich gestiegenen Freiheitsgraden werden OpenSource-Bibs schon etliches an Entwicklungszeit einsparen und gleichzeitig als Basis für eigene neue Effekte dienen.


Gibt es zu den Aussagen irgendwelche stichhaltigen Zahlen?
Weil einfach sagen -> OpenSource = billiger als ClosedSource in den Kosten ist etwas an den Haaren herbeigezogen. Ist so, weil ich das sage? Oder wie läuft das hier?
Zumal ich auch einen dezenten Widerspruch in der Aussage ansich sehe... Wer wenn nicht die Hersteller der Hardware können den Entwicklern bei (wie du selbst sagst) "erheblich gestiegenen Freiheitsgraden neuer APIs" helfen? Vor allem in Sachen Optimierung AUF eben diese Hardware? Wie soll das OpenSource, vielleicht noch von externen, also dritten Parteien gehen?
Nur weil einer der möglichen Kandidaten seine Leistungen nicht als OpenSource Versionen bereit stellt, ist das keineswegs schlecht. Muss man sich halt an den Lizenzen beteiligen oder Alternativen suchen...
Möglicherweise ist auch die Qualität der heute zu erstehenden Leistungen in Sachen Gameworks überhaupt erstmal so hoch, gerade WEIL es die Firmen lizensieren?
Wenn man sich das Gegenstück bei AMD ansieht. OpenSource gut und schön, nutzt mir als Entwickler aber gar nix, wenn es eben neben bisschen visuellen Effekten und TressFX nichts gibt, was Gameworks, vor allem in der Physikpalette sonst noch ausmacht... Warum macht es AMD (oder Andere, Dritte) nicht einfach? OpenSource kostet ja nix, wie du selbst sagst... Nur wie kommen diese Firmen an die Mittel um diese immer höheren Zeitanforderungen für immer komplexere Bibliotheken zu kompensieren, wenn da keine Gelder fließen?
-> das ist klar ein Henne Ein Problem. Der eine will möglichst nichts zahlen, der andere will möglichst nichts umsonst machen. Wie finden sie sich zusammen? Mit OpenSource von Dritten wäre eine Option. Aber der Dritte steht vor dem exakt gleichen Problem, wenn es nicht gerade die Community mit Eigenentwicklungen ist. -> mir wäre nicht bekannt, dass es in Sachen GameEngines/Bibliotheken so viel Eigenanteil von der Community gibt. Da stehen nach wie vor ziemlich große Firmen dahinter.
#141
customavatars/avatar33802_1.gif
Registriert seit: 21.01.2006

Kapitänleutnant
Beiträge: 1754
Zitat fdsonne;24384822
Warum sollte das nicht gehen?
...
Das wird wohl nix. 3D-Vision ist propritär NV. Entweder die lassen das zu (was unwarscheinlich ist) oder es geht einfach nicht... Technisch sollte MGPU dem Spaß nicht unbedingt was im Wege stehen, aber ich kann es mir nicht vorstellen.
...


Das hört sich doch schon ganz gut an; bei technischer Möglichkeit wäre ein Treiberhack denkbar.


Zitat fdsonne;24384822

...
Auf der anderen Seite, ich würde im ersten Step aber auch grundsätzlich erstmal bezweifeln, dass 3D-Vision überhaupt unter DX12 läuft :fresse:
...


Das wiederum klingt weniger gut, aber bisher hat nvidia 3D-Vision ja nicht offiziell aufgegeben, und in Hinsicht auf den VR-Hype wird ja eh eine 3D-Unterstützung notwendig werden, da dürfte eine Adaption der Ausgabemodi auf 3D-Vision doch eigentllich nicht so viel Zusatzaufwand bedeuten.
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

NVIDIA GeForce GTX 1080 mit Pascal-Architektur im XXL-Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Heute ist es soweit: NVIDIA läutet mit der GeForce GTX 1080 und GTX 1070 auf Basis der Pascal-Architektur den diesjährigen Neustart bei den Grafikkarten ein. In Kürze wird wohl auch AMD seinen Beitrag zu diesem Thema leisten. Vor zehn Tagen lud NVIDIA die gesammelte Fachpresse nach Austin ein... [mehr]

AMD Radeon R9 390X, 390 und 380 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2015/MSI-390X/RADEON-390-LOGO

Unterschiedlicher könnten die Produktstrategien zwischen AMD und NVIDIA derzeit wohl nicht sein. Während NVIDIA sein Lineup Schritt für Schritt erneuert und ein Rebranding, also ein Umbenennen alter Produkte im Desktop-Bereich, nur sehr selten bis gar nicht anwendet, stellt AMD zum zweiten Mal... [mehr]

Drei Modelle der Radeon R9 380 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2015/3X-R9-380/3X_R9_380-TEASER

Nach dem Start der neuen AMD-Grafikkarten treffen nach und nach in der Redaktion die ersten Boardpartner-Karten ein. Während es von der Radeon R9 Fury X lediglich Modelle mit Standard-Wasserkühler gibt, war es für die Hersteller ein Leichtes, ihre Kühlsysteme für die restlichen Modelle der... [mehr]

Drei Modelle der GeForce GTX 980 Ti im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2015/GTX980TI-ROUNDUP/ZOTAC-GTX980TI-ARCTICSTORM-LOGO

Heute wollen wir uns einmal drei unterschiedliche Modelle der GeForce GTX 980 Ti anschauen, von denen zumindest eines durch ein interessantes Konzept mit einer zusätzlichen Wasserkühlung auf sich aufmerksam machen kann. Es geht darum, die gute Basis der GeForce GTX 980 Ti weiter zu verbessern und... [mehr]

ASUS GeForce GTX 980 Ti Strix im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2015/ASUS-980TI-STRIX/ASUS-GTX980TI-LOGO

Es bricht die Phase an, in der alle namhaften Hersteller nicht nur eine erste Version der GeForce GTX 980 Ti auf den Markt gebracht haben, sondern inzwischen auch ausreichend Zeit und technische Kompetenz für einige komplett eigene Interpretationen aufbringen konnten. Mit insgesamt bereits fünf... [mehr]

AMD Radeon R9 Fury X im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2015/AMD-FURYX/AMD-FURYX-PRE-LOGO

Heute ist es endlich soweit - AMD startet mit der Radeon R9 Fury X in die nächste GPU-Generation. Es dürfte für AMD einer der wichtigsten Produktstarts sein, denn vieles hängt in naher Zukunft davon ab, wie gut die Produkte ankommen. Dies gilt sowohl bei den Grafikkarten als auch bei den... [mehr]