Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
TestForza 7 Benchmark: Vega hat mehr Benzin im Blut als Pascal
Ich würde noch einen Schritt weiter gehen und sagen, dass UWP-Spiele-"Apps" generell nichts in Benchmark-Parcours verloren haben sollten, da dieser unsägliche Microsoft-Schwachsinn mit all seinen Einschränkungen keinerlei Unterstützung jedweder Art verdient hat.
Wenn das scheduling bei AMD in Hardware bei DX 11/12 stattfindet und bei Nvidia über Software einer CPU überlassen wird, dann sollte klar sein, warum in einem reinen DX 12 Spiel bei Nvidia, wo die API die Verteilung der Last übernehmen sollte, plötzlich solche Resultate zu Tage fördert.
War das schließlich nicht genau die Funktion von DX 12 wo die Asynchronous Compute Engine greifen soll und die Last optimal auf die Shader verteilt ?
@Wadenbeisser @aivazi
Mit meinem Kommentar habe ich mich nicht gegen einen möglichen Inhalt gestellt sondern gegen eine unbegründete sinnfreie Antwort.
Ihr beide habt Gründe genannt bzw. Detailliert dargelegt warum x anders ist als y.
Die Person die ich Zitiert habe nicht. Sie hat sich nicht mal die mühe gemacht überhaupt was brauchbares von sich zu geben.
- Genauso wie @LyGht
Wer kam eigentlich auf die Bezeichnung "Frametimes in FPS"? Frametimes sind, wie das Wort schon sagt, Zeiten und die werden in ms angegeben. Wäre auch kein Problem hier einfach die ms Werte anzugeben.
Aber natürlich sind die FPS Werte besser verständlich, nur sind es dann keine Frametimes mehr.
Ich benutze für die Leistung eines Gerätes ja z.B. auch Watt und für dessen Stromaufnahme Ampere.
Und genau deshalb ist AMD in DX12 stärker, weil das was die GPU bei Nvidia macht, mit der DX12 API keinen Nutzen mehr hat, da der Scheduler komplett auf DX11 optimiert ist, wohingegen AMD hier deutlich von der Parallelisierung profitiert.
Bei Nvidia Pascal muss der Treiber/Hardware dass Scheduling übernehmen weil die Pipeline kein Asynchronous Shaders beherrscht. Wenn mehrere Tasks anliegen kann Pascal diese nur linear nacheinander abarbeiten. Daher kann Nvidia das Scheduling nicht der Anwendung überlassen. Diese sehr eigenartige implementierung wurde mit Pascal aber zumindest deutlich verbessert, weil das umschalten zwischen mehreren Tasks deutlich flotter Erfolg als beim DX12 Entschleuniger Maxwell.
Btw wurde der Artikel aktualisiert, was ist bitte 99th Percentile (Frametimes in FPS)?!?
Ich kenne bisher nur 99th percentile in Millisekunden. Wie stellt man bitteschön Frametimes in FPS dar und was soll das?
Richtig.
In anderen Worten: weil AMD zu dämlich war, einen anständigen HW-Scheduler in der GPU zu implementieren muss das jetzt auf Software-Ebene erledigt werden.
Wie heißt nochmal die Firma, die immer mit gigantischen GFlop-Werten protzt und diese niemals in der Praxis umsetzen konnte?
AC ist nichts anderes als ein Workaround für den beschissenen Scheduler in AMD-GPUs.
Ergänzung ()
tek9 schrieb:
Bei Nvidia Pascal muss der Treiber/Hardware dass Scheduling übernehmen.
Was heißt hier "muss"? Das sollte der Normalfall sein! Das Management der GPU-Funktionseinheiten muss die GPU selber übernehmen, denn die kann das am besten.
^^Du bist nicht mehr auf dem Stand der Dinge. In DX12 übernimmt die Anwendung die meisten Aufgaben des Treibers. Das nennt sich hardwarenahe Programmierung
Da Maxwell/Pascal aber nur ein DX11 Chip mit reingepatchtem DX12 Features ist, muss Nvidia wiederum ran und die Limitierung der Hardware mittels Treiber fixen.
Ich bin schon auf dem Stand der Dinge.
Das macht ja die Dx12 Programmierung so extrem kompliziert und fehleranfällig. Wo soll da der Vorteil ggü. anderen APIs sein? Nicht umsonst wird auch DX11 immer noch weiter entwickelt. Derzeit ist 11.4 aktuell.
Ich bin schon auf dem Stand der Dinge.
Das macht ja die Dx12 Programmierung so extrem kompliziert und fehleranfällig. Wo soll da der Vorteil ggü. anderen APIs sein? Nicht umsonst wird auch DX11 immer noch weiter entwickelt. Derzeit ist 11.4 aktuell.
Also auf gut Deutsch solange NV ihren rückständige Pascal Architektur verkauft, kommen wir weder bei den APIs noch bei anständigem CPU Mehrkernsupport weiter.
@Kisser
Du bist auf dem Holzweg AMD macht das Sheduling in Hardware, NV in Software.
DX11 ist so ausgelegt, dass der Mainthread auf einem Kern Drawcalls erzeugt.
NV konnte das clever im Treiber lösen und die Drawcalls hauptsächlich auf 2-4 Threads aufteilen.
Das geht bei AMDs Hardware Sheduler nicht.
oder er müsste derart angepasst werden, dass NVs DX11 Implementierung in Hardware gemacht werden könnte, was nicht einfach zu lösen ist und am Ende der DX11 Ära auch nicht besonders sinnvoll ist.
Da der Prozessor damit das Sheduling macht, hat NV falls alle Kerne gut belastet sind, mehr Overhead als AMD.
Und natürlich auch bei DX12 und Vulkan Games hat NV da einen Nachteil, da dort viel mehr Kerne von Haus aus belastet sind.
Das ist alles noch ohne Async und sonstige Next Gen Features.
Daher stimmt die Aussage durchaus, dass AMD schon lange DX12 und NV eben DX11 Karten baut.
Sieh dir das verlinkte Video an und verstehe es.
Da NV eben Budget hat, kann man mit Gameworks Einfluss auf die Enginebastler nehmen und bleibt solange wie möglich auf dem Steinzeit DX11.
Somit muss man sagen, jeder der NV Karten kauft bremst den Fortschritt bei den APIs und bei Multikernsupport der CPU.
Ich war mir selbst ja nicht so sicher und habe dir da vorhin einfach mal zugestimmt, auch wenn ich meinte mich zu Erinnern, dass AMD derjenige mit dem HW Scheduler war, aber nach dem Video wurde ja bestätigt, dass es in der Tat stimmt.
Also ja, bei AMD ist der Scheduler stark von der jeweiligen Anwendung abhänhig, trotzdem ist er ein Hardware Scheduler
Und bei Nvidia macht das nicht die GPU sondern der Treiber.
Laut Wikipedia hat GCN sogar zwei Hardware Scheduler
Since the third iteration of GCN, the hardware contains two schedulers: One to schedule wavefronts during shader execution (CU Scheduler, see below) and a new one to schedule execution of draw and compute queues.
LOL...man sieht dass du genau NULL verstanden hast was aktuell der "Stand der Dinge" ist.
Das Video wurde nun schon oft genug verlinkt das die Wirkungsweise des "nVidia-command-list-Treiber" erklärt. Das brauche ich nicht nochmal zu machen.
Das Video erklärt so WUNDERBAR warum in DX11 nVidia GPUs später ins CPU-limit laufen und warum auf nVidia-GPUs "seltsamerweise" die CPU-Last-Verteilung auf viel mehr Threads verlagert ist als bei AMD in DX11 games. Und auch warum AMD in DX12 deswegen einen Vorteil hat.
Das Video oben sagt im Grunde dasselbe wie Wadenbeisser schon schön zusammengefasst hat:
Bei den Radeons findet das sheduling der GPU in Hardware statt, nvidia hat das auf die CPU ausgelagert. Damit rennen die Radeons voll in die Renderthread Beschränkungen von DX11 wärend nvidia die Aufgaben auf andere Kerne verteilen kann und somit mehr Rechenleistung für den Renderthread von DX11 übrig bleibt. Man umgeht also teilweise die Schwächen von DX11. Da die neuen APIs allerdings ein vernünftiges multithreading bieten läuft der Workaround ins leere und kann sogar das Gegenteil bewirken weil das Sheduling auf der CPU natürlich auch Rechenleistung fordert. Kann das Spiel also alle Kerne voll auslasten dürften die Geforce Karten im CPU Limit hinter die Radeons zurück fallen
Was beobachtet man:
In DX12 games liegen die nVidias zunächst mal in der Regel 10-20% zurück und haben Probleme mit den Frametimes....ggf. macht sich nVidia die Mühe und patch das im Treiber. Oder auch nicht je nach Lust und Laune ihres Treiberteams. Manches lässt sich halt aber nicht (über den Treiber) patchen (Stichwort Async Shaders).
Weiter oben hat xexex ja schon darauf hingewiesen dass bei einem DX12 game das "nur" Feature Level 11_0 benötigt dennoch der API-Teil in DX12 gecoded ist. Was bedeutet dass man viel flexibler mit Multithreading umgehen kann als mit einem Games das mit DX11 API Featurelevel 11_0 daherkommt. Man kann nämlich die command list befehle die nativ und KERN-Bestandteil von DX12 sind eben nutzen um die alten feature Level 11_0 befehlsketten abzusetzen. Die Command-List-Struktur wiederum ermöglicht es der GPU "quasi" unabhängig von der CPU z.B. Draw calls zu verarbeiten.
Zumindest GPUs die einen Hardwarescheduler haben können das.
nVidia nun hat eben eine Softwarescheduler der Teil des Treibers ist. Das erlaubt relativ schnell und auch sehr starke individuelle Anpassung an unterschiedliche Games...erfordert diese sozusagen auch.
Es ist also genau das Gegenteil der Fall von dem was du hier sabbelst und es gibt genügend Quellen im Netz z.T. auch von Leuten die mehr Ahnung haben die das belegen.
Kurzum:
nVidia = Softwarescheduler
=> Vorteil in DX11 da man "Renderthread"-Limit etwas umgehen kann
=> "späteres" CPU Limit (bzw. weniger "CPU-Overhead" wobei das faktisch nicht stimmt. Eigentlich wird die Last nur "besser" verteilt. Der "Overhead" ist tatsächlich sogar größer.)
=> Siehe "CPU-Limit in DX12 bei nVidia plötzlich "früher" als bei AMD.
Nachteil in DX12 - der softwarescheduler und die jeweilige Applikation arbeiten ggf. aneinander vorbei
=> "ruckeln", schlechtere Performance solanges bis eine Anpassung des Schedulers ODER der Applikation erfolgen.
AMD = Hardwarescheduler
=> Nachteil in DX11 da man auf die Applikationsentwickler angewiesen ist das "beste" aus dem Renderthread limit von DX11 zu holen. Keine Treiberseitige Patch Möglichkeit.
=> Vorteil in DX12 da hier NATIV via command-list eine möglichst maximale Entkopplung von GPU und CPU arbeit direkt durch die API und den Applikationsentwickler vorgenommen wird.
=> Keine Notwendigkeit hier jedes mal den Treiber anpassen zu müssen. Hardware muss "einfach nur die API können". (ist also durchaus auch "einfacher" für den Entwickler...der muss sich halt einfach eine GPU der Sorte besorgen und das game mal darauf testen, kein rein"pfushen" des Treibers mehr)
Das ganze ist erkennbar an den 10-20% performance boost von AMD-Karten @DX12. Insbesondere auch noch dann wenn z.B. KEIN intel CPU im System.
Leider hat CB es mal wieder versäumt wenigstens EINE nvidia Karte @Ryzen gegenzutesten....damit man auch mal sieht wieviel Einfluss die "intel-optimierung" der nVidiatreiber//und Games hier noch reinhauen.
@Volker: Liefert ihr bitte noch EINE nVidia Karte @Ryzen nach ? z.B. eine 1080 ?
, dann hier: Haste n YT-Video 
