> > > > 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 2: Multi-GPU: Mixed-Mode mit AMD und NVIDIA

Bisher konzentrierte sich vieles bei der Berichterstattung über DirectX 12 auf die Low-Level-Natur der API sowie den geringeren Overhead und damit das freiwerdende Leistungspotenzial. Auch wir haben bereits einige Tests durchgeführt – einmal zum entsprechenden Draw-Call-Test des 3DMark von Futuremark und inzwischen gehört ein DirectX-12-Benchmark zum Grafikkarten-Testparcours. Über die gemeinsame Nutzung der Grafik-API von AMD- und NVIDIA-Grafikkarten haben wir bereits berichtet, aber bis auf die theoretische Möglichkeit war davon bisher wenig zu sehen.

Ein gewöhnungsbedürftiger Anblick: Je eine AMD- und NVIDIA-Grafikkarte im Test
Ein gewöhnungsbedürftiger Anblick: Je eine AMD- und NVIDIA-Grafikkarte im Test

DirectX 12 Multi-GPU Explicit Multi-Adapter oder Multi Display Adapter – so die meistgenannten Namen der Methode der gemeinsamen Zusammenarbeit unterschiedlicher GPUs – wird durch die tiefere Kontrolle der API durch die Entwickler möglich. Sie haben eine weitergehende Kontrolle über den Zugriff auf den Speicher und viele andere Elemente der Hardware. Der Betrieb eines Multi-GPU-Systems lag unter DirectX 11 in den Händen der Treiber-Entwickler. Mit DirectX 12 geht die Kontrolle auf die Spiele-Entwickler über.

Die Multi-GPU-Technik

Doch zunächst noch ein paar Worte zur Historie der Multi-GPU-Technik: Die Entwicklung von PCI-Express als Interface zur Kommunikation der Grafikkarten mit dem restlichen System hat dazu geführt, dass sowohl AMD als auch NVIDIA mithilfe des AFR (Alternate Frame Rendering) eine relativ einfache Implementation der Multi-GPU-Technik einführen konnten. Beim AFR wird jeweils ein Frame von einer GPU berechnet. Anpassungen des Spiels oder der Game-Engine sind nicht notwendig. Einzig AMD und NVIDIA müssen ihre Treiber entsprechend anpassen, damit Unterschiede im Rendering einzelner Frames nicht zu störenden Effekten führen. AMD führte dazu das Frame Pacing ein, bei NVIDIA sind entsprechende Techniken ebenfalls bereits in Hard- und Software gegossen. Die Synchronisation zwischen GPU und Display-Panel in Form von FreeSync und G-Sync hat dazu geführt, das weitere störende Effekte zumindest minimiert werden konnten.

Allerdings sind die Hardwaremöglichkeiten relativ eingeschränkt. NVIDIA erlaubt nur die Zusammenarbeit zwischen identischen Grafikkarten, während AMD etwas flexibler zumindest die Möglichkeit bietet unterschiedliche Grafikkarten einzusetzen, die auf der gleichen GPU basieren (z.B: Radeon R9 290 und Radeon R9 290X). Der wichtigste Grund für diese Einschränkung ist natürlich die Tatsache, dass so die Frames im AFR immer ähnlich schnell berechnet werden können. Anläufe mit dem SFR (Spit Frame Rendering) wurden zwar gemacht, setzten sich aber nicht durch. Zum SFR aber später mehr.

Doch abgesehen von den offiziellen Modi SLI und CrossFire gab es auch Anläufe Grafikkarten verschiedener Hersteller und unterschiedlicher Leistungsklassen zu kombinieren. 2010 führte LucidLogix die Hydra-Technologie ein. Mit einem Zusatzchip und dazugehöriger Software setzte sich die Technologie zwischen die Calls von DirectX und OpenGL und führte diese den kompatiblen Grafikkarten zu. Allerdings gab es auch große Einschränkungen, sowohl auf Seiten der Hardware, als auch auf Seiten der Software. Letztendlich führte dies dazu, dass sich die Hydra-Technologie nicht durchsetzen konnte und wieder in der Versenkung verschwand.

DirectX 12 und Multi-Adapter

Mit DirectX 12 führt Microsoft drei Multi-Adapter-Modi ein. Der einfachste beschreibt dabei die bereits bekannte Funktionalität im AFR mit gleichen Grafikkarten wie bisher bei AMD und NVIDIA. Dieser Modus limitiert allerdings die Möglichkeiten der Entwickler, reduziert aber auch das Fehlerpotenzial bei tiefergehenden Zugriffen auf die Hardware. Weiterhin wird ein Großteil der Arbeit vom Treiber übernommen und nicht von DirectX 12.

Präsentation zu EMAPräsentation zu EMA

Präsentation zu EMA in DirectX 12

