News DirectX 12: Disput zwischen Oxide und Nvidia geht weiter

[Iscaran]

Sorry das weiss ich auch nicht.

Aber es deckt sich auch mit der Diskussion anderswo...
EDIT: siehe auch Unicous einige Posts vorher bei 3d-center - das deckt sich ja mit dem "simplified" von guru...

Ein Grundpfeiler auf dem das DX12-"Gebäude" steht ist das man versucht grundsätzlich die Dinge zu "entknüpfen". So dass man die Möglichkeit hat eben durch Parallelisierung/Async Computing bestimmte "voneinander unabhängige" Teile zu beschleunigen.
Und das ganze eben Teils deutlich (nach AMD ca 0-50%...real dann wohl je nach Anwendung weniger).

 

[xeonking]

Sagte ich ja schon einmal, man kann davon ausgehen das der Anteil von GPU/APU die AS in Hardware unterstützen höher ist als die, die es nicht in Hardware können.

gruß

 

[Nai]

@ Iscaran
Tut mir leid, der erste Link ist wieder absoluter kauderwelsch an technischen Begriffen. Das Scheduling von Compute und Graphik an sich läuft sowohl bei Maxwell als auch bei GCN in Hardware ab. Der einzige Unterschied ist, dass Maxwell nicht Graphik und Compute gleichzeitig kann. Deswegen muss der Treiber der GPU, wenn es zu einem gegebenen Zeitpunkt sowohl Compute als auch Graphikaufgaben zu berechnen gibt, in regelmäßigen Abständen für den Kontextwechsel sorgen indem er der GPU sagt: Höre hier an der Stelle mit Compute auf und kümmere dich um die Graphik oder alternativ höre hier an der Stelle mit Graphik auf und kümmere dich um Compute.

 

[max_1234]

Richtig .. wenn man schon meckert, dann wenigstens technisch korrekt
Allerdings sollte man noch ergänzen, dass Maxwell hier auf Antworten der CPU warten muss, egal ob gerade 2 oder 31 Slots der Queue gefüllt sind.

Ich würd wirklich gerne mal Arma 4 mit DX12 sehen ... ob das immer noch im CPU Limit hängt

mfg,
Max

 

[Häschen]

http://www.guru3d.com/news-story/nvidia-will-fully-implement-async-compute-via-driver-support.html
http://www.pcgameshardware.de/Direc...Geforce-Treiber-Asynchronous-Compute-1170406/

Es bleibt CPU seitig, wie genau es sich letztendlich auswirkt werden wir sehen.
Vielleicht ist es sogar Hardware seitig, aber nvidia schweigt.

 

[max_1234]

Es bleibt CPU seitig, wie genau es sich letztendlich auswirkt werden wir sehen.

Das wird auf jeden Fall interessant ...
Imho glaube ich aber nicht dass die CPU schnell genug dafür sein kann, aber mal abwarten. Vielleicht kompensiert die daraus resultierende quasi-parallele Verarbeitung der Tasks die Mehrleistung, die die CPU softwareseitig aufbringen muss. Zumindest teilweise.

mfg,
Max

 

[Nai]

Allerdings sollte man noch ergänzen, dass Maxwell hier auf Antworten der CPU warten muss, egal ob gerade 2 oder 31 Slots der Queue gefüllt sind.

Das ist auch wieder nicht der Fall . . . .

Huhu Moon_Knight!

 

[Krautmaster]

Aha, nur weil ein Spiel die gegebenen technischen Möglichkeiten voll ausschöpft ist es eine Techdemo...

nö, aber weils quasi dieselbe Engine wie Swarm verwendet welches die Mantle Techdemo darstellte

Klar, das Setting "1 Mio Einheiten auf einer Map um Drawcalls und API Last zu provozieren" bietet sich dazu auch an. Gehen tut das, wie man sieht, aber mit wenig Aussagekraft für "ausgeglichene" Engines.

Genau wegen dieser "speziellen" Engine sind auch über Treiberoptimierungen enorm hohe Zuwächse drin - und genau deshalb konnte Nvidia damals diesen "Wundertreiber" nachlegen.

 

[foofoobar]

@ Iscaran
Tut mir leid, der erste Link ist wieder absoluter kauderwelsch an technischen Begriffen. Das Scheduling von Compute und Graphik an sich läuft sowohl bei Maxwell als auch bei GCN in Hardware ab. Der einzige Unterschied ist, dass Maxwell nicht Graphik und Compute gleichzeitig kann. Deswegen muss der Treiber der GPU, wenn es zu einem gegebenen Zeitpunkt sowohl Compute als auch Graphikaufgaben zu berechnen gibt, in regelmäßigen Abständen für den Kontextwechsel sorgen indem er der GPU sagt: Höre hier an der Stelle mit Compute auf und kümmere dich um die Graphik oder alternativ höre hier an der Stelle mit Graphik auf und kümmere dich um Compute.

Wie teuer ist ein Contextswitch und kann der jederzeit durchgeführt werden oder geht das nur in bestimmten GPU-States? Müssen ggf. Queues nach einem Contextswitch neu befüllt werden?

 

[Nai]

Wie teuer: Ich habe nie gebenchmarkt. Aber ich schätze es so in dem einstelligen oder niedrigen zweistelligen Microsekundenbereich, ähnlich wie andere State-Wechsel der GPU.

geht das nur in bestimmten GPU-States?

Wie meinst du das ?

Müssen ggf. Queues nach einem Contextswitch neu befüllt werden?

Ich weiß auch nicht 100 \%tig wie NVIDIA-GPUs das intern lösen. Ich bezweifle aber, dass die Queues jedes mal neu befüllt werden müssen, da das umständlich wäre.

 

[foofoobar]

Wie meinst du das ?

Ob z.b. Shader und/oder FF Funktionen abgeschlossen sein müssen, damit ein Contextswitch stattfinden kann. Es geistern ja diese ominösen 16ms durch den Raum.

 

[Nai]

Ob z.b. Shader und/oder FF Funktionen abgeschlossen sein müssen, damit ein Contextswitch stattfinden kann.

Meines Kenntnissstands nach müssen sie das

 

[max_1234]

Ich weiß auch nicht 100 \%tig wie NVIDIA-GPUs das intern lösen. Ich bezweifle aber, dass die Queues jedes mal neu befüllt werden müssen, da das umständlich wäre.

Ziemlich unwissend für jemanden der häufig und oft mit redet?
Natürlich werden diese nicht neu befüllt, das ist der Sinn einer Queue (nicht Stack).

Und meiner Aussage bin ich mir relativ sicher - obwohl es bis dato keine genaueren Infos von Nvidia gibt (bzw. jemals geben wird).

Alles andere hier ist nur Augenwischerei und mimimi

Aktuelle Nvidia Karten können damit einfach kein DirectX12. Ob man ein Auto mit 2 Reifen noch als Auto bezeichnet, das liegt immer im Auge des Betrachters. Manipu-Marketing wird hier ja besonders groß geschrieben.

mfg,
Max

 

[Iscaran]

Wie teuer: Ich habe nie gebenchmarkt. Aber ich schätze es so in dem einstelligen oder niedrigen zweistelligen Microsekundenbereich, ähnlich wie andere State-Wechsel der GPU.

Wow also um einen Frame zu berechnen wo ich dann im zweistelligen ms Bereich "Zeit" verliere bei einer ungefähren Rechenzeit von so einer Frameberechnungszeit von ~30ms ist nicht gerade wenig...in Prozent umgerechnet.

Auf AMD-Präsentationsfolien war irgendwo die Zeit von 33ms ohne AS und 27ms mit AS...womit wir bei 20% Differenz wären bei nur 6ms. Lass das mal 10 oder 15 sein und du bist bei ~50%.

Ich weiss Frame-Berechnungszeit != "Performance in FPS". Dennoch ist eine Erhöhung der Latenz eines Befehls um mal eben 20% oder so kein Pappenstiel.

 

[Nai]

Ziemlich unwissend für jemanden der häufig und oft mit redet?

Ich hab kein Problem damit zu schreiben, wenn ich etwas nicht weiß oder unsicher bin oder Fehler einzugestehen, wenn ich etwas falsches geschrieben habe. . . . . Ist das schlecht?

Aktuelle Nvidia Karten können damit einfach kein DirectX12.

Jedes Programm, was dem DirectX12 Standard entspricht, wird auf ihnen laufen, weswegen sie doch DirectX12 können.

Natürlich werden diese nicht neu befüllt, das ist der Sinn einer Queue (nicht Stack).

Ich weiß hier nicht, was du mir hier mit Queue und Stack sagen möchtest. Die Frage war ob die Queues neu befüllt werden müssen. Da ist es m.E. komplett Implementierungsabhängig ob die GPU die Queues weiterhin in ihrem DRAM vorhält oder bei einem Kontextwechsel verwirft. Ersteres würde ich aber stark annehmen, da letzteres ineffizient wäre, da die Queues jedes mal neu übertragen werden müssten.

Wow also um einen Frame zu berechnen wo ich dann im zweistelligen ms Bereich "Zeit" verliere bei einer ungefähren Rechenzeit von so einer Frameberechnungszeit von ~30ms ist nicht gerade wenig...in Prozent umgerechnet.

Microsekunden, nicht Millisekunden

 

[Iscaran]

Microsekunden, nicht Millisekunden

Dann eben 33µs statt 27µs und ändert das was an den 20% ?

 

[PiPaPa]

Jedes Programm, was dem DirectX12 Standard entspricht, wird auf ihnen laufen, weswegen sie doch DirectX12 können.

Ich kann auch versuchen mit einem Porsche GT3/911 bei einem Stoppelfeldrennen mitzufahren, ist aber keine tolle Idee, auch wenn der Wagen dem Standard "Auto" entspricht.
Sprich nur, weil nvidia womöglich erstmal per Treiber meldet sie können Asynch, dann sich jetzt melden das sie es nachliefern(!!!) können Sie nicht unbedingt DX12.

 

[Nai]

Dann eben 33µs statt 27µs und ändert das was an den 20% ?

Wie genau meinen? Der Kontextwechsel ist nicht das einzige was dir Performance kostet.

Ich kann auch versuchen mit einem Porsche GT3/911 bei einem Stoppelfeldrennen mitzufahren, ist aber keine tolle Idee, auch wenn der Wagen dem Standard "Auto" entspricht.
Sprich nur, weil nvidia womöglich erstmal per Treiber meldet sie können Asynch, dann sich jetzt melden das sie es nachliefern(!!!) können Sie nicht unbedingt DX12.

Du musst zwischen unterscheiden zwischen:
-Sie können jedes DirectX12 Programm ausführen
-Sie besitzen eine genügend Performance um DirectX12-Programme schnell genug auszuführen.
Der DirectX-Standard verlangt aus naheliegenden Gründen nur ersteres. Async-Compute ist nur für letzteres gut.

 

[PiPaPa]

-Sie können jedes DirectX12 Programm ausführen

ausführen kann soll was bedeuten? Das ist so lapidar formuliert. Das es startet? Eine DX 9 Karte kann bestimmt auch ein DX 12 Programm aus, macht sie aber immer noch nicht zu einer DX 12 Karte.

-Sie besitzen eine genügend Performance um DirectX12-Programme schnell genug auszuführen.
Der DirectX-Standard verlangt aus naheliegenden Gründen nur ersteres. Async-Compute ist nur für letzteres gut.

Bisher nicht, sonst hätten Sie Oxcide nicht aufgefordert AS in ihrem Spiel zu deaktivieren.... Momentan ist es eine Bremse statt "schnell genug auszuführen"

 

[Iscaran]

Wie genau meinen? Der Kontextwechsel ist nicht das einzige was dir Performance kostet.

Das ist mir grundsätzlich klar - auch ob und falls die Queues / Command list bei einem Context switch neu befüllt werden müssen etc.

Aber das sind eben all die Schritte die bei AMD aufgrund der "hardware" bedeutend kürzer wenn überhaupt in der Form (Stichwort Context Switch) stattfinden müssen.

Dazu noch die Aussage vom Oculus Rift Entwickler (weiter oben gepostet das der Preemption support (was eine wichtige grundbedingung für das "Async Compute von graphics/compute tasks" darstellt auf nVidia karten momentan eine totale Katastrophe darstellt.

Now as Microprocessor analyst, David Kanter, said, some Oculus employees told him that the best Preemption support for context switches was with AMD by far, Intel was pretty good and NVIDIA was possibly catastrophic (1:21:00 in the video below).

Dazu noch den Beyond3d Topic wo über das MDolenc Skript diskutiert wird...

Es wäre wirklich schön wenn nVidia mal was dazu sagen würde - aber wie schon bei allen derartigen "technischen" Reinfällen der letzten Jahre (z.B. die fehlende Shader/VRAM bei der 970) kommt nur die Mauer des Schweigens.