Async Shader bzw. Async Compute ist letztendlich "nur" für eine bessere Performance und Latenz da.
Das ist aber Architektur abhängig wie stark man von so einem Feature profitieren würde.
Ganz grob gesehen könnte man es auch mit SMT bei CPUs vergleichen, es macht wenig Sinn einen schmalen Kern der meistens ausgelastet ist mit 4 Threads voll zu knallen, hat man aber breiten Kern, dann ist die Wahrscheinlichkeit größer das dieser häufiger unausgelastet ist, SMT lohnt sich.
So ähnlich ist das bei AMDs GCN und Nvidias Maxwell und noch viel mehr Intels Gen-Architektur.
Jeder der drei hat eine Architektur die unterschiedliche Arbeitsgrößen für die ALUs verwendet, AMD hat die breiteste mit 64 Threads, Nvidia verwendet 32, Intel ist flexibel mit 8, 16 oder 32, sie verwenden meistens 16.
Und jede Architektur hat eine andere Balance was die Kontrolllogik angeht, wie schnell sie den Arbeitsmodus wechseln kann, wie hoch die durchschnittliche Auslastung der Einheiten ist usw.
AMDs GCN neigt dazu mehr idle-Units zu haben gegenüber der Konkurrenz, Hardware-Scheduler und Async Compute macht Sinn.
Bei Async Compute kommt der Performance-Boost durch zwei Sachen zu Stande, 1. unausgelastete Einheiten bekommen Compute-Arbeit zugewiesen, 2. prinzipiell unausgelastete Einheiten bekommen Compute-Arbeit zugewiesen.
Async Compute lohnt sich besonders bei der Nummer 2, wenn man Spiele rendert dann gibt es Berechnungen die fast vollständig auf die ROPs (Backend) gehen, da tun die ALUs prinzipiell wenig, wenn man hier Async Compute dazwischen schiebt, kann man viel gewinnen.
Das ist auch die Hauptaufgabe von Entwicklern, schauen welche Arbeitsschritte sich nicht in die Quere kommen und unabhängige Flaschenhälse haben, somit kann man am meisten Performance herausschlagen.
Geschaut wird welche Compute-Aufgaben sich parallel eignen und dann wird das ganze über die API konstruiert (vorgegeben) und mit den restlichen Arbeitsschritten synchronisiert.
Conservative Rasterization ist ein neuer Arbeitsmodus vom Rasterizer welcher anders arbeitet als bisher.
Normalerweise wird im Raster geschaut, ob ein Dreieck die Mitte eines Pixels überschreitet oder nicht.
Wird die Pixelmitte getroffen, wird gerastert, wenn nicht, wird eben nicht gerastert.
Conservative Rasterization dagegen rastert alles was einen Pixel berührt.
Es ist dadurch möglich Algorithmen zu verwenden die früher optische Pixelfehler hatten.
Mögliche Dinge sind die Berechnung von Schatten oder Voxeln.
ROVs sind dazu da OIT und Blending effizienter und flexibler zu gestalten, wobei das auch von der Hardware abhängt wie schnell das ist.
Intel hat sehr gute Hardware an der Stelle, wie es mit Nvidia aussieht weiß ich nicht, wir werden es "bald" mit Just Cause 3 und F1 2015 erfahren, beide Spiele verwenden Conservative Rasterization und ROVs.
Hier kann man dem Backend sagen das er nicht alle Pixel parallel berechnen soll, sondern einige seriell.
Das kostet natürlich etwas Performance, garantiert einen aber das gewisse Objekte erst nach den anderen gerendert werden, sodass man Transparenzen korrekt darstellen kann, ohne Pixelfehler.
Bisher verwendet man Datenstrukturen die das ganze in eine Liste schreiben, sortieren und dann ausgeben.
Das kostet auch viel Performance und hat den Nachteil, dass man nie genau weiß wie viel Speicher eine Szene benötigt, deswegen wird immer ein Sicherheitsbuffer im VRAM reserviert.
TressFX von AMD z.B. verwendet OIT und frisst viel VRAM.
Mit ROVs könnte man einen Arbeitsschritt wesentlich schneller und sparsamer ausführen, vorausgesetzt die Hardware kann ROVs schnell berechnen.
Async Compute sollte relativ leicht zu implementieren sein. Im Grunde ist das dank den Konsolen sowieso auf dem Radar von den meisten Entwicklern.
Conservative Rasterization ist wahrscheinlich aufwendiger, weil man hier konkrete Rendering-Dinge anders berechnet.
Möchte man Conservative Rasterization ohne "Hardware-Support" berechnen, müsste man es über Shader emulieren, dass benötigt einen ganz anderen Code-Path und wäre viel langsamer natürlich.
ROVs sind laut Entwickler (sebbbi) relativ leicht zu integrieren, aber ein Fallback wäre ebenso aufwendig, da er anders gelöst werden müsste.
Eine gute Standard-Quelle die ich sehr schätze sind Sebastian Aaltonen aka sebbbi (RedLynx) und Andrew Lauritzen (Intel) und das Forum Beyond3D allgemein.
Beide Persönlichkeiten führen viele technische Dinge aus und geben auf viele Frage die man hat eine Antwort. Aber das technische Wissen ist auch außerhalb davon von vielen anderen hoch.
Da tummeln sich noch mehr professionelle Entwickler.
Wer mag kann z.B. hier reinschauen, ein Thread über Gen9, Execution-Model, SIMD-Breite etc:
https://forum.beyond3d.com/posts/1861164/
Zuerstmal mal zu der AsyncS Geschichte. Theoretisch kann NV dieses in Hardware und das sogar relativ gut ->
http://docs.nvidia.com/cuda/samples/6_Advanced/simpleHyperQ/doc/HyperQ.pdf
Die Grid Management Unit ist hier das Zauberwort. Leider hat es, zumindest bei Kepler, nur die GK110. Möglich ist es aber. Ob die kleinen GM Chips was ähnliches haben glaube ich nicht ( wenn wer andere Infos hat immer her damit ).
Das Problem ist die verwendete Begrifflichkeit Async Shader bzw. Async Compute für eine Sache, mit der man etwas anderes meint.
Gemeint ist eig. parallel Rendering und Compute berechnen zu können.
Nvidia hat nur einen Scheduler, sie müssen entsprechend immer switchen, wenn andere Aufgabenbereiche anstehen.
Hyper-Q sollte laut Anandtech ab Maxwell generell zur Verfügung stehen:
AMD Dives Deep On Asynchronous Shading
Der Artikel ist aber meh, Darstellung und Text sind krude.
)
Ich freu mich darauf, unabhängig davon, ob AMD oder Nvidia Nutzer ein längeren ***** besitzen.
??