DirectX 12 ermöglicht einen tiefergehenden Zugriff auf die Hardware, auch in einem Multi-GPU-System. Dazu hat Microsoft auch den Explicit-Multi-Adapter-(EMA)-Modus eingeführt. Dazu müssen die Spieleentwickler explizit auf eine Multi-GPU-Unterstützung hinarbeiten. Jede einzelne GPU, die Speicherzugriffe und wie die GPUs untereinander kommunizieren – all dies muss zuvor festgelegt werden. Die Verantwortung der Funktionalität liegt vollständig in Händen der Spieleentwickler, was auch gewisse Gefahren birgt. Der Aufwand dieser expliziten Anpassungen darf nicht unterschätzt werden und Fehler müssen von den Entwicklern und nicht durch Microsoft, AMD oder NVIDIA korrigiert werden.

Präsentation zu EMA in DirectX 12
Präsentation zu EMA in DirectX 12

Der EMA-Modus bietet aber auch noch zwei unterschiedliche Wege der Implementierung: Linked Mode und Unlinked Mode. Der Unlinked Mode stellt die Basis der Funktionalität von EMA dar. Der Linked Mode auf der anderen Seite bietet eine höhere Funktionalität, schränkt dann aber auch die kombinierbare Hardware deutlich stärker ein – das ist wie ein festgelegtes SLI und CrossFire für DirectX 12 zu verstehen. Der Unlinked Mode hingegen kann dazu verwendet werden, unterschiedliche Grafikkarten, auch von unterschiedlichen Herstellern, miteinander zu kombinieren. Auch die Kombination zwischen diskreten und integrierten GPUs ist möglich.

Präsentation zu EMA in DirectX 12
Präsentation zu EMA in DirectX 12

Im Unlinked Mode wird jede Grafikkarte als eigenständige Hardware, mit eigenem Speicher, eigenem Commandprozessor etc. angesehen. Das EMA in DirectX 12 ermöglicht aber nun den Datenaustausch zwischen diesen Instanzen und dies tiefergehend als nur der Austausch fertig gerenderter Frames. Teilweise gerenderte Frames oder Daten in den Buffern können nun ausgetauscht werden, was völlig neue Wege des Renderings auf mehreren GPUs ermöglicht.

Was sich auf den ersten Blick aber wie eine einfache Möglichkeit des Datenaustausches darstellt und damit weiter als alles geht, was bisher möglich war, wird auf den zweiten Blick doch etwas komplizierter. So werden die Daten über das PCI-Express-Interface ausgetauscht, was im Vergleich zur Kommunikation zwischen GPU und dem Grafikspeicher deutlicher langsamer ist und zudem über eine recht hohe Latenz verfügt. Die Entwickler müssen sich also überlegen, welche Daten sie wann austauschen wollen, damit das PCI-Express-Interface nicht zum Flaschenhals wird. Ebenfalls darauf geachtet werden muss, in welcher Form diese Daten ausgetauscht werden. Die verschiedenen Hersteller und GPU-Generationen und Varianten legen oftmals unterschiedliche Datenformate an, die dann nicht so einfach untereinander verwendet werden können. Hier wird dann die Arbeit ersichtlich, die bei der Implementation von EMA im Unlinked Mode notwendig ist. Der Fokus des Unlinked Mode innerhalb des EMA liegt auf der bereits besagten Unterstützung von dGPUs und iGPUs, aber natürlich lassen sich hier auch unterschiedliche GPUs unterschiedlicher Hersteller kombinieren.

Präsentation zu EMA in DirectX 12
Präsentation zu EMA in DirectX 12

Der Linked Mode stellt wie gesagt in einfachster Form ein SLI oder CrossFire unter DirectX 12 dar, allerdings wird im Linked Mode die Hardware zu einer "Grafikkarte" zusammengefasst. Für das Spiel und den Nutzer sind nur noch eine GPU und ein Speicher sichtbar. Die Hardware muss dazu deutlich enger miteinander verknüpft werden, was mehr Möglichkeiten zulässt, allerdings auch für die Einschränkungen bei der Hardware sorgt. Das größte Leistungspotenzial liegt durch die Freiheiten sicherlich im Linked Mode, die größte Flexibilität bietet der Unlinked Mode. Entwickler, die möglichst wenig Arbeit haben möchten und dennoch eine Basisfunktionalität für ein Multi-GPU-System bieten wollen, unterstützen einfach nur das EMA und überlassen die Arbeit den Treiberentwicklern von AMD und NVIDIA. Da aber nur die Entwickler selbst den besten Einblick in die eigene Arbeit haben, ist sicherlich ein Angebot aus Linked und Unlinked Mode zu bevorzugen.

EMA in Ashes of the Singularity

