Hill Ridge
Banned
- Registriert
- Mai 2018
- Beiträge
- 1.142
Warum sollte Volta für DX12 besser sein?
Volta ist doch nur Pascal (Maxwell 3.0) mit Tensor-Cores!
Volta ist doch nur Pascal (Maxwell 3.0) mit Tensor-Cores!
News Wochenrückblick: Nvidia mit Problemen in DirectX-12-WoW und bei HDR
- Ersteller Frank
- Erstellt am
- Zur News: Wochenrückblick: Nvidia mit Problemen in DirectX-12-WoW und bei HDR
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
Wenn Nvidia schwache DX11-Treiber ausliefern würde und DX12-Umsetzungen 10-20% Performanceboost bei Pascal liefern würde, würde ein Querschnitt an Forenusern Nvidia für tolle "DX12 Hardware" loben.Shrimpy schrieb:
Stattdessen sind es jetzt "DX11-Schleudern".
Aber mal ernsthaft, Nvidia ist aktuell beim Resource-Model nicht bestens für DX12/Vulkan aufgestellt, aber Volta meldet bei Vulkan im Schnitt kaum höhere Limits zurück, als Pascal.
Und so wie aktuelle DX12-Apps designed sind, würde selbst fähigere Hardware indem Aspekt zu keinem großen Unterschied führen.
Es gibt natürlich auch noch andere Dinge die interessieren könnten und bei Volta verbessert, aber bisher sieht man nur die zurückgemeldeten Limits vom aktuellen Treiber bei Titan V, dessen Ergebnisse und das Volta Conservative Rasterization Tier 3 unter DX12 unterstützt, (Pascal Tier 2, Maxwell v2 nur Tier 1).
Übrigens, woher weiß man das Turing Maxwell v3 sein sollte?
Wird dir deine wissentliche Propaganda nicht langweilig?Whiskey Lake schrieb:
Volta ist in mehreren Bezügen sehr unterschiedlich zu Pascal bis hin zu völlig neu.
Die ISA ist komplett anders, dass Cache-Design stark umgestellt und verbessert und mehr.
Hill Ridge
Banned
- Registriert
- Mai 2018
- Beiträge
- 1.142
Spiel dich nicht immer so auf!
Falsch.
Mir ziemlich egal, darum geht es gerade nicht.
Die ISA hat sich kaum geändert...
Palmdale
Captain
- Registriert
- Apr. 2009
- Beiträge
- 3.164
@Locuza
War eher auf den allgemeinen Trend bezogen, exemplarisch https://www.gamestar.de/artikel/das...nur-fuenf-spiele-veroeffentlicht,3323372.html
Selbst in diesen 5 Spielen isses mitunter suboptimal, ob des Aufwands zumindest fraglich, ob es sich lohnte. Verglichen mit 7.700 in 2017 veröffentlichten Spielen allein auf Steam quasi nicht existent
War eher auf den allgemeinen Trend bezogen, exemplarisch https://www.gamestar.de/artikel/das...nur-fuenf-spiele-veroeffentlicht,3323372.html
Selbst in diesen 5 Spielen isses mitunter suboptimal, ob des Aufwands zumindest fraglich, ob es sich lohnte. Verglichen mit 7.700 in 2017 veröffentlichten Spielen allein auf Steam quasi nicht existent
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
Sagt mir der Typ der sich wohl über 4 neue Accounts bei PCGH anlegen musste, weil er immer wieder für seine haltlosen Behauptungen und das ständige Wiederholen von Unwahrheiten gebannt wurde, trotz eindeutiger Widerlegungen.Whiskey Lake schrieb:
https://arxiv.org/pdf/1804.06826.pdfSeite 2 schrieb:
In der PDF wird noch genau ausgeführt, wie das Instruction-Encoding bei den Architekturen im Vergleich aussieht.
Daneben arbeitet die Main-ALU auch die meisten Instruktionen in 4-Zyklen durch, wie AMDs GCN, Maxwell/Pascal haben 6-Zyklen gebraucht, Kepler war bei 9 und Fermi gar bei ~20.
Daneben ist das veränderte Cache-Design auch nicht ziemlich egal, wenn du pauschal Volta nur als einen Maxwell/Pascal mit Tensor-Cores darstellen möchtest.
Da macht man sich die Betrachtung aber zu einfach, da man nur zwei Jahre miteinander vergleicht und nicht jedes Jahr die gleiche Anzahl an AAA-Games pro Publisher/Studio mit X-Engine herauskommen.Palmdale schrieb:
Da von einem Trend zu reden ist völlig fehl am Platz.
Dagegen gibt es etliche Gründe für eine bessere DX12/Vulkan-Verbreitung in naher Zukunft.
Es gibt deutlich bessere DX12/Vulkan-Tools wie zuvor bzw. überhaupt, wie der relativ neue RadeonGPU-Profiler von AMD, ein Profiler and neues Crash-Tool von Nvidia mit Nsight Graphics und Aftermath und von Microsoft Pix.
Alle Werkzeuge machen es zusammen mit den verbesserten Validation-Layern und API/OS-Updates einfacher stabilere und performantere Spiele zu entwickeln.
DICE und Ubisoft haben mit FrameGraphs/Task-Graphs auf der GDC neue Render-Architekturen präsentiert, um grundlegend von den neuen API zu profitieren, nur wird das leider noch nicht verwendet, da noch nicht fertig bzw. die Spieleentwicklung nicht auf die neusten Versionen aufsetzen kann, wenn ein Release naht.
UE4 und Unity machen beide ständige Fortschritte bei der Render-Architektur, bei UE4 denkt man auch darüber nach für Linux die Default-Einstellung von OGL4.3 auf Vulkan zu wechseln.
Ebenso bei Android, es gibt mehrere Vulkan-Spiele für Android und Initiativen von Samung/Google bei der Umsetzung und Entwicklung zu helfen.
Zuletzt bearbeitet:
(weiteren Beitrag zitiert.)
W
Wadenbeisser
Gast
@Locuza
Wenn ich mir das GCN Blockschaltbild so ansehe gibt es aber keine getrennte Verarbeitung von Compute und Grafik Aufgaben, die ACEs sorgen lediglich für eine bessere Auslastung wenn mehrere Aufgaben gleichzeitig durch sollen, Stichwort Asyc Compute. Auch sehe ich nicht wo in die Lastverteilung seitens des Treibers eingegriffen werden könnte um zu einem Ergebnis wie bei nvidia zu kommen denn so wie ich das sehe AMDs "Global Data Share" mit nvidias "GigaThread Engine" vergleichbar und der gesammte obere Teil (ACE, Graphics command Prozessor) ist bei nvidia nicht existent und dürfte der Part sein der von nvidia per Software gefüttert wird. Du müsstest also den kompletten "Graphics command Prozessor" und vermutlich auch die ACEs umgehen. Ist das überhaupt in der Hardware vorgesehen?
http://www.3dcenter.org/dateien/abbildungen/AMD-Radeon-RX-480-Blockschaltbild.jpg
https://pics.computerbase.de/6/0/1/2/3/9-1080.2238304950.png
Wenn ich mir das GCN Blockschaltbild so ansehe gibt es aber keine getrennte Verarbeitung von Compute und Grafik Aufgaben, die ACEs sorgen lediglich für eine bessere Auslastung wenn mehrere Aufgaben gleichzeitig durch sollen, Stichwort Asyc Compute. Auch sehe ich nicht wo in die Lastverteilung seitens des Treibers eingegriffen werden könnte um zu einem Ergebnis wie bei nvidia zu kommen denn so wie ich das sehe AMDs "Global Data Share" mit nvidias "GigaThread Engine" vergleichbar und der gesammte obere Teil (ACE, Graphics command Prozessor) ist bei nvidia nicht existent und dürfte der Part sein der von nvidia per Software gefüttert wird. Du müsstest also den kompletten "Graphics command Prozessor" und vermutlich auch die ACEs umgehen. Ist das überhaupt in der Hardware vorgesehen?
http://www.3dcenter.org/dateien/abbildungen/AMD-Radeon-RX-480-Blockschaltbild.jpg
https://pics.computerbase.de/6/0/1/2/3/9-1080.2238304950.png
O
owned139
Gast
http://www.guru3d.com/articles_page...x_1080_fcat_frametime_analysis_review,17.html (FE vs Vega)frkazid schrieb:
Custom 1080 vs Vega 64:
Wenn die Foundersedition schon gleich auf zur Vega ist, dann werden die Customs wohl logischerweise ne Ecke schneller sein.
S
Shrimpy
Gast
Locuza schrieb:
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".
@Wiskey Lake
NV hat die Marktmacht um RTX, was auf Tensore läuft, durch zu drücken.
GPGPUs sind mit nichten ungeeignet für Echtzeitgrafik Berechnungen.
Der Games-markt ist am PC ja auch zu 95% DX11 seid 10 Jahren, und Maxwell bringt darauf gut Leistung.
Zuletzt bearbeitet von einem Moderator:
Locuza
Lieutenant
- Registriert
- Dez. 2010
- Beiträge
- 570
@Wadenbeisser
CP und ACEs sind im Prinzip nur die Manager für anstehende Aufgaben.
Die Befehle werden dann von den entsprechenden Units ausgeführt.
Bei 3D-Aufgaben kommen irgendwelche Fixed-Function-Hardwareblöcke in Spiel, sei es Rasterizer, Geometry-Engines oder ROPs + Shader-Array, hier spielt nur der CP und die 3D-Queue mit rein, die ACEs haben keinen direkten Zugriff auf die Graphics-Pipe.
Bei Compute-Aufgaben kommt praktisch nur das Shader-Array zum Einsatz, Compute-Queues kann der CP verwalten und auch die ACEs.
Mehrere Compute-Queues können der Hardware helfen Aufgaben feiner und unabhängig zu verteilen.
Es hilft besonders in Kombination mit 3D-Berechnungen bei Spielen, denn nicht alle 3D-Aufgaben lasten zu jeder Zeit alle Teile vom Chip aus, manchmal muss man auf den Rasterizer oder die ROPs warten und die ALUs drehen Däumchen.
Mit einer zusätzlichen Compute-Queue kann der Chip bei idle-phasen Befehle aus der Compute-Queue ausführen.
Bei DX11 kommt eine massive Maschinerie zum Einsatz, wo der Treiber unzählige Aufgaben löst.
Da wird auf Fehler und unterschiedliche Abhängigkeiten überprüft, die richtigen States gesetzt, die Speicherverwaltung umgesetzt und letztendlich die Befehle an die GPU abgeschickt und entsprechende Queues/Command-Buffer befüllt.
AMDs Treiber hat theoretisch die Möglichkeit den Befehlsstrom zu analysieren und zu schauen, welche Aufgaben eig. der Treiber in eine Compute-Queue packen könnte und von der GPU dann asynchron ausgeführt.
Das wäre aber dazu da die GPU-Performance zu erhöhen, je nach Aufwand auf der CPU-Seite könnte es den Treiberoverhead erhöhen.
Bezüglich der allgemeinen Threadskalierung hat AMD gewiss die Möglichkeit unter DX11 unterschiedliche Aufgaben auf mehrere Threads zu verteilen.
Das Problem sollte hauptsächlich im Aufwand stecken das Ganze auch wirklich mit einem Performancevorteil umzusetzen, wo letztendlich auch alles korrekt abläuft.
Und nein, es wäre gar nicht möglich den CP zu umgehen, der CP nimmt die Befehle von der CPU auf und steuert zu Beginn die GPU und die Anweisungen hier muss man eine Sachen verstehen.
Der Treiber dröselt API-Befehle auf, übersetzt noch entsprechende Programmiersprachen in die entsprechende Maschinensprache für die GPU und schickt ein Command-Package ab, welche die GPU aufnimmt und den Rest berechnet.
Und wie das Command-Package letztendlich erstellt wurde interessiert die GPU nicht.
Das State-Model macht es unter DX11 schwer multithreading umzusetzen, aber letztendlich befüllt man wie unter DX12 ein Command-Package welches von der GPU ausgeführt wird.
Ob AMD's Treiber 1 oder 3 Threads verwenden würde, um einen Command-Buffer abzuschicken würde die GPU nicht tangieren, aber dazu führen das der Mainthread wie unter DX12 (nur bei weitem nicht auf dem selben Level) weniger Zeit benötigt und entsprechend weniger auf die CPU gewartet werden muss.
Und da habe ich noch keine schlüssige Ansicht gelesen, wieso AMD wegen ihrer Hardware das nicht umsetzen könnte.
Intel hat eine gute High-Level-Übersicht zu DX11 vs. DX12 präsentiert:
https://www.slideshare.net/GaelHofemeier/efficient-rendering-with-directx-12-on-intel-graphics
Auf Seite 15 wird auch grob erwähnt, wieso man nicht Deferred Contexts umgesetzt hat bzw. Command-Lists über mehrere Threads, da es keine triviale Aufgabe ist und an gewissen Stellen zu mehr Overhead führt durch State-Abhängigkeiten unterschiedlicher Command-Lists und am Ende sowieso der Immediate-Context den Command-Buffer abschicken muss.
Es gab die PDF als Videopräsentation, aber den Link zu finden (wurde nur irgendwo bei Intel gehostet), falls er überhaupt noch existiert, ist mir gerade nicht möglich.
Nvidia dagegen konnte gute Ergebnisse unter Spielen wie Civ5 und AC3 (24% bei einer 680) erzielen:
https://developer.nvidia.com/sites/...dev/docs/GDC_2013_DUDASH_DeferredContexts.pdf
Da muss man aber unterschiedliche Fälle unterscheiden, wie der Treiber allgemein funktioniert und wie er funktioniert wenn ein Spiel Deferred Context verwendet und es gibt mehrere Stellschrauben, wo die Treiber explizite Spieleprofile haben und unterschiedliche Dinge umsetzen und eine Heuristik nach Mustern schaut und entsprechend agiert, entsprechend gibt es keine konsistenten Ergebnisse von Anwendung zu Anwendung.
-----
Der GDS bei AMD ist etwas total anderes, dass ist ein 64KB kleiner Speicher, der für die Synchronisation gewisser Operation über alle CUs zuständig sein kann.
Die GigaThread-Engine arbeitet dagegen prinzipiell ganz ähnlich wie bei AMD der CP/ACEs bzw. nach Nvidias Nomenklatur gibt es noch den CWD (Cuda Work Distributor) und die GMU (Grid Management Unit), alles Hardware-Scheduler die sich explizit um die Verwaltung mehrerer 3D/Compute-Queues kümmern und der Threadverteilung auf die Compute-Units.
ATI bzw. AMD hatte in alten Schaubildern auch noch von einem Ultra-Threaded-Dispatch-Processor geredet, so etwas wird nicht mehr eingezeichnet.
https://pics.computerbase.de/3/2/1/0/6/36-1080.3340947470.jpg
CP und ACEs sind im Prinzip nur die Manager für anstehende Aufgaben.
Die Befehle werden dann von den entsprechenden Units ausgeführt.
Bei 3D-Aufgaben kommen irgendwelche Fixed-Function-Hardwareblöcke in Spiel, sei es Rasterizer, Geometry-Engines oder ROPs + Shader-Array, hier spielt nur der CP und die 3D-Queue mit rein, die ACEs haben keinen direkten Zugriff auf die Graphics-Pipe.
Bei Compute-Aufgaben kommt praktisch nur das Shader-Array zum Einsatz, Compute-Queues kann der CP verwalten und auch die ACEs.
Mehrere Compute-Queues können der Hardware helfen Aufgaben feiner und unabhängig zu verteilen.
Es hilft besonders in Kombination mit 3D-Berechnungen bei Spielen, denn nicht alle 3D-Aufgaben lasten zu jeder Zeit alle Teile vom Chip aus, manchmal muss man auf den Rasterizer oder die ROPs warten und die ALUs drehen Däumchen.
Mit einer zusätzlichen Compute-Queue kann der Chip bei idle-phasen Befehle aus der Compute-Queue ausführen.
Bei DX11 kommt eine massive Maschinerie zum Einsatz, wo der Treiber unzählige Aufgaben löst.
Da wird auf Fehler und unterschiedliche Abhängigkeiten überprüft, die richtigen States gesetzt, die Speicherverwaltung umgesetzt und letztendlich die Befehle an die GPU abgeschickt und entsprechende Queues/Command-Buffer befüllt.
AMDs Treiber hat theoretisch die Möglichkeit den Befehlsstrom zu analysieren und zu schauen, welche Aufgaben eig. der Treiber in eine Compute-Queue packen könnte und von der GPU dann asynchron ausgeführt.
Das wäre aber dazu da die GPU-Performance zu erhöhen, je nach Aufwand auf der CPU-Seite könnte es den Treiberoverhead erhöhen.
Bezüglich der allgemeinen Threadskalierung hat AMD gewiss die Möglichkeit unter DX11 unterschiedliche Aufgaben auf mehrere Threads zu verteilen.
Das Problem sollte hauptsächlich im Aufwand stecken das Ganze auch wirklich mit einem Performancevorteil umzusetzen, wo letztendlich auch alles korrekt abläuft.
Und nein, es wäre gar nicht möglich den CP zu umgehen, der CP nimmt die Befehle von der CPU auf und steuert zu Beginn die GPU und die Anweisungen hier muss man eine Sachen verstehen.
Der Treiber dröselt API-Befehle auf, übersetzt noch entsprechende Programmiersprachen in die entsprechende Maschinensprache für die GPU und schickt ein Command-Package ab, welche die GPU aufnimmt und den Rest berechnet.
Und wie das Command-Package letztendlich erstellt wurde interessiert die GPU nicht.
Das State-Model macht es unter DX11 schwer multithreading umzusetzen, aber letztendlich befüllt man wie unter DX12 ein Command-Package welches von der GPU ausgeführt wird.
Ob AMD's Treiber 1 oder 3 Threads verwenden würde, um einen Command-Buffer abzuschicken würde die GPU nicht tangieren, aber dazu führen das der Mainthread wie unter DX12 (nur bei weitem nicht auf dem selben Level) weniger Zeit benötigt und entsprechend weniger auf die CPU gewartet werden muss.
Und da habe ich noch keine schlüssige Ansicht gelesen, wieso AMD wegen ihrer Hardware das nicht umsetzen könnte.
Intel hat eine gute High-Level-Übersicht zu DX11 vs. DX12 präsentiert:
https://www.slideshare.net/GaelHofemeier/efficient-rendering-with-directx-12-on-intel-graphics
Auf Seite 15 wird auch grob erwähnt, wieso man nicht Deferred Contexts umgesetzt hat bzw. Command-Lists über mehrere Threads, da es keine triviale Aufgabe ist und an gewissen Stellen zu mehr Overhead führt durch State-Abhängigkeiten unterschiedlicher Command-Lists und am Ende sowieso der Immediate-Context den Command-Buffer abschicken muss.
Es gab die PDF als Videopräsentation, aber den Link zu finden (wurde nur irgendwo bei Intel gehostet), falls er überhaupt noch existiert, ist mir gerade nicht möglich.
Nvidia dagegen konnte gute Ergebnisse unter Spielen wie Civ5 und AC3 (24% bei einer 680) erzielen:
https://developer.nvidia.com/sites/...dev/docs/GDC_2013_DUDASH_DeferredContexts.pdf
Da muss man aber unterschiedliche Fälle unterscheiden, wie der Treiber allgemein funktioniert und wie er funktioniert wenn ein Spiel Deferred Context verwendet und es gibt mehrere Stellschrauben, wo die Treiber explizite Spieleprofile haben und unterschiedliche Dinge umsetzen und eine Heuristik nach Mustern schaut und entsprechend agiert, entsprechend gibt es keine konsistenten Ergebnisse von Anwendung zu Anwendung.
-----
Der GDS bei AMD ist etwas total anderes, dass ist ein 64KB kleiner Speicher, der für die Synchronisation gewisser Operation über alle CUs zuständig sein kann.
Die GigaThread-Engine arbeitet dagegen prinzipiell ganz ähnlich wie bei AMD der CP/ACEs bzw. nach Nvidias Nomenklatur gibt es noch den CWD (Cuda Work Distributor) und die GMU (Grid Management Unit), alles Hardware-Scheduler die sich explizit um die Verwaltung mehrerer 3D/Compute-Queues kümmern und der Threadverteilung auf die Compute-Units.
ATI bzw. AMD hatte in alten Schaubildern auch noch von einem Ultra-Threaded-Dispatch-Processor geredet, so etwas wird nicht mehr eingezeichnet.
https://pics.computerbase.de/3/2/1/0/6/36-1080.3340947470.jpg
Zuletzt bearbeitet:
Hill Ridge
Banned
- Registriert
- Mai 2018
- Beiträge
- 1.142
Du hast dich verzählt, du müßtest eigentlich Maxwell 4 meinen, weil für dich Pascal ja schon 3 ist
Hardware_Hoshi
Lt. Commander
- Registriert
- Jan. 2008
- Beiträge
- 1.481
Locuza schrieb:
Würde ich so nicht sagen. DX12 bedeutet unter anderem Zwang zu Windows 10, welches sich trotz jahrelangem Release am Markt immer noch nicht richtig durchsetzt. Das ist eine weitere wichtige Kette in der Gleichung.
Es nutzt auch nichts wie toll irgendwelche Hardware DX12 unterstüzten würde. Letztendlich macht die Optimierungsartbeit und der geschriebene Gamecode der Entwickler den Unterschied.
Bei DX12 sind diese 10-20% Performanceboost jedoch mit einer heiden Arbeit und somit zustäzlichen Kosten verbunden. Blizzard hat das lediglich gemacht um WoW vielleicht weitere 1-2 Jahre über Wasser zu halten.
Die größer werdende Anzahl an Goodies steigt stetig. Neuerdings gibt Blizz sogar die Addons kostenlos für Abonennten raus, nur damit irgendwie die Spielerzahlen gehalten werden kann.
Locuza schrieb:
Das mit dem Cache-Design wollte ich gerade sagen. Dazu deutliche Änderungen im Scheduling, das nun "independent" per jedem einzelnen Shader läuft. Dies alleine ist eine Fähigkeit, die kein Maxwell oder Pascal jemals konnte.
Volta kann all diese Dinge seit längerem. Die nächste Gaminggeneration wird darauf sicher aufbauen. Etwas anderes zu behaupten geht wie gesagt in die Propaganda-Ecke. Gut, dass du das erwähnt hast, @Locuza !
Bei WoW machen alle diese Änderungen wahrscheinlich nichts bringen. Die jahrelangen Anpassungen an DX11 wird DX12 wohl niemals erreichen. Die Lebenszeit des MMO ist mit bald über 14 Jahren mehr als ausgeschöpft. Ewig wird das Spiel nicht mehr leben.
G3cko schrieb:
Ich will dich nicht angreifen, aber das was du in deinem Beitrag schreibst ist zum allergrößten Teil nur eine Verschwörungstheorie, bzw das mit dem Hardware vs Software Scheduler völliger Blödsinn.
Der letzte Satz hier treibt es auf die Spitze. Wenn du wüsstest was eine low level API ist, dann würdest du nicht behaupten dass eine solche sich bei mehr Herstellern schneller etabliert.
Genau das krasse Gegenteil wird der Fall sein. Mehr Hersteller --> mehr Extrawürste, deutlich mehr Eigenheiten auf die geachtet werden muss.
Wie kommt man denn nur auf sowas?
AYAlf
Commodore
- Registriert
- Apr. 2005
- Beiträge
- 4.370
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
Viel wichtiger ist die "neue" Generation. Kann die dann wenigstens DX12 oder HDR?
Wenn der Laden so arbeitet wie Intel, dann eher nicht Kappa
W
Wadenbeisser
Gast
@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.
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.
owned139 schrieb:
Ja und von Vega gibts keine Customs?
https://www.hardwareluxx.de/index.p...-radeon-rx-vega-64-nitro-im-test.html?start=8
Die Karten sind einfach mal genau gleich. Darum stehen sie auch in Konkurrenz zueinander.
Und wenn du jetzt gleich mit Ausreiserbenchmarks kommst. Das kann ich auch
Edit: Jetzt schau ich gerade nochmal bei guru3d und bin erstaunt. Die vergleichen ja auch Custom vs. FE. Ist ja genauso ein beschissener Vergleich wie das von dir verlinkte YT-Video. Dann Schande auf mein Haupt.
https://hexus.net/qadoro
Hier wird anstelle von "Custom GTX1080" wie bei HWLuxx wenigstens das Modell angegeben.
Zuletzt bearbeitet:
Ich erreiche keine 60FPS mehr auf meinem Laptop durch die Änderung sondern gammel um die 20-35FPS vor mich hin. Ich hatte mit einer Intel UHD630 vor de Patch stabile 60FPS auf low settings. 1A... WoW ist quasi nicht mehr spielbar auf einem Laptop. Der Laptop hat übrigens auch eine GTX1050Ti und mit dieser erreiche ich auch nur noch um die 45FPS. Scheinbar mag iGPU und Optimus kein non fullscreen mode. Kann das jemand bestätigen?
Zuletzt bearbeitet:
O
owned139
Gast
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.frkazid schrieb:Ja und von Vega gibts keine Customs?
https://www.hardwareluxx.de/index.p...-radeon-rx-vega-64-nitro-im-test.html?start=8
Widde widde witt und so?
Die Karten sind einfach mal genau gleich. Darum stehen sie auch in Konkurrenz zueinander.
Und wenn du jetzt gleich mit Ausreiserbenchmarks kommst. Das kann ich auch
Edit: Jetzt schau ich gerade nochmal bei guru3d und bin erstaunt. Die vergleichen ja auch Custom vs. FE. Ist ja genauso ein beschissener Vergleich wie das von dir verlinkte YT-Video. Dann Schande auf mein Haupt.
https://hexus.net/qadoro
Hier wird anstelle von "Custom GTX1080" wie bei HWLuxx wenigstens das Modell angegeben.
Wieso genau sollte man sich für die Vega entscheiden?
Cl4whammer!
Lt. Commander
- Registriert
- Aug. 2008
- Beiträge
- 1.899
Ich bin ja mal gespannt was nach HDR das nächste Marketing Buzzword wird.
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.
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.
Nein, wohl eher alle GPUs. Die WoW Foren sind voller Hass. Ich bekomm nur noch 35FPS wo ich vorher 60FPS hatte mit meiner Intel GPU aufm Laptop.HOT schrieb: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.
