News Wochenrückblick: Nvidia mit Problemen in DirectX-12-WoW und bei HDR

[Locuza]

NUn ja, man schaue sich die Roadmaps an.
Zwischen Maxwell und Volta gabs nichts, erst als NV gemerkt hat was für eine Goldmine Maxwell ist kam Pascal mit einem Shrink und paar Anpassungen, wie der VR Shader und bessere Async Ausführung.
Und nach AMDs schwachen auftritt mit Vega unter DX11 tauchte langsam Turing auf.
Für mich ist das offensichtlich.
Wenn da keine Tensore Cores drin sind ist es imho. recht sicher das es Maxwellv3 wird, ich habe mich schon Mitte 2017 über die Leute amüsiert die glaubten NV würde in der jetzigen Situation nicht das selbe machen wie seiner Zeit Intel ohne Konkurrenz. Einfach nur Naiv wer es der Lederjacke abgekauft hat das "wir vollgas geben werden".

Pascal wurde vermutlich eingeschoben, weil Volta auf sich warten lies, ansonsten hätten sie ihn ja zuvor schon für den HPC-Markt releasen können, stattdessen kam der später und mit GP100 sogar ein exklusives Pascal-Design nur für HPC/Workstation-Kunden.

Und Turing kann nicht einfach etwas anderes darstellen, nachdem Vega enttäuscht hat.
Die Entwicklung eines Chips dauert Jahre, einfach die Pläne umstellen geht nicht.

Die aktuelle nVidia Generation kann nichts was neu und wichtig ist. Das sollte schon langen allen bekannt sein.
Viel wichtiger ist die "neue" Generation. Kann die dann wenigstens DX12 oder HDR?
Wenn der Laden so arbeitet wie Intel, dann eher nicht Kappa

Irgendwie "kann" die Nvidia Generation ja schon HDR und DX12, bloß kann man wohl selber nicht die richtige Formulierung treffen oder muss ständig mit Unsachlichkeit an der Leine spazieren gehen.

@Locuza
Nach deiner Beschreibung macht der Command Prozessor wohl genau das was Intels Software Losung macht, auf der ihre teilweise Umgehung der Unzulänglichkeiten von DX11 basiert. Ohne Umgehungsmöglichkeit gibt es auch keine Möglichkeit etwas vergleichbares einzuführen. Zudem ist die Zeit der reinen Fixed-Function-Units beim Rendervorgang schon lange vorbei, Stichwort Pixel- und Vertex Shader. Der Shader Part ist natürlich ebenfalls am Rendervorgang beteiligt denn die sind nicht umsonst programmierbar. Zudem, hast du dir das verlinkte Blockschaltbild mal angesehen? Die Textureneinheiten (TMU - Texture Mapping Unit) sind Teil der Compute Units, welche wiederum auch die Shader beinhalten. Die ROPs (Raster Operation Processor/Render Output Unit/Raster Operations Pipeline) hängen meines Wissens nach vor dem Speicher Controller und erzeugen die letztendlichen Pixel.

DX11 hat zwar schonmal was von Multithreading gehört aber letztendlich landet alles in einem primären Renderthread landet, deshalb giert das ja auch nach Einzelkern Leistung. Ist der dicht dann ist Feierabend, man kann Threads erzeugen wie man will und die GPU langweilt sich dennoch weil die Aufgaben nicht schnell genug abgearbeitet werden können. Das ist ein grundsätzliches Problem das mit den neuen APis aufgebrochen wurde. Das ist ja ein Grund warum sie ein vielfaches der Draw Calls von DX11 erzeugen können.

Intels Software Lösung?
Genauso wie bei AMD und Nvidia gibt es dort einen Command-Processor, der die Befehle von der CPU durch den Treiber aufnimmt.
Irgendwie scheint die Message nicht durchzukommen, dass es prinzipiell vom Work-Flow bei keinem Hersteller unterschiedlich abläuft, jedenfalls nicht in so einer Form wie die pauschale Behauptung "X-Hersteller hat Software-Scheduler, aber Y-Hersteller Hardware-Scheduler" propagieren möchte.

Mein Beitrag beim Rendervorgang hat nicht von reinen FF-Units gesprochen, sondern von Fixed-Units + Shader-Array.
Du kannst weder bei AMD, noch bei Intel und Nvidia einen Pixel/Vertex-Shader schreiben, ohne das FF-Units zum Einsatz kommen und möglicherweise die ALUs Däumchen drehen.
Und wie mein Beitrag eig. ebenfalls aussagen wollte, dass grundlegende DX11-Design macht Multithreading schwer, aber der Dreh- und Angelpunkt auf dem ich mich die ganze Zeit befinden möchte, ist bezüglich der Aussagen über mögliche Treiberarchitekturen und was angeblich nur bei einem Hersteller möglich ist oder bei einem nicht.

Das sollte wohl eher "Pascal mit Problemen in DirectX-12-WoW und bei HDR" heißen
Denn es wird schon an der Architektur liegen, was eben schwierig ist, das per Software wieder aufzufangen. Volta ist hier schon sehr anderes, der kann nämlich beispielsweise asnyc compute, was bei Pascal eben nicht funktioniert.

Pascal kann asynchron seine Aufgaben wechseln und managed auch Compute-Queues was man auch bei GPUView sieht.

 

[frkazid]

Also kommt AMD's schnellste Karte gerade mal an die 3. schnellste von Nvidia heran und verbraucht dabei fast doppelt so viel Strom: "https://www.golem.de/news/radeon-rx...-und-durstig-mit-potenzial-1708-127610-7.html", wird kochend heiß und kostet auch noch 150€ mehr.

Wieso genau sollte man sich für die Vega entscheiden?

Kochend heiß? Nö. Meine nicht. Gemütliche 75°C, und das auch nur weil ich das TempTarget bissle runter gestellt habe. Bei edit: 1350RPM 2000RPM.

150€ Teurer? Nö. Kostet ebenso wie die Custom 1080 um die 550€ (für ein ordentliches Kühldesign).

Nur gleichschnell wie die drittschnellste (eigentlich ja nur zweitschnellste. afaik ist die Titan keine "Gamerkarte". Wenn du sie schon dazuzählst fehlt dann aber die V) von nVidia? Jop. Dafür 200€ / 750€ (edit für die V: 2650€) günstiger.

Mal ehrlich: Möchtest du eigentl. ordentlich diskutieren?

Mehr als Polemik konnte ich von dir bei diesem Thema bisher nicht lesen.

 

[Wadenbeisser]

Intels Software Lösung?

Es war natürlich nvidias Software Lösung gemeint.

Pascal kann asynchron seine Aufgaben wechseln und managed auch Compute-Queues was man auch bei GPUView sieht.

Soweit mir bekannt ist aber nur dazwischen schieben und letztendlich seriell statt parallel abarbeiten.

 

[Locuza]

@Wadenbeisser
Bei Pascal scheint Nvidia nur einen 3D- oder Compute-Context pro SM laufen lassen zu können und die Verwaltung läuft entsprechend nicht so fein und flexibel wie bei AMD aus, aber wenn man sagt Pascal kann Async Compute nicht, dann liegt man im Prinzip falsch und meint eig. Pascal kann Async Compute nicht so wie GCN.

 

[owned139]

Kochend heiß? Nö. Meine nicht. Gemütliche 75°C, und das auch nur weil ich das TempTarget bissle runter gestellt habe. Bei edit: 1350RPM 2000RPM.

150€ Teurer? Nö. Kostet ebenso wie die Custom 1080 um die 550€ (für ein ordentliches Kühldesign).

Nur gleichschnell wie die drittschnellste (eigentlich ja nur zweitschnellste. afaik ist die Titan keine "Gamerkarte". Wenn du sie schon dazuzählst fehlt dann aber die V) von nVidia? Jop. Dafür 200€ / 750€ (edit für die V: 2650€) günstiger.

Mal ehrlich: Möchtest du eigentl. ordentlich diskutieren?

Mehr als Polemik konnte ich von dir bei diesem Thema bisher nicht lesen.

Die 1080 von Gigabyte liegt bei unter 500€ und die günstigste Vega liegt bei 570:
https://geizhals.de/?cat=gra16_512&sort=p&xf=653_AMD~9809_14+10215+-+RX+Vega+64
https://geizhals.de/?cat=gra16_512&sort=p&xf=653_AMD~653_NVIDIA~9810_7+8228+-+GTX+1080

Die 1080 ist Kühler, hat mehr übertaktungsspielraum, frisst VIEL weniger Strom, ist günstiger und wesentlich performanter bei singlethreaded Spielen. Bei allen anderen Games nehmen die beiden sich nicht viel.
Nenn mir einen einzigen Grund, warum ich mich für AMD entscheiden sollte.

Btw. gibt es ja noch die Titan Pascal, welche ebenfalls schneller ist und definitiv eine Gamerkarte, auch wenn Nvidia sie nicht als solche bewirbt. Somit wäre es dann sogar nur Platz 4 für AMD.

 

[frkazid]

Freesync.

Edit: Auch wenn ich sonst persönliche Präferenzen beim Diskutieren außer acht lasse, hab ich mich nach dem GTX970-Debakel (hab das Ding selbst am Releasetag gekauft ) persönlich von nVidia verabschiedet. Da bleibt mir nur AMD.

 

[Micha Go.]

Ich bin ein wenig verwirrt... Hier wird über Performance eines 14 Jahre alten Spiels, auf komplett übertriebener Hardware gefachsimpelt. Das Game war schon immer nur etwas für - sagen wir mal, etwas einfacher gestricktere Menschen. Aber die ganze Diskussion hier lässt mich ein wenig an der geistigen Verfassung einiger Forenten zweifeln. Ihr zockt tatsächlich sowas auf fetten Rechnern mit Flaggschiff-Grakas? Das ganze rennt doch auf jeder Discounter-Möhre...
Ich meine, klar, kann man sich ärgern, wenn man richtig Geld für Hardware ausgibt, und dann die S*****verlängerung nicht das hergibt, was man sich davon versprochen hat... Aber Wow? Echt jetzt? Voll der Massstab.
Bringt auch total viel hohe Fps zu haben.
Und ist auch voll das anspruchsvolle Spiel.
Aber ok. Jedem sein Hobby. Seh auch genug "Sportwagenfahrer" die zu blöd sind, den Reifendruck für 2 Runden Nordschleife anzupassen. Oder Smartphonebenutzer die mir partout nicht erklären können, warum ihr 1k€ Gerät besser ist als mein 200€ Gerät - und dann noch doof fragen was root/jailbreak heisst. Weitermachen! Ich schäme mich stellvertretend.

 

[owned139]

Ich bin ein wenig verwirrt... Hier wird über Performance eines 14 Jahre alten Spiels, auf komplett übertriebener Hardware gefachsimpelt. Das Game war schon immer nur etwas für - sagen wir mal, etwas einfacher gestricktere Menschen. Aber die ganze Diskussion hier lässt mich ein wenig an der geistigen Verfassung einiger Forenten zweifeln. Ihr zockt tatsächlich sowas auf fetten Rechnern mit Flaggschiff-Grakas? Das ganze rennt doch auf jeder Discounter-Möhre...
Ich meine, klar, kann man sich ärgern, wenn man richtig Geld für Hardware ausgibt, und dann die S*****verlängerung nicht das hergibt, was man sich davon versprochen hat... Aber Wow? Echt jetzt? Voll der Massstab.
Bringt auch total viel hohe Fps zu haben.
Und ist auch voll das anspruchsvolle Spiel.
Aber ok. Jedem sein Hobby. Seh auch genug "Sportwagenfahrer" die zu blöd sind, den Reifendruck für 2 Runden Nordschleife anzupassen. Oder Smartphonebenutzer die mir partout nicht erklären können, warum ihr 1k€ Gerät besser ist als mein 200€ Gerät - und dann noch doof fragen was root/jailbreak heisst. Weitermachen! Ich schäme mich stellvertretend.

Ich hab mir den Rechner doch nicht nur wegen Wow gekauft. WoW ist nur eines von vielen Spielen, welches allerdings ordentlich laufen soll, ansonsten macht eine Investition in Highend Hardware keinen Sinn.
Arma ist auch so ein Kandidat, welcher unter AMD schlecht performt.

 

[Iscaran]

@Locuza
Intel spricht aber in der von dir verlinkten Darlegung darüber dass man eben gerade nicht "via Software" die Probleme umgehen kann da dies z.T. an Overhead barrieren scheitert.

Seite 15: https://image.slidesharecdn.com/eff...12-on-intel-graphics-15-638.jpg?cb=1430328820

Ebenso die Slides davor - Intel spricht ja bereits die Thematik an dass "most GPU Vendors" (es gibt eigentlich eh nur 2 GPU Vendors, "most" wäre bei den Marktanteilen z.B. wenn nVidia das macht und AMD nicht) lieber CPU-Last erzeugen um GPU-Last besser verteilen zu können:
https://image.slidesharecdn.com/eff...-12-on-intel-graphics-5-638.jpg?cb=1430328820