Oxide Games hat Ashes of the Singularity vor einigen Monaten in den Early Access von Steam gebracht. 2016 soll das Echtzeit-Strategiespiel dann fertig sein. Als erstes seiner Art setzt es auf DirectX 12 und als erster Entwickler hat Oxide Games die Möglichkeiten von DirectX 12 vollständig ausgenutzt. AMD und Microsoft nutzen das Entwicklerstudio bzw. das Spiel als Technologiedemo. Zur Demonstration von EMA hat Oxide Games das Spiel auf eine AFR-Implementierung hin angepasst. Die Entwickler können jeden Frame einer bestimmten GPU zuteilen – eine Arbeit die zuvor vom Treiber übernommen wurde. Außerdem übernehmen sie die Übertragung der Frames von der sekundären zur primären GPU und auch das Frame Pacing wird nun vom Entwickler übernommen.

Das AFR funktioniert am besten, wenn ähnlich starke Grafikkarten eingesetzt werden, da die Frames hier in ähnlicher Zeit berechnet werden. Dennoch geht die Implementierung weiter als das, was AMD und NVIDIA derzeit bieten. Nicht nur lassen sich unterschiedliche GPUs unterschiedlicher Hersteller kombinieren, auch ist der Betrieb einer GeForce GTX Titan X mit einer GeForce GTX 980 Ti beispielsweise möglich. Funktionieren sollten alle Grafikkarten, die DirectX 12 unterstützen. Allerdings ist eine Kombination einer leistungsstarken mit einer eher leistungsschwachen Grafikkarte weniger sinnvoll. Wenn überhaupt, dann dürfte in der Praxis der Betrieb zweier fast gleichwertiger GPUs zu finden sein, womit auch die besten Resultate zu erwarten sind.

Ashes of the Singularity befindet sich in der Gesamtheit noch in einem Alpha-Status. Der Unlinked Mode von EMA ist noch weitaus experimenteller. Nur eine bestimmte Kombination aus AMD- und NVIDIA-Treibern funktioniert, aber das Ergebnis ist weitaus besser, als man dies zum aktuellen Zeitpunkt erwarten könnte. Laut Oxide Games soll der Unlinked Mode weiter verbessert werden, bevor man sich an die Arbeit mit dem Linked Mode macht. Von ihm erwartet man sich eine Leistungssteigerung im Bereich von 5 bis 10 Prozent.

 

Social Links

Seitenübersicht

Kommentare (141)

#132
Registriert seit: 10.12.2009
Schweiz
Kapitän zur See
Beiträge: 3811
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: 651
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

Oberleutnant zur See
Beiträge: 1284
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

Fregattenkapitän
Beiträge: 2825
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: 2857
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: 651
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: 29103
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: 31938
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: 2025
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:

Roundup: 5x GeForce GTX 1070 mit Custom-Design im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/5X-GTX1070/GTX1070_CUSTOM_ROUNDUP-TEASER

Nachdem wir bereits eine Reihe von Boardpartner-Karten der NVIDIA GeForce GTX 1080 ausführlich getestet haben, holen wir gleiches nun für das kleinere Schwestermodell nach, denn auch von der NVIDIA GeForce GTX 1070 gibt es viele Custom-Modelle mit höheren Taktraten, eigenen Kühlsystemen und... [mehr]

Drei Custom-Modelle der GeForce GTX 1060 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/3X-GTX1060/GTX1060_ROUNDUP_TEST-TEASER

Anders als bei der GeForce GTX 1080 und GeForce GTX 1070 trudelten wenige Stunden nach unserem Test zur Founders Edition der NVIDIA GeForce GTX 1060 schon die ersten Boardpartner-Karten mit teils höheren Taktraten, eigenem Kühlsystem und überarbeitetem Platinenlayout ein. Sie dürften... [mehr]

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]

Roundup: 5x GeForce GTX 1080 im Custom-Design im Test

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

Nachdem wir uns die Founders Edition der GeForce GTX 1080 und GeForce GTX 1070 bereits angeschaut haben, folgen nun fünf Retail-Modelle, die wir in aller Ausführlichkeit unter die Lupe nehmen wollen. Aus den vielen Boardpartnern und unterschiedlichen Modellen haben wir uns solche von ASUS, EVGA,... [mehr]

AMD Radeon RX 480 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/RADEON-RX480/RADEON-RX480-REFERENCE-LOGO

Es ist also soweit: AMD startet die großangelegte Zurückeroberung des Grafikkartenmarktes mit der Radeon RX 480, die als erste Grafikkarte der Polaris-Generation mit gleichnamiger Architektur erscheint und die wir uns genauer anschauen können. Dabei versucht sich AMD an einem anderen Ansatz im... [mehr]

PowerColor Radeon RX 480 Red Devil im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/POWERCOLOR-RX480/POWERCOLOR-RX480REDDEVIL-LOGO

Mit der Radeon RX 480 will AMD zurück zu alter Stärke und hat daher über Monate hinweg die PR-Trommel geschlagen. Letztendlich dabei herausgekommen ist eine sehr gute Karte für einen niedrigen Preis, die aber nicht in allen Bereichen zu überzeugen weiß. Wohl größtes Manko der Karte sollte... [mehr]