cl55amg
BIOS-Overclocker(in)
Es ist einfach nur absolut konfus was du schreibst bzw. es ergibt keinen Sinn. Dir fehlt das Basiswissen darüber wie eine GPU funktioniert oder was genau ein Treiber macht.
Ashes of the Singularity Beta - Benchmark 2.0 mit DirectX 12, Asychronous Compute und pikanten Ergebnissen
- Ersteller PCGH-Redaktion
- Erstellt am
Es ist einfach nur absolut konfus was du schreibst bzw. es ergibt keinen Sinn. Dir fehlt das Basiswissen darüber wie eine GPU funktioniert oder was genau ein Treiber macht.
K12_Beste
Gesperrt
Natürlich ergibt es Sinn.
Fehlt wohl dir, wenn du so weltfremde Behauptungen aufstellst:\
Man kann das nicht per Treiber ändsern, der Treiber kann die Hardware nicht verändern...
Lack of Async Compute on Maxwell Makes AMD GCN Better Prepared for DirectX 12 | techPowerUp
Und jetzt brauchst du nicht mehr zu antworten, ich sehe deinen Spam nicht mehr!
cl55amg
BIOS-Overclocker(in)
Immernoch konfus, eben hast du noch über Treiber Optimierungen für Spiele die DX11 verwenden geschrieben, jetzt schwenkst du auf Async Compute.
Das erinnert mich an einen betrunkenen Autofahrer der die Spur nicht halten und Schlangenlinien fährt...
Du weisst nicht wie eine GPU funktioniert, daher kannst die Begriffe seriell und parallel in Zusammenhang mit GPUs nicht einordnen.
Illithide
Freizeitschrauber(in)
Das derzeit einzig Konfuse ist doch eher die von nV aufgestellte Behauptung, per Treiber irgendetwas Maßgebliches an der DX12-Performance von Maxwell drehen zu können, dass ASync Compute noch gar nicht im Treiber integriert wäre (obwohl es läuft, wenn auch mit mäßiger Performance), etc. Daran ändern dann auch unqualifizierte persönliche Angriffe gegen die Mitforisten nichts.
PCGH_Carsten
Ex-Redakteur
Das liegt daran, dass Async Compute kein Caps Bit ist, was entweder geht oder nicht geht. Das kann man sich so ähnlich vorstellen wie die Unified Shader aus DX10: Damals haben es zwar alle Hersteller auch in Hardware implementiert, weil es einfach sinnvoll war, aber im Prinzip ging es darum, dass die Programmierbarkeit sich nicht voneinander unterscheidet, also für die auf Direct3D zugreifende Software (Spiele) keinen Unterschied macht in Sachen Funktionsumfang und/oder Programmlänge. Ob die Hardware dahinter wirklich Unified war oder nicht hätte für DirectX keine Rolle gespielt.
Ähnlich auch bei Async Compute: DirectX ist das völlig egal, der Treiber muss die Programmhinweise lediglich akzeptieren, ohne Fehler zu werfen - wie es dahinter weitergeht, ist DirectX egal. Und wie schon öfter erwähnt: Async Compute ist ein bißchen wie SMT/Hyperthreading - es bringt mehr, je schlechter die einzelnen Kerne ausgelastet sind. Sind die Recheneinheiten bereits optimal beschäftigt, bringt AC nullkommagarnix.
Kleine Preview aus der PCGH 04/2016 zum Thema:
AMD könnte aber auch unter DX11 Driver Command Lists unterstützen (Intel tut's btw auch nicht, Nvidia schon).
Fiji schrieb:
Zuletzt bearbeitet:
Blizzard_Mamba
Volt-Modder(in)
Man muss auch sagen, dass AMD und Nvidia zwei komplett verschiedene Hardware-Ansätze "Async Compute" nennen. Unabhängig der sich auch sonnst unterscheidenden Architektur: AMD hat bis zu 8 "echte" ACEs, Nvidia eine Grafikpipeline + 1 (31) computepipes. Das Hardware feature ist bei beiden da, sieht aber fundamental anders aus.
Nvidia hat zusätzlich Probleme mit der Voraussage von Kontextwechseln etc. Liegt wohl daran, dass das Design eher dafür gedacht war die winzigen! Lücken bei der Grafikberechnung zu stopfen und nicht wie bei AMD gleichberechtigte Parallelisierung zu ermöglichen. Da die Chips Sequentiell unheimlich gut auszulasten sind gehe ich persönlich auch eher davon aus dass man durch Nvidias Async Compute in Maxwell höchstens sehr moderate Performanceverbesserungen erwarten darf. Bei niedrigem Load müsste der Nvidia Ansatz aber mindestens mithalten können... Das interessiert aber fast keinen in der Praxis. (Gibt es dazu Tests ?)
Nvidia beschäftigt meinen Informationen nach aber 3 Schwarzmagier, da könnte noch was kommen
Nvidia hat zusätzlich Probleme mit der Voraussage von Kontextwechseln etc. Liegt wohl daran, dass das Design eher dafür gedacht war die winzigen! Lücken bei der Grafikberechnung zu stopfen und nicht wie bei AMD gleichberechtigte Parallelisierung zu ermöglichen. Da die Chips Sequentiell unheimlich gut auszulasten sind gehe ich persönlich auch eher davon aus dass man durch Nvidias Async Compute in Maxwell höchstens sehr moderate Performanceverbesserungen erwarten darf. Bei niedrigem Load müsste der Nvidia Ansatz aber mindestens mithalten können... Das interessiert aber fast keinen in der Praxis. (Gibt es dazu Tests ?)
Nvidia beschäftigt meinen Informationen nach aber 3 Schwarzmagier, da könnte noch was kommen
Cool, ich wusste doch, es gibt eine nachvollziehbare Erklärung
Ich bin bislang Aufgrund etwas viel Arbeit in letzter Zeit noch nicht so richtig zum Lesen gekommen... Wie gut, dass sowas Schlaues in unserem Heft steht. Gruß,
Phil
Datarecovery09
Komplett-PC-Aufrüster(in)
[...]
Async Compute ist ein bißchen wie SMT/Hyperthreading - es bringt mehr, je schlechter die einzelnen Kerne ausgelastet sind. Sind die Recheneinheiten bereits optimal beschäftigt, bringt AC nullkommagarnix.
[...]
Mal ganz blöd gefragt: Ist es überhaupt realistisch, die Recheneinheiten einer Grafikkarte ohne AC perfekt auszulasten? Ich hatte das jetzt so verstanden, dass entweder Compute oder Grafik geht, aber nicht beides gleichzeitig - da aber im Normalfall(?) beides gemacht werden muss, müsste doch in einem herkömmlichen Anwendungsfall immer ein gewisser Anteil der Recheneinheiten nicht optimal ausgelastet sein, oder?
PCGH_Carsten
Ex-Redakteur
Das ist schwer zu sagen - und generell schonmal gar nicht.
Auch mit Grafik und Compute zusammen kann das gehen (oder auch nicht). Async Compute bringt ja nur was, wenn in der Grafik-Pipeline Leerlauf entsteht; gibt's keinen Leerlauf, bringt auch AC nix, da es nicht „zwischengeschoben“ werden kann.Aber genau das will doch keiner(!) Das was Nvidia macht ist auch nur eine "Lösung", die nur für Nvidia funktioniert, sprich die anderen Grafikkarten Hersteller müssten dies auch wieder, jeder für sich, lösen.
Selbst wenn Intel und AMD dies machen wollten, mit GameWorks würde dies sowieso nicht gehen, da CS. Vielleicht versteht man so etwas besser warum zb AMD sich das "schenken" wollte. Davon das die Engine, je nach GPU-Hersteller, etwas umgebaut werden müsste sprechen wir lieber erst einmal nicht.
Dafür genau gibt es doch jetzt DX12 AC, es soll dies für alle spezifiziert lösen.
(Ok bei AotS will Nvidia auch wieder etwas "eigenes"
)DX12 - Asynchronous Shader wird wohl den Nvidia Treiber _und Nvidia_ etwas entzaubern.
Was werden wir von Nvidia sehen?
Wieder zu jedem Spiel ein "GAME READY" Treiber?
Mehr CPUlast bei Nvidia?
wird der Nvidia Treiber ein Intel GPU für "Compute" nutzen?
cl55amg
BIOS-Overclocker(in)
Ähnlich auch bei Async Compute: DirectX ist das völlig egal, der Treiber muss die Programmhinweise lediglich akzeptieren, ohne Fehler zu werfen - wie es dahinter weitergeht, ist DirectX egal. Und wie schon öfter erwähnt: Async Compute ist ein bißchen wie SMT/Hyperthreading - es bringt mehr, je schlechter die einzelnen Kerne ausgelastet sind. Sind die Recheneinheiten bereits optimal beschäftigt, bringt AC nullkommagarnix.
Ja genau so ist das. Hier sieht man ganz gut, dass man den Sachverhalt differenziert betrachten muss, dafür muss man nun mal auch die basics verstehen.
Wenn jemand behauptet der Himmel wäre permenent Rot und nicht Blau, dann muss ich nicht das Gegenteil beweisen. K12_Beste schreibt das die Maxwell Architektur Instruktionen nur seriell abarbeiten kann, was im Grunde im Widerspruch zur Hauptexistenzberichtigung einer GPU steht, nämlich mit tausenden computation units (shadern) parallele Berechnungen für das "Rendering" durchzuführen. Async Compute setzt aber wo ganz anders an. Es soll ermöglicht werden Rendering und "non Rendering" Berechnungen gleichzeitig durchzuführen, ohne jedes mal einen Kontext- Switch durchführen zu müssen, wenn sich die "Instruktionsart" ändert. Das hat nur dann einen Vorteil, wenn genügend freie shader zu Verfügung stehen, denn sind alle belegt, dann gibt es nichts was man parallel für non rendering Berechnungen nutzen könnte. Und dann muss man entweder einen Kontext Switch durchführen oder die Anzahl der shader units für Rendering Aufgaben beschränken. Beides bringt Nachteile mit sich... Man kann sicher in vielen Situationen Anwendungsspezifisch die Auslastung der shader units so per Treiber optimieren, dass ein fehlendes Async Compute kein Problem darstellt.
Zuletzt bearbeitet:
ZeroCool261
Freizeitschrauber(in)
Man sollte hier aber aber klarstellen, dass eine GPU rein auf Daten-Parallelismus fokussiert ist obwohl zugegeben eine GPU auch Threadparallismus beherrscht , was bedeutet eine GPU beherrscht beides man kann ja Verzweigungen im Programm einführen für Threads was aber einfach unerwünscht ist. ACEs führen das aber weiter, das Programm was auf der GPU läuft beherrscht dann sowohl Daten als auch Threadparallismus weil es andere "kleinere" Shader gibt komplett was anderes berechnen können und ihren eigenen Context haben, das ist aber ein Design Win für AMD.
Man kann ja sagen, dass Maxwell eine gute Architektur ist aber irgendwie stößt diese an die Grenzen, etwas Parallel rechnen zu können ist noch immer besser als es nur seriell hin Hinblick auf Performance und Effizienz selbst wenn es hier wider Probleme gibt um das zu erreichen.
PCGH_Carsten
Ex-Redakteur
Wieso will das keiner? Driver Command Lists ist/sind ein offizielles Feature samt Caps Bit unter DirectX 11 und damit genauso spezifiziert, wie AC als implizites Feature unter DX12.
Weil der nutzen der Command List unter DX11 den Aufwand nicht rechtfertigt, unter DX12 ergibt dies doch erst wirklich Sinn durch die Pipeline State Objects.
Ich bleibe dabei, wenn ein Game wirklich nutzen aus der DX11 "Command List" ziehen will, dann muss jeder GPU Hersteller, für jedes Spiel "Optimieren". Und das will keiner.
DKK007
PCGH-Community-Veteran(in)
Weshalb bricht die Fury am Ende denn so ein, so dass die 380X da die schnellste Karte da ist? Oder gibts die Antwort im Heft?
Apollo4244
Komplett-PC-Aufrüster(in)
Kann mir bitte jemand möglichst einfach erklären oder zeigen, was eigentlich Asynchronous Compute in diesem Spiel bzw. Benchmark bewirkt oder bewirken sollte?
Oromis16
BIOS-Overclocker(in)
@Apollo4244
Da ist erklärt was es allgemein bewirkt, und in Ashes macht es genau das gleiche
Für mehr Informationen besuche die Datenschutz-Seite.
Da ist erklärt was es allgemein bewirkt, und in Ashes macht es genau das gleiche
Eingebundener Inhalt
Youtube
An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst:
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.Für mehr Informationen besuche die Datenschutz-Seite.
Apollo4244
Komplett-PC-Aufrüster(in)
@Apollo4244
Da ist erklärt was es allgemein bewirkt, und in Ashes macht es genau das gleiche
Danke, das Video hatte ich vor langem schon einmal gesehen.
Ich dachte die funktionsweise von Asynchronous Shaders hätte ich weitestgehend verstanden, und Asynchronous Compute wird für andere (nicht Grafik) Berechnungen verwendet?
Zuletzt bearbeitet:
PCGH_Carsten
Ex-Redakteur
Eine definitive Antwort weiß ich nicht, vielliecht liegt's daran, dass Fiji nur vier ACEs hat? Es sind übrigens prozentuale Werte - absolut gesehen ist Fiji immer noch (teils mit großem Abstand) am schnellsten.