Das Problem das man dabei erzeugt und das Intel auch auf dieser Folie nennt ist:
"Treiber erzeugen neue Threads die dann oft mit der Applikation in Konkurrenz/konflikt sind"
"Ermöglicht deshalb nur minimales Multithreading abgesehen von genau diesen 2 threads. Dem Treiber-Thread und dem Game-Thread (was effektiv der Main-Render-Thread). Das ist eben schon ein ziemliches DX11 limit in dem ganzen Konstrukt.
Durch den Gang zu DX12 ermöglicht man nun dem Developer dieser Thread-Struktur DIREKT selbst aufzubrechen...nur dass ermöglicht wirklich gutes Multithreading. So es denn "richtig" angewandt wird. Das kann man aber lernen (was derzeit geschieht).

Weiter zeigt Intel auch dass "zu komplexe" CPU/GPU optimierung, also ein manueller Versuch über den Treiber in die Abarbeitung der Befehle einzuwirken, eher kontraproduktiv ist und letztlich sehr oft zu noch mehr Overhead führt (und deswegen nicht sinnvoll applizierbar ist).

Ich vermute AMD hat dasselbe Problem (bei GCN) (und DX11). In DX11 kann man über den direkten Kontext leider nur eine bestimmte Parallelisierbarkeit erreichen. Was man umgeht indem Deferred Contexts eingebaut werden.
Aber die Deferred Contexts liefern nur unter bestimmten Vorraussetzungen gute Resultate. Und genau HIER versagt die Intel Hardware und wohl auch der AMD "Scheduler" aufbau.

Warum nVidia hier besonders gut dasteht ist in meinen Augen immer noch offen - aber die Beobachtung dass nVidia auch unter DX11 irgendwie mehr Worker Threads laufen hat und so das Main-Render-Thread limit "umschifft" ist einfach sichtbar wenn man mal GPU und CPU Auslastungsverläufe in Games vergleicht.

Die Quizfrage warum AMD das nicht "einfach" auch macht weil es wie du darlegst "prinzipiell" möglich ist bleibt aber weiterhin offen !
Vermutlich weil es "einfach" (im sinne von simpel) nicht geht mit GCN-Arch wegen des massiv parallelisierten Input-Systems - Grundsätzlich mag das gehen, aber zu lasten von noch mehr CPU Overhead der dann vermutlich erst Recht auf dem Treiber/Main-Render-Thread ins Limit läuft.

Schade dass ich keine ähnlich tiefgreifende Analyse der Command State Struktur bei AMD kenne wie die schöne Darstellung von dir wie das bei Volta anders als in Relation zu Pascal abläuft:

Falls du was kennen solltest könntest du das bitte linken.



------------------------------------------------
Bzgl. WoW und warum man auf DX12 umstellt....das ist ein Blick darauf dass Blizzard hier "noch mehr" machen möchte in Zukunft und man wohl aktuell einfach an die Grenzen stößt die man mit DX11 in der Engine umsetzen kann.

https://image.slidesharecdn.com/eff...-12-on-intel-graphics-4-638.jpg?cb=1430328820

Ergänzung (24. Juli 2018)

Nachtrag:
nVidia scheint also die Benutzung von Deferred Contexts zu schmecken, da sie der Treiber offenbar abfangen kann und in entsprechend sinnvolle Worker-Threads unterteilen kann.
Wie diese nette Darstellung von dir zeigt:
https://developer.nvidia.com/sites/...dev/docs/GDC_2013_DUDASH_DeferredContexts.pdf

Die Frage ist vermutlich warum kann AMD deferred Contexts nicht via Treiber Abfangen....irgendwas muss hier anders sein ?

Und hier kommt mir die Analyse von Ext3h in den sinn zur unterschiedlichen Nutzung von Compute Queues in nVidia und AMD/GCN:
http://ext3h.makegames.de/DX12_Compute.html
"Best case scenario for AMD is the absolute worst case scenario for Nvidia.
Both hardware vendors do profit from compute engine usage.
They achieve this by different means, but the potential gains are significant for both vendors."

Vermutlich trifft dies so auch auf die Verwendung von DX11 "an sich" bzw. das Zugrunde liegende Problem des einen vom Game erzeugten Command Buffers für DX11 zu...das was TOP ist für nVidia ist genau das was man GAR NICHT für AMD möchte.

Die Frage ist nun - wer hält sich in seiner Hardware-Realisierung mehr an das was DX11 machen WILL.

 

[Locuza]

Weiter zeigt Intel auch dass "zu komplexe" CPU/GPU optimierung, also ein manueller Versuch über den Treiber in die Abarbeitung der Befehle einzuwirken, eher kontraproduktiv ist und letztlich sehr oft zu noch mehr Overhead führt (und deswegen nicht sinnvoll applizierbar ist).

Ich vermute AMD hat dasselbe Problem (bei GCN) (und DX11). In DX11 kann man über den direkten Kontext leider nur eine bestimmte Parallelisierbarkeit erreichen. Was man umgeht indem Deferred Contexts eingebaut werden.
Aber die Deferred Contexts liefern nur unter bestimmten Vorraussetzungen gute Resultate. Und genau HIER versagt die Intel Hardware und wohl auch der AMD "Scheduler" aufbau.

Diese komplexe Optimierung ist aber ein allgemeines Thema und war nicht bezogen auf Deferred Contexts, sondern wie viel Aufwand Intels Treiber in die Überprüfung und Berechnung unterschiedlicher Dinge steckt.
Apps die schlecht geschrieben sind können dank mehr Treiberaufwand mehr GPU-Leistung herausholen, nur erhöht das den CPU-Overhead.
Da Intel keine dGPUs herstellt und CPU und GPU auf einem Chip sich das Strombudget teilen, hat man herausgefunden, dass der erhöhte CPU-Overhead vom Treiber in vielen Fällen dazu führt das die Leistung geringer ist, als wenn der Treiber simpler ausfällt und weniger Aufwand in die Analyse steckt.
Apps die schlecht geschrieben sind könnten Performance verlieren, aber das ist eine Kompromiss-Sache.

Bezüglich Deferred Contexts nennt auch Nvidia selber die Vor- und Nachteile und worauf man achten muss.
Es ist auch wie gesagt kein simples Thema, denn die Treiber funktionieren je nach Profil und dank Heuristiken je nach Spiel etwas anders.
Das ist dann eher eine Frage wie viele Ressourcen ein IHV in seinen Treiber stecken kann und wie gut er die Treiberimplementierung generell hinbekommt.
Und nicht allgemein die Sache von einem Scheduler auf der Hardware, denn welcher Hardware-Scheduler denn bitte? Es gibt nämlich etliche Hardware-Scheduler pro Chip an unterschiedlichen Stellen.
Der Command-Processor am Anfang nimmt auch nur stupide Befehle auf, der diktiert nicht wie man ihn befüllt.
Mich interessiert es auch nicht, ob zwei Kellner oder einer mir das Essen bringt, ich esse nur.
Wenn zwei Kellner schneller sind, kann ich unter Umständen schneller essen, wenn zwei Kellner sich gegenseitig die Beine stellen muss ich länger warten bis ich essen kann, in dem Fall wäre ein Kellner schneller.
Ich selber wäre aber nicht das Problem und genauso ist auch die Hardware sehr wahrscheinlich nicht das Problem, was die konkrete Treiberimplementierung angeht.

Bezüglich Volta und dem Scheduling.
In dem Paper wird aber nur über das SM-Scheduling berichtet, da weißt du auch wie das Scheduling bei GCN aussieht, was aber nicht API abhängig ist, so funktioniert die Hardware allgemein, egal ob OGL, DX11, OpenCL, Vulkan, CUDA oder was auch immer verwendet wird.

Bezüglich der Compute-Queue-Implementierung (ext3h Link) interessiert das auch im konkreten Fall nicht.
Wenn ein DX12/Vulkan-Spiel keine Compute-Queues verwendet, dann landen alle Draw/Dispatch-Befehle in einer Universal/3D-Queue bei jedem Herstellern und nach wie vor profitieren beide Hersteller massiv von DX12/Vulkan indem Fall, weil bei DX12/Vulkan keine aufwendigen Error/Hazard-Checks durchgeführt werden und das State-Managment wesentlich einfacher ausfällt, mitsamt der Möglichkeit Command-Lists über mehrere Threads zu befüllen, was nichts mit Hardware-Schedulern auf Seiten der GPU zu tun hat, sondern mit dem API-Design.

Und wie schon einmal erwähnt, konkret geht es darum DX11 konform zu sein.
Input und entsprechender Output sind spezifiziert, wie das ganze dazwischen berechnet und erreicht wird, ist nicht spezifiziert.
Es gibt kein Schiedsrichter der sagt Ergebnis X darf so nicht erreicht werden, wenn das Ergebnis wie spezifiziert das selbe ist.

 

[Wadenbeisser]

Ich vermute dass AMDs "Graphics command Prozessor" nicht genug Power hat um die Daten beim Rendern schnell genug aufzuarbeiten denn im GPGPU Bereich haben sie definitiv kein Problem damit ihre Leistung zu entfalten und mit steigender Taktfrequenz skalieren die GPUs durchaus mit. Bei steigender Komplexität sieht es beim Rendern hingegen eher schlecht aus.

 

[Locuza]

Das ist teilweise der Fall*, dass gilt aber viel mehr für DX12/Vulkan, als für DX11, weil bei DX12/Vulkan kannst du die GPU voll mit Befehlen zu knallen, nicht bei DX11/OGL, weil dir dort der CPU-Overhead um die Ohren fliegt.

* Bei GCN Gen 2 hat Oxide bei Star Swarm mit der Mantle API die Befehle gruppiert, denn einzeln kam der CP nicht hinterher.
Das hat bei Hawaii wenn ich mich an die Zahlen erinnere ungefähr 10-15% mehr GPU-Performance gebracht.
Aber neuere GCN GPUs haben möglicherweise einen stärkeren CP und unter DX11 werden die Befehle meist so gut wie möglich gruppiert.

 

[Iscaran]

@Locuza
warum steigt eigentlich die CPU-Last bei nVidia wenn man die Auflösung erhöht (von FullHD auf WQHD) fast den Faktor 2 an ?
https://www.tomshw.de/2018/07/17/th...-times-varianzen-speicher-und-cpu-auslastung/
EDIT: hier die direkt Links:
https://www.tomshw.de/2018/07/17/th...imes-varianzen-speicher-und-cpu-auslastung/6/
https://www.tomshw.de/2018/07/17/th...imes-varianzen-speicher-und-cpu-auslastung/7/

EDIT: Beide GPUS haben in FullHD 60FPS (frame cap)
Beide GPUS haben in WQHD ca 50FPS.
Schade dass THW hier nicht noch 4k getestet hat (und das ganze mit Vega/1080 anstelle von RX580/1060).

 

[Locuza]

Das weiß ich nicht, wenn man aber indirekt das Treiberverhalten beobachten möchte, dann müsste man unterschiedliche Spiele und unterschiedlich starke Hardware testen.
Dann könnte man sich ein besseres Bild davon machen.

 

[Wadenbeisser]

Steigt mit der Pixel Zahl auch die Anzahl an draw calls oder dergleichen?
Wenn ja dann wäre es nur logisch das die Last bei der Geforce mit steigender Auflösung steigt denn damit würde sich auch die CPU seitige Zuarbeit ihres Treiber Modells erhöhen.

 

[Iscaran]

Ja leider geben die wenigsten Reviewer solche Angaben wie in dem THW-Test.
Ich hatte zwar CB schon mehrfach gebeten so etwas in der Art zu machen bei den GPU und CPU Tests dann hätte man wenigstens mal Anhaltspunkte in einzelnen Games woran es liegt.

Die einzige Seite die ich noch kenne die CPU-Auslastungen mit angibt bei Games-Tests ist GameGPU.ru
Dort sieht man auch das nVidia Karten in der Regel auch eher eine "höhere" CPU Last haben, aber eben vor allem in DX11 deutlich besser Multithreaden als AMD Pendants.

Leider wird auch dort dann wieder nur mit 1er GPU der CPU-Lastbereich angegeben...manchmal fragt man sich echt warum Hardware-Redakteure nicht öfter mal solche Themen aufgreifen statt denn hundersten custom modell Test durchlaufen zu lassen.

Ergänzung (25. Juli 2018)

Wenn die Zahl der Draw Calls steigt müsste das aber auf BEIDEN GPUs zuschlagen ?

 

[Wadenbeisser]

Nicht wenn sie bei AMD ohne Zwischenschritte durchgereicht aber bei nvidia aber vom sogenannten Software Sheduler zusammengestaucht werden damit DX11 nicht an seinen Limitierungen erstickt.
Mit steigender Pixel Zahl wäre das dann bei AMD recht egal weil keine Zuarbeit seitens der CPU stattfinden.

 

[Locuza]

Facepalm @ Software-Scheduler.
Richtiges Meme ohne eine technisch fundierte Erklärung.

 

[Wadenbeisser]

Wie wäre es damit:
Daten für DX11 werden vom Treiber verändert/verfälscht (CPU Leistung wird für das Zusammenlegen/komprimieren verbraten) damit DX11 nicht an seinen Begrenzungen erstickt.
Oder kurz ausgedrückt, Software Sheduler.

 

[Locuza]

Also egal was der Treiber macht = Software Scheduler?
Treiber = Software-Scheduler?

Hat nur Nvidia einen Treiber?