-
Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!
Test World of Warcraft: DirectX 12 macht AMD schneller, Nvidia bricht ein
- Ersteller Wolfgang
- Erstellt am
- Zum Test: World of Warcraft: DirectX 12 macht AMD schneller, Nvidia bricht ein
W
Wadenbeisser
Gast
Das Problem hätte man mit Vulkan umgehen können aber nun ja.... 
G
Genscher
Gast
"Unterstützt" heißt in dem Fall nur, dass die Befehle der API verstanden werden, das hat nichts damit zu tun, ob für die API auch Hardware Beschleunigung zur Verfügung steht. An Async Compute sieht man es bei NVIDIA am besten, das die nur faken.Locuza schrieb:
Man könnte auch sagen, dass NVIDIA einen DirectX 12 API Emulator benutzt.
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
1. Das ganze Arbeitsmodell von DX12/Vulkan?Wadenbeisser schrieb:
Also die explizite Erstellung der Command-Buffer, dass neue State- und Resource-Binding-Model, die explizite Speicherverwaltung etc, was über 90% der ganzen Arbeit und möglichen Effizienzverbesserung darstellt.
Du kannst doch nicht alles rausfiltern und dich auf einen spezifischen Teil davon beziehen und behaupten das ist das einzige was HW DX12 Support darstellt.
2. Von den oben genannten Bestandteilen der neuen APIs kann ich speziell auf das neue Resource-Binding-Model eingehen.
Alte Hardware (relativ gesehen), sind in vielen Dingen dem Modell gefolgt das es eine limitierte Anzahl an Hardware-Slots gab, wo API-Objekte gebunden waren.
Modernere Hardware-Designs sind viel weniger statisch und können viel mehr Objekte dynamisch indizieren.
Unter DX12 gibt es in diesem Bezug drei unterschiedliche Levels, es gibt Resource-Binding-Tier1 was sich grob an die starren Limits von DX11 hält, um DX12 Support für ältere/simplere Hardware einfacher zu machen und es gibt Resource-Binding-Tier2 was bezüglich einiger Ressourcen wie den Shader-Resource-Views (Bindless Textures) die alten Limits praktisch aufhebt.
Mit Resource-Binding-Tier 3 hat gibt es dann auch keine Limits mehr wie viele UAVs oder CBVs pro Shader Stage Entwickler verwenden können.
Kepler bis Pascal unterstützen in Hardware Resource-Binding Tier 2 als Fast-Path, mittlerweile und das kann man eher als cheat ansehen, hat Nvidia ab Maxwell v2 auch das Resource-Binding-Tier-3 implementiert bzw. unterstützt auch unter Vulkan deutlich höhere Limits, als die Hardware direkt schnell adressieren und managen kann:
https://abload.de/img/nvagrm0.jpg
Wie die Mechanik dahinter funktioniert kann ich nicht sagen, aber wenn man mehr Ressourcen hantiert, als die Hardware direkt verwalten kann, wird Nvidia wohl die Daten in ihrer Speicherhierarchie irgendwo hinschieben, wo es Platz gibt und das wird bisher unbekannte Performancekosten nach sich ziehen.
Dafür haben Entwickler eben die Möglichkeit den Kompromiss eingehen zu können, anstatt fest auf die Hardware-Limits getackert zu sein und ihre App enstprechend schreiben zu müssen.
DX12 FL12_0 schreibt bei DX12 Resource-Binding Tier 2 voraus, Tiled Resources Tier 2 (gab es ab DX11.2 auch optional) und Typed UAV Tier 1:
http://i.imgur.com/B47WPmC.jpg
Funktionell gesehen interessieren Spiele hauptsächlich das Resource-Binding-Model (tiled resources sind praktisch unnütz) und da unterstützt Nvidia mindestens Tier 2 (Außer old Fermi Tier 1), also hat man schon die Möglichkeit designtechnisch über das Niveau von DX11 hinaus zu gehen.
DX12 FL12_1 setzt noch Conservative Rasterization Tier 1 und ROVs voraus.
Beides setzt Nvidia über die Hardware (Rasterizer/ROPs) um und AMD hat erst mit Vega das entsprechende FL12_1 umgesetzt.
Und ist es okay FL12_1 nicht zu unterstützen und in der Hardware umzusetzen, aber wenn eine Hardware nicht simultan 3D, Compute und Copy-Queues durch unterschiedliche Units verwalten kann, was die DX12 Spec auch gar nicht vorschreibt, dann heißt es Nvidia Hardware hat kein HW DX12 Support, AMD aber schon?
Das ist eben völlig daneben.
Und ja GCN Gen 1 unterstützt schon die simultane Verwaltung von einer 3D- und Compute-Queue, aber wie gesagt DX12 schreibt nicht vor, wie es die Hardware umzusetzen hat, keine der drei Queue-Typen.
Intel setzt auch keine Compute-Queue um soweit ich weiß und für eine Copy-Queue steht eine DMA-Engine bereit, aber die wird nicht für alle Operationen verwendet, der Treiber entscheidet ob es die Shader machen oder die DMA-Engine, je nach Fall und die Freiheit erlaubt DX12 bzw. gibt keine Garantie darüber wie die Hardware die Queues verwalten wird.
Bezüglich der Copy-Queue haben AMD und Nvidia eine bessere DMA-Engine und können durch die simultan Befehle von einer Copy-Queue abarbeiten, unter DX11 Vanilla ohne IHV extensions gab es keine direkte Möglichkeit die DMA-Engines auszunutzen.
Und es gibt zig unterschiedliche Befehle, welche alle in der einen oder anderen Form umgesetzt werden und daraus pickt man nur ein Thema heraus und deklariert das als HW support?Genscher schrieb:
Eine spezifische "Async Compute-Implementierung" stellt keine 100% der DX12-API dar, bei weitem nicht.
Es ist völliger Unsinn an der Stelle zu sagen, dass Nvidia einen DX12 Emulator benutzt, wenn der Großteil der API nativ über die Hardware läuft und Möglichkeiten fernab der DX11-Limiterungen bestehen.
Zuletzt bearbeitet:
W
Wadenbeisser
Gast
@Locuza
Die Hauptaspekte der neuen APIs sind die Hardware nähere Programmierung der zeitgemäße CPU Support und die daraus resultierende ressourcen schonendere Arbeitsweise. Geschichten wie die Speicherverwaltung ergeben sich dadurch von selbst, da die API einem die Arbeit eben nicht mehr abnimmt.
Des weiteren redest du dich gerade um Kopf und Kragen denn deiner Argumentation nach würde die DX Version nur dann unterstützt werden wenn die höchste Ausbaustufe erreicht wurde, was natürlich kompletter Unfug ist.
Unterm Strich scheinst du dir das rauszupicken was deiner Argumentation dienlich ist.
War Async Compute für DX12 nun ein optionales Feature oder nicht? Um diese Antwort scheinst du dich mit ausladenen Postings verbissen zu drücken.
Wenn es für die FL12_0 und höher nicht optional ist und nicht von der GPU selbst unterstützt wird dann bietet diese, weil unvollständig, keinen hardwareseitigen DX12 Support. Es wäre also eine softwareseitig aufgemotzte DX11 GPU die so erst die Spec für das 12er Feature Level schafft. Damit wäre es auch herzlich egal ob sie mit den anderen Funktionen über die DX11 Spec hinaus geht. Siehe die erste GCN Generation.
Irgendwie schreibst du wie ein Politiker oder Werbestratege, viele wenig nützliche Informationen um das gewünschte Ziel zu erreichen und der Kernaspekt wird ausgeklammert.
Die Hauptaspekte der neuen APIs sind die Hardware nähere Programmierung der zeitgemäße CPU Support und die daraus resultierende ressourcen schonendere Arbeitsweise. Geschichten wie die Speicherverwaltung ergeben sich dadurch von selbst, da die API einem die Arbeit eben nicht mehr abnimmt.
Des weiteren redest du dich gerade um Kopf und Kragen denn deiner Argumentation nach würde die DX Version nur dann unterstützt werden wenn die höchste Ausbaustufe erreicht wurde, was natürlich kompletter Unfug ist.
Unterm Strich scheinst du dir das rauszupicken was deiner Argumentation dienlich ist.
War Async Compute für DX12 nun ein optionales Feature oder nicht? Um diese Antwort scheinst du dich mit ausladenen Postings verbissen zu drücken.
Wenn es für die FL12_0 und höher nicht optional ist und nicht von der GPU selbst unterstützt wird dann bietet diese, weil unvollständig, keinen hardwareseitigen DX12 Support. Es wäre also eine softwareseitig aufgemotzte DX11 GPU die so erst die Spec für das 12er Feature Level schafft. Damit wäre es auch herzlich egal ob sie mit den anderen Funktionen über die DX11 Spec hinaus geht. Siehe die erste GCN Generation.
Irgendwie schreibst du wie ein Politiker oder Werbestratege, viele wenig nützliche Informationen um das gewünschte Ziel zu erreichen und der Kernaspekt wird ausgeklammert.
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
Scheinbar war es nicht offensichtlich, dass meine Gegenfrage ein simples Beispiel dafür dargestellt hat, wohin man optional kommen kann, wenn man die gleiche selektive Logik anwendet.
Wenn Nvidia kein DX12 HW Support wegen einer nicht vorgeschriebenen Async Compute Implementierung besitzt, könnte ich doch genauso Schwachfug behaupten, dass AMD keine "echte" (ich liebe in dem Kontext das Wort, weil es so schwachsinnig ist) DX12 Hardware bietet, da ihnen DX12 FL12_1 Support fehlt (außer bei Vega).
Wieso klingt das eine wie kompletter Unfug für dich, aber nicht das andere?
-----
Zu dem scheinbaren Kernaspekt, da der Aufwand ein größeres Bild zu zeichnen scheinbar noch missbilligt wird.
DX12 stellt für den Entwickler drei unterschiedliche Queues bereit, welche unterschiedlich definierte Befehle aufnehmen können.
3D-Queue, Compute-Queue (was allgemein als Async Compute bezeichnet wird) und eine Copy-Queue.
Die DX12 Spec schreibt aber nicht vor wie die Implementierung der drei Queues auf der HW auszusehen hat, es gibt indem Bezug auch keine Feature-Abfrage unter DX12, man kann nicht nach Async Compute/Async Copy-Support fragen, es steht aus der API-Sicht immer zur Verfügung, egal welches Feature-Level man verwendet.
Und ich habe auch zuvor das Beispiele mit ARMs Tessellation-Implementierung über Compute-Shader genannt, um darzustellen wie groß die Freiheit bei der Implementierung sein kann, denn es geht letztendlich darum Spec konform zu sein und in der Hinsicht zwingt DX11/DX12 keinen Hersteller Tessellation über Fixed-Function-Hardware umzusetzen.
Genauso wie kein Hersteller unter DX12 gezwungen ist die Compute- oder Copy-Queue über dedizierte Scheduler/DMA-Units umzusetzen mit X-Arbeitsgranularität und Verwaltungsmechanismen.
Wenn Nvidia kein DX12 HW Support wegen einer nicht vorgeschriebenen Async Compute Implementierung besitzt, könnte ich doch genauso Schwachfug behaupten, dass AMD keine "echte" (ich liebe in dem Kontext das Wort, weil es so schwachsinnig ist) DX12 Hardware bietet, da ihnen DX12 FL12_1 Support fehlt (außer bei Vega).
Wieso klingt das eine wie kompletter Unfug für dich, aber nicht das andere?
-----
Zu dem scheinbaren Kernaspekt, da der Aufwand ein größeres Bild zu zeichnen scheinbar noch missbilligt wird.
DX12 stellt für den Entwickler drei unterschiedliche Queues bereit, welche unterschiedlich definierte Befehle aufnehmen können.
3D-Queue, Compute-Queue (was allgemein als Async Compute bezeichnet wird) und eine Copy-Queue.
Die DX12 Spec schreibt aber nicht vor wie die Implementierung der drei Queues auf der HW auszusehen hat, es gibt indem Bezug auch keine Feature-Abfrage unter DX12, man kann nicht nach Async Compute/Async Copy-Support fragen, es steht aus der API-Sicht immer zur Verfügung, egal welches Feature-Level man verwendet.
Und ich habe auch zuvor das Beispiele mit ARMs Tessellation-Implementierung über Compute-Shader genannt, um darzustellen wie groß die Freiheit bei der Implementierung sein kann, denn es geht letztendlich darum Spec konform zu sein und in der Hinsicht zwingt DX11/DX12 keinen Hersteller Tessellation über Fixed-Function-Hardware umzusetzen.
Genauso wie kein Hersteller unter DX12 gezwungen ist die Compute- oder Copy-Queue über dedizierte Scheduler/DMA-Units umzusetzen mit X-Arbeitsgranularität und Verwaltungsmechanismen.
Zuletzt bearbeitet:
W
Wadenbeisser
Gast
@Locuza
Wie heißt es so schön? Beantworte nie eine Frage mit einer Gegenfrage.
Wenn Async Compute eine Grundvoraussetzung für die 12er Feature Level ist und dies bei nvidia nur per (in der Praxis nutzlosen bis schädlichen) Software Emulation bereitstellen kann dann ist die Hardware eben nur DX11 tauglich...Punkt. Es ist für diese Aussage herzlich egal ob das Produkt per Software Emulation die entsprechende Feature Level dennoch erreicht. Eine Kette ist eben nur so stark wie ihr schwächstes Glied.
Es ist auch vollkommen irrelevant was du gern hättest, die Voraussetzungen für DX12 fangen bei 12_0 an. Punkt!
Unterm Strich geht es bei dieser nutzlosen Diskussion doch lediglich daraum das du nicht eingestehen willst das die entsprechenden Geforce Modelle keinen direkten DX12 Support in ihrer Hardware haben, also versuchst du entscheidene Punkte zu zerreden (Async Compute) und weitere Punkte hinzu zu dichten (FL12_1) und ich frage mich was deine Ambitionen dazu sind. An den Produkteigenschaften, welche nunmal aus Hard- und Software bestehen, ändert das schließlich herzlich wenig.
Dann kommst du auch noch wieder mit der ARM Geschichte angerannt, was letztendlich 2 verschiedene Paar Schuhe sind denn bei denen berechnet es dennoch die GPU selbst wärend Async Compute bei nvidia meines wissens nach von der CPU des PCs verwaltet wird und das eine ist ein Feature zur Berechnung , das andere eines Lastverwaltung. Das eine läuft dadurch im Zweifelsfall nur langsamer, das andere ist in der Praxis idR. deaktiviert wird weil es nur allso oft üble Performance Probleme nach sich zieht. Das fängt beim Frameratenverlußt an und geht weiter bis zu einem instabilen Frameratenverlauf, wobei es auch Konfigurationen/Programme zu geben scheint bei denen es halbwegs läuft.
Wie heißt es so schön? Beantworte nie eine Frage mit einer Gegenfrage.
Wenn Async Compute eine Grundvoraussetzung für die 12er Feature Level ist und dies bei nvidia nur per (in der Praxis nutzlosen bis schädlichen) Software Emulation bereitstellen kann dann ist die Hardware eben nur DX11 tauglich...Punkt. Es ist für diese Aussage herzlich egal ob das Produkt per Software Emulation die entsprechende Feature Level dennoch erreicht. Eine Kette ist eben nur so stark wie ihr schwächstes Glied.
Es ist auch vollkommen irrelevant was du gern hättest, die Voraussetzungen für DX12 fangen bei 12_0 an. Punkt!
Unterm Strich geht es bei dieser nutzlosen Diskussion doch lediglich daraum das du nicht eingestehen willst das die entsprechenden Geforce Modelle keinen direkten DX12 Support in ihrer Hardware haben, also versuchst du entscheidene Punkte zu zerreden (Async Compute) und weitere Punkte hinzu zu dichten (FL12_1) und ich frage mich was deine Ambitionen dazu sind. An den Produkteigenschaften, welche nunmal aus Hard- und Software bestehen, ändert das schließlich herzlich wenig.
Dann kommst du auch noch wieder mit der ARM Geschichte angerannt, was letztendlich 2 verschiedene Paar Schuhe sind denn bei denen berechnet es dennoch die GPU selbst wärend Async Compute bei nvidia meines wissens nach von der CPU des PCs verwaltet wird und das eine ist ein Feature zur Berechnung , das andere eines Lastverwaltung. Das eine läuft dadurch im Zweifelsfall nur langsamer, das andere ist in der Praxis idR. deaktiviert wird weil es nur allso oft üble Performance Probleme nach sich zieht. Das fängt beim Frameratenverlußt an und geht weiter bis zu einem instabilen Frameratenverlauf, wobei es auch Konfigurationen/Programme zu geben scheint bei denen es halbwegs läuft.
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
@Wadenbeisser
Ich glaube ich bemühe einen klassischen Autovergleich, der eindeutig machen wird, auf was für einem brutal unsinnigen Niveau die Diskussion sich befindet.
Man stelle sich vor wir sind nicht bei Computerbase, sondern bei Autobase.
Ein Testfahrer fährt mit zwei unterschiedlichen Autos auf einer Strecke mit unterschiedlichen Herausforderungen, einmal von BMW und einmal vom Mercedes.
Nach den Testergebnissen schreibt einer im Forum: "Man sieht hier eindeutig das Mercedes keine Autos baut".
An der Stelle weiß ich schon ganz gut was mit der völlig falschen Aussage gemeint ist, die davon kommt das vielen Leuten grundlegendes Wissen und Vorstellungsvermögen der Thematik fehlen.
Denn wenn Mercedes keine Autos herstellt, mit was ist der Testfahrer gefahren? Mit der Luft?
Nun kommt ein anderer Forenteilnehmer und sagt, was ist an der Aussage das Mercedes keine Autos baut denn unsinnig?
Denn Mercedes stellt keine Fahrzeuge mit Automatikschaltung her, also keine Autos.
Und hier kommt meine einfache Antwort, dass du ein Auto doch nicht einzig und allein an der Art der Gangschaltung definieren kannst.
Ein Auto besteht aus zig unterschiedlichen Komponenten.
An der Stelle kommt eine simple Gegenfrage, wo ich mich auf die Antriebsart beziehe, der BMW mit Automatik hat nämlich nur Vorderrad-Antrieb, der Mercedes mit manueller Gangschaltung Allradantrieb.
Hier Stelle ich die einfache Frage, wieso man nicht auch behaupten könnten, dass BMW keine echten Autos baut, denn die haben ja keinen Allradantrieb, sondern nur Vorderrad-Antrieb?
Jetzt kommt deine Antwort: "Dann widerlege es doch einfach".
Ich gehe darauf ein, dass man für ein Auto vier Reifen braucht, eine entsprechende Karosserie, einen Motor, Sitze etc.
Darauf bekomme ich sinngemäß folgenden Input: "Blabla, Reifen, Karosserie, Motor etc., dass ergibt sich von selbst, du schreibst wie ein Politiker oder Werbestratege, wenig nützliche Informationen, dabei wird der Kernaspekt ausgeklammert, muss ein Auto eine automatische Gangschaltung implementieren oder nicht?"
Und darauf war meine letzte Antwort, dass nein, ein Auto muss eine Art Gangschaltung implementieren, aber es ist egal ob manuell oder Automatik.
Dein neuster Beitrag redet erneut davon, dass Mercedes keine automatische Gangschaltung verwendet, also keine Autos baut und ich nicht eingestehen möchte, dass Mercedes keine Autos baut, dabei sind mir die Autohersteller völlig egal.
Da ich ehrlich gesagt nicht einschätzen kann, ob überhaupt fruchtbarer Boden existiert kommt hier mein letzter Beitrag dazu, falls erneut kein Fortschritt beim Verständnis erzielt wird:
In meinen Beitrag oben habe ich dir gesagt, was die Grundvoraussetzungen sind, die Unterstützung von drei Queue-Typen, egal wie ein Hersteller das umsetzt.
Die drei Queue-Typen sind immer verfügbar, egal welches FL.
Du kannst "Async Compute" mit DX12 FL11_0 verwenden, immer, du bekommst nur von der API bzw. der Spec keine Garantie oder Vorschrift darüber, wie die Hardware deine definierten Queues fressen wird.
Und die Behauptung eine Kette ist nur so stark wie ihr schwächstes Glied ist auch völlig unsinnig.
Und hier scheint man auch etwas nicht zu wissen oder bequem ausklammern zu wollen, denn die Verwendung von Async Compute ist völlig optional unter DX12/Vulkan und damit meine ich nicht von der HW, sondern von der Softwareseite, kein Entwickler muss Compute-Queues verwenden und extra definieren, haben einige DX12/Vulkan-Spiele auch nicht und andere bieten einen on/off-Schalter an, wo die Befehle einer separaten Compute-Queue in eine 3D-Queue eingespeist werden.
Wenn ein Entwickler DX12 FL12_1 ohne Async Compute verwendet, läuft der grotesken Logik denn was ab?
Bei niemanden läuft DX12 dann mit Hardware-Support, da kein Async Compute verwendet wird?
Ein Autobeispiel als völlig passende Analogie; der Testfahrer verwendet keine manuelle Gangschaltung --> Testfahrer fährt kein Auto.
Ich hoffe es leuchtet ein was für ein Hirnkrampf diese Aussage darstellt.
Was ist jetzt genau das Problem, wenn bei Kepler bis Maxwell v2 die Befehle in eine Queue eingespeist werden und dann von der Hardware ausgeführt?
Die CPU berechnet die Befehle schließlich nicht, sie serialisiert höchstens die Befehlsstruktur für die GPU, welche dank ihrer Architektur durch unterschiedliche Queues sowieso keinen Gewinn herausziehen könnte.
Pascal verwaltet Compute-Queues in der Hardware, aber irgendwie habe ich das Gefühl das es dennoch auf kein HW DX12-Support hinaus läuft oder?
Ich glaube ich bemühe einen klassischen Autovergleich, der eindeutig machen wird, auf was für einem brutal unsinnigen Niveau die Diskussion sich befindet.
Man stelle sich vor wir sind nicht bei Computerbase, sondern bei Autobase.
Ein Testfahrer fährt mit zwei unterschiedlichen Autos auf einer Strecke mit unterschiedlichen Herausforderungen, einmal von BMW und einmal vom Mercedes.
Nach den Testergebnissen schreibt einer im Forum: "Man sieht hier eindeutig das Mercedes keine Autos baut".
An der Stelle weiß ich schon ganz gut was mit der völlig falschen Aussage gemeint ist, die davon kommt das vielen Leuten grundlegendes Wissen und Vorstellungsvermögen der Thematik fehlen.
Denn wenn Mercedes keine Autos herstellt, mit was ist der Testfahrer gefahren? Mit der Luft?
Nun kommt ein anderer Forenteilnehmer und sagt, was ist an der Aussage das Mercedes keine Autos baut denn unsinnig?
Denn Mercedes stellt keine Fahrzeuge mit Automatikschaltung her, also keine Autos.
Und hier kommt meine einfache Antwort, dass du ein Auto doch nicht einzig und allein an der Art der Gangschaltung definieren kannst.
Ein Auto besteht aus zig unterschiedlichen Komponenten.
An der Stelle kommt eine simple Gegenfrage, wo ich mich auf die Antriebsart beziehe, der BMW mit Automatik hat nämlich nur Vorderrad-Antrieb, der Mercedes mit manueller Gangschaltung Allradantrieb.
Hier Stelle ich die einfache Frage, wieso man nicht auch behaupten könnten, dass BMW keine echten Autos baut, denn die haben ja keinen Allradantrieb, sondern nur Vorderrad-Antrieb?
Jetzt kommt deine Antwort: "Dann widerlege es doch einfach".
Ich gehe darauf ein, dass man für ein Auto vier Reifen braucht, eine entsprechende Karosserie, einen Motor, Sitze etc.
Darauf bekomme ich sinngemäß folgenden Input: "Blabla, Reifen, Karosserie, Motor etc., dass ergibt sich von selbst, du schreibst wie ein Politiker oder Werbestratege, wenig nützliche Informationen, dabei wird der Kernaspekt ausgeklammert, muss ein Auto eine automatische Gangschaltung implementieren oder nicht?"
Und darauf war meine letzte Antwort, dass nein, ein Auto muss eine Art Gangschaltung implementieren, aber es ist egal ob manuell oder Automatik.
Dein neuster Beitrag redet erneut davon, dass Mercedes keine automatische Gangschaltung verwendet, also keine Autos baut und ich nicht eingestehen möchte, dass Mercedes keine Autos baut, dabei sind mir die Autohersteller völlig egal.
Da ich ehrlich gesagt nicht einschätzen kann, ob überhaupt fruchtbarer Boden existiert kommt hier mein letzter Beitrag dazu, falls erneut kein Fortschritt beim Verständnis erzielt wird:
Async Compute ist keine Grundvoraussetzung für die 12er FLs.Wadenbeisser schrieb:
In meinen Beitrag oben habe ich dir gesagt, was die Grundvoraussetzungen sind, die Unterstützung von drei Queue-Typen, egal wie ein Hersteller das umsetzt.
Die drei Queue-Typen sind immer verfügbar, egal welches FL.
Du kannst "Async Compute" mit DX12 FL11_0 verwenden, immer, du bekommst nur von der API bzw. der Spec keine Garantie oder Vorschrift darüber, wie die Hardware deine definierten Queues fressen wird.
Und die Behauptung eine Kette ist nur so stark wie ihr schwächstes Glied ist auch völlig unsinnig.
Und hier scheint man auch etwas nicht zu wissen oder bequem ausklammern zu wollen, denn die Verwendung von Async Compute ist völlig optional unter DX12/Vulkan und damit meine ich nicht von der HW, sondern von der Softwareseite, kein Entwickler muss Compute-Queues verwenden und extra definieren, haben einige DX12/Vulkan-Spiele auch nicht und andere bieten einen on/off-Schalter an, wo die Befehle einer separaten Compute-Queue in eine 3D-Queue eingespeist werden.
Wenn ein Entwickler DX12 FL12_1 ohne Async Compute verwendet, läuft der grotesken Logik denn was ab?
Bei niemanden läuft DX12 dann mit Hardware-Support, da kein Async Compute verwendet wird?
Ein Autobeispiel als völlig passende Analogie; der Testfahrer verwendet keine manuelle Gangschaltung --> Testfahrer fährt kein Auto.
Ich hoffe es leuchtet ein was für ein Hirnkrampf diese Aussage darstellt.
In die Queues kommen definierte Befehle rein, die von der HW ausgeführt werden.Wadenbeisser schrieb:
Was ist jetzt genau das Problem, wenn bei Kepler bis Maxwell v2 die Befehle in eine Queue eingespeist werden und dann von der Hardware ausgeführt?
Die CPU berechnet die Befehle schließlich nicht, sie serialisiert höchstens die Befehlsstruktur für die GPU, welche dank ihrer Architektur durch unterschiedliche Queues sowieso keinen Gewinn herausziehen könnte.
Pascal verwaltet Compute-Queues in der Hardware, aber irgendwie habe ich das Gefühl das es dennoch auf kein HW DX12-Support hinaus läuft oder?
Zuletzt bearbeitet:
W
Wadenbeisser
Gast
@Locuza
Dann nehmen wir eben eine Auto Vergleich.
Nimm nen BMW M5 und klau dem die Turbos. Auf dem Papier bleiben die Leistungswerte gleich aber in der Realität (Hardware).... Alternativ kannst du dem dann auch das Steuergerät löschen (Treiber).
Das Gesammtprodukt passt erst wenn beides hinhaut aber das ändert nichts an den Fähigkeiten der Einzelnen Komponenten.
Du kannst so viel schreiben wie du willst aber das ändert nichts daran das Software keine Hardware ist und wenn es um die Fähigkeiten der Hardware geht schießt du dich mit dem Software Argument (Treiber Emulation) selbst ins Aus. Daher schenke ich mir auch den Großteil des Postings ernsthaft durchzulesen.
Dann nehmen wir eben eine Auto Vergleich.
Nimm nen BMW M5 und klau dem die Turbos. Auf dem Papier bleiben die Leistungswerte gleich aber in der Realität (Hardware).... Alternativ kannst du dem dann auch das Steuergerät löschen (Treiber).
Das Gesammtprodukt passt erst wenn beides hinhaut aber das ändert nichts an den Fähigkeiten der Einzelnen Komponenten.
Du kannst so viel schreiben wie du willst aber das ändert nichts daran das Software keine Hardware ist und wenn es um die Fähigkeiten der Hardware geht schießt du dich mit dem Software Argument (Treiber Emulation) selbst ins Aus. Daher schenke ich mir auch den Großteil des Postings ernsthaft durchzulesen.
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
Das ist aber kein zutreffender Vergleich oder ein Äquivalent der die völlig unsinnige Aussage von dir widerspiegelt.Wadenbeisser schrieb:
Denn was du pauschal weiß machen willst ist, dass wenn der BMW M5 kein Turbo implementiert, es pauschal kein Auto ist.
Du und der Poster zu Beginn wollen ja genau das weiß machen, dass wenn eine GPU nicht Compute-Queues von der HW simultan verwalten lässt, es keinen DX12 Hardware Support gibt, als ob ein Auto kein Auto ist wenn es keinen Turbo hat oder eine automatische Gangschaltung.
Du bist auch ein extremer Feigling und ein Faultier, der meine Beiträge gar nicht ordentlich durchliest, auf meine Fragen nicht antwortet und sich letztendlich meinen Argumenten völlig selektiv entziehen möchte, wie es ihm passt.
Neotax
Cadet 4th Year
- Registriert
- Okt. 2013
- Beiträge
- 65
Mein Amd Fury Vergleich in der neuen Horde Hauptstadt
Hardware
Cpu: Intel I7 6700K @ 4,5Ghz RAM: G.Skill 16GB 2133 Mhz Graphic Card: Gigabyte AMD Fury Windforce X3 @1060Mhz
Szene mit Bildvergleich Kamera ist Fixiert
DX11
Average framerate : 69.7 FPS
Minimum framerate : 50.5 FPS
Maximum framerate : 118.9 FPS
1% low framerate : 38.9 FPS
0.1% low framerate : 23.2 FPS
DX12
Average framerate : 74.9 FPS
Minimum framerate : 52.5 FPS
Maximum framerate : 128.9 FPS
1% low framerate : 47.0 FPS
0.1% low framerate : 25.6 FPS
Hardware
Cpu: Intel I7 6700K @ 4,5Ghz RAM: G.Skill 16GB 2133 Mhz Graphic Card: Gigabyte AMD Fury Windforce X3 @1060Mhz
Szene mit Bildvergleich Kamera ist Fixiert
DX11
Average framerate : 69.7 FPS
Minimum framerate : 50.5 FPS
Maximum framerate : 118.9 FPS
1% low framerate : 38.9 FPS
0.1% low framerate : 23.2 FPS
DX12
Average framerate : 74.9 FPS
Minimum framerate : 52.5 FPS
Maximum framerate : 128.9 FPS
1% low framerate : 47.0 FPS
0.1% low framerate : 25.6 FPS
W
Wadenbeisser
Gast
Es ist doch ziemlich genau das worum es geht.Locuza schrieb:
Klau dem Motor die Turbos und er läuft nicht wenn sie dennoch gefordert werden.
Lasse das Steuergerät so tuen als ob sie dennoch da wären und die Kiste läuft unrund....vielleicht gibt es etwas mehr Leistung als als Sauger aber die Warscheinlichkeit ist hoch das man Leistung verliert weil das Gemisch usw. nicht stimmt.
Konfiguriere es so das er wie ein Sauger arbeitet und die Kiste läuft wieder rund, hat aber weniger Leistung als mit Turbos.
Unterm Strich ist es genau das worum es hier geht. Das Steuergerät (Treiber) wurde so programmiert das es so tut als würde der Motor (Hardware) etwas können was nicht vorhanden ist, hauptsache das Auto (Grafikkarte) läuft irgendwie.
Diesen Zustand willst du mit dem orginalen Zustand gleich setzen und so tuen als hätte er doch welche weil das Steuergerät sagt das sie da wären.
Und weil der Ofen dann unnrund wie ein Sack Nüsse läuft macht man was? Richtig, man sagt dem das er keinen Turbo nutzen soll und hätte wieder das Ergebnis vom Sauger.
Wie du immer wieder verdeutlichst bist du nicht in der Lage die über den Treiber anzusprechende Grafikkarte von den in Hardware ausgeführten Funktionen der GPU zu unterscheiden. Da helfen dir auch deine Beleidigungen nicht weiter, sie unterstreichen es eher noch.
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
@Wadenbeisser
Wieso kommt es bei dir nicht durch, dass DX12 an der Stelle keine konkrete HW-Implementierung verlangt und Async Compute selber auch nur einen Teilbereich der DX12 API darstellt?
Wie kommst du zu der Weltansicht das HW gestütztes Compute-Queue Scheduling in Kombination mit einem 3D-Kontext das einzige ist was Hardware Support für DX12 ausmacht?
Ich meine was passiert in deiner Weltanschauung, wenn der Entwickler gar keine Compute-Queues verwendet?
Ist dann eine DX12-App effektiv nur DX11 oder läuft die DX12 App dann ohne HW-Support bei keinem Hersteller oder wie?
Wir enden wieder bei dem Beispiel, wo ein Auto angeblich kein Auto ist, weil es die Gangschaltung nicht automatisch umsetzt oder ein TurboLoader fehlt.
Dann schauen wir uns von mir aus Benchmarks an, hier DX12 Time Spy mit Async Compute:
https://www.computerbase.de/2016-07/3dmark-time-spy-dx12-benchmark/3/
Kein Unterschied für Maxwell, ob AC genutzt wird oder nicht und die Ergebnisse in Relation zu den Radeons befinden sich auch nicht in einer anderen Welt.
Sniper Elite 4 als konkretes Spiel:
https://www.computerbase.de/2017-02/sniper-elite-4-benchmark/
Na ach du Schreck, eine RX480 wird von DX11 auf DX12 16% schneller, Async Compute hilft zusätzlich nur um 3%.
Aber oh oh, Pascal wird dank DX12 ja auch schneller 3%, + 2% durch Async Compute.
Keine Ahnung wie die Ergebnisse in dein Weltbild passen.
Wieso kommt es bei dir nicht durch, dass DX12 an der Stelle keine konkrete HW-Implementierung verlangt und Async Compute selber auch nur einen Teilbereich der DX12 API darstellt?
Wie kommst du zu der Weltansicht das HW gestütztes Compute-Queue Scheduling in Kombination mit einem 3D-Kontext das einzige ist was Hardware Support für DX12 ausmacht?
Ich meine was passiert in deiner Weltanschauung, wenn der Entwickler gar keine Compute-Queues verwendet?
Ist dann eine DX12-App effektiv nur DX11 oder läuft die DX12 App dann ohne HW-Support bei keinem Hersteller oder wie?
Wir enden wieder bei dem Beispiel, wo ein Auto angeblich kein Auto ist, weil es die Gangschaltung nicht automatisch umsetzt oder ein TurboLoader fehlt.
Dann schauen wir uns von mir aus Benchmarks an, hier DX12 Time Spy mit Async Compute:
https://www.computerbase.de/2016-07/3dmark-time-spy-dx12-benchmark/3/
Kein Unterschied für Maxwell, ob AC genutzt wird oder nicht und die Ergebnisse in Relation zu den Radeons befinden sich auch nicht in einer anderen Welt.
Sniper Elite 4 als konkretes Spiel:
https://www.computerbase.de/2017-02/sniper-elite-4-benchmark/
Na ach du Schreck, eine RX480 wird von DX11 auf DX12 16% schneller, Async Compute hilft zusätzlich nur um 3%.
Aber oh oh, Pascal wird dank DX12 ja auch schneller 3%, + 2% durch Async Compute.
Keine Ahnung wie die Ergebnisse in dein Weltbild passen.
W
Wadenbeisser
Gast
@Locuza
Uhh...Cherry picking...fein fein.
https://www.computerbase.de/2016-02...e-singularity-beta-2-1920-1080-extreme-preset
https://www.tomshw.de/2016/02/26/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming/
Oder der Test hier:
https://www.extremetech.com/gaming/...s-performance-on-amd-hardware-flat-on-maxwell
Zudem, wurde bei Wolfenstein nicht Async Compute per default deaktiviert weil es zu einem stockenden Frameratenverlauf führen konnte? Etwas was bei solchen Tests eher selten berücksichtigt wird.
Auch wenn es ein Vulkan und kein DX12 Spiel ist.
Und noch etwas zu Sniper Elite 4...
Uhh...Cherry picking...fein fein.
https://www.computerbase.de/2016-02...e-singularity-beta-2-1920-1080-extreme-preset
https://www.tomshw.de/2016/02/26/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming/
Oder der Test hier:
https://www.extremetech.com/gaming/...s-performance-on-amd-hardware-flat-on-maxwell
Zudem, wurde bei Wolfenstein nicht Async Compute per default deaktiviert weil es zu einem stockenden Frameratenverlauf führen konnte? Etwas was bei solchen Tests eher selten berücksichtigt wird.
Ergänzung ()
https://www.computerbase.de/2017-10/wolfenstein-2-benchmark-async-compute/
Auch wenn es ein Vulkan und kein DX12 Spiel ist.
Ergänzung ()
Und noch etwas zu Sniper Elite 4...
http://www.pcgameshardware.de/Sniper-Elite-4-Spiel-56795/Tests/Direct-X-12-Benchmark-1220545/
Zuletzt bearbeitet von einem Moderator:
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
Okay, Cherry Picking, aber die Cherrys existieren oder etwa nicht?
Vielleicht verdeutlichen dann die Resultate von Sniper Elite 4 und Time Spy das eine pauschale Generalisierung nicht möglich ist?
Oder blendet man das einfach aus?
Und die 2-5% die Vega dank AC unter Wolfenstein 2 gewinnt....
Ist es das, was einzig und alleine "HW DX12 Support" ausmacht?
Darf ich fragen, ob mich das Prädikat "Hardware DX12 Support" dann zu interessieren braucht?
Vielleicht verdeutlichen dann die Resultate von Sniper Elite 4 und Time Spy das eine pauschale Generalisierung nicht möglich ist?
Oder blendet man das einfach aus?
Und die 2-5% die Vega dank AC unter Wolfenstein 2 gewinnt....
Ist es das, was einzig und alleine "HW DX12 Support" ausmacht?
Darf ich fragen, ob mich das Prädikat "Hardware DX12 Support" dann zu interessieren braucht?
Zuletzt bearbeitet:
G
Genscher
Gast
Bearbeitet: Sinnlos noch zu Argumentieren.Locuza schrieb:
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
Okay, also da AMD vertex fetch über die CPU emuliert, kann ich jetzt wie du behaupten AMD unterstützt allgemein keine 3D-API, weil sie nicht alle Befehle der API über die GPU HW umsetzen?Genscher schrieb:
Es gilt doch schließlich die Regel, dass wenn HW-Support gegeben sein soll, es für ALLE Elemente der Menge gelten muss.
(Arseny ist ein Entwickler, der an FIFA gearbeitet hat, jetzt an Roblox; Sebastian war früher Rendering Lead by RedLynx, einer Ubisoft Tochter und arbeitet gerade an dem Indie Spiel Claybook; Axel Gneiting arbeitet bei id Software und hat an Doom und Wolfstein 2 + Vulkan mitgearbeitet und früher bei Crytek und der Crysis-Serie)
https://twitter.com/axelgneiting/status/959581984048762885
Das wäre völliger Schwachsinn, weil die praktische Realität nirgendwo die explizite Anforderung stellt, dass man jeden Befehl über die Hardware und in genau dieser Form lösen muss.
Jeder Hersteller löst die Befehle im Treiber und in der Hardware etwas unterschiedlich, es gibt Millionen von Befehlen und Anforderungen.
Wenn ein Hersteller eine API und deren Funktionen zu 73% auf der GPU berechnen lässt und ein anderer zu 78%, ergibt es Sinn zu behaupten das ein Hersteller die API über die HW unterstützt, der andere aber nicht?
Natürlich nicht und es ist unglaublich grotesk wie man das ganze Thema durch Schwarz/Weiß-Malerei abbilden möchte und sich an einer Funktionalität von Millionen aufhängt und das als Hardware-Support deklariert.
Wahnsinnig ist das.
Und das mit Cherrys, ich hätte natürlich lieber Fragen sollen wieso das Cherrys sind.
Letztendlich will ich nur wissen,wie das mit eurem Weltbild im Einklang steht.
PS: Natürlich ist es sinnlos zu argumentieren, wenn man keine gewichteten Argumente besitzt.
Und ich bin kein Nvidia Lobbyist, meine Argumente sind völlig IHV neutral, Intel unterstützt DX12 genauso über die Hardware, wie jedes DX12 fähige Device, da es kein Device gibt welches den Großteil der DX12 API auf der CPU berechnen lässt und nicht auf dem Device selber.
Die Regel ohne Async Compute existiere kein DX12 HW Support ist faktischer Unsinn.
Zuletzt bearbeitet:
