Remedy Northlight-Engine: RTX-Effekte kosten viel Renderzeit

[HWL News Bot]

Bisher kennen wir nur viele Videos, eine Tech-Demo (Star Wars: Reflections) und viele Ankündigungen zu Spielen mit RTX- bzw. DXR-Unterstützung. Im Falle von Battlefield V konnten wir uns auf der GamesCom die RTX-Alpha bereits anschauen. Darüber hinaus halten sich die Erfahrungen mit den Ray-Tracing-Effekten aber in Grenzen.So fehlt es...

... weiterlesen

 

[fdsonne]

Woher stammt denn die Zahlenspielerei?
Normalerweise sollte das ganze RT Zeugs während der Frameberechnung nebenbei stattfinden (können), einfach weil die RT Cores und Tensor Cores auch gleichsam neben den ALUs funktionieren und nicht nur entweder/oder.
Es sollte also so sein, dass nach Abschluss des Frames einfach dann die RT Berechnung drauf kommt -> aber gleichsam die GPU schon das nächste Frame berechnet. Da im Beispiel, so scheint es mir, die RT-Rechendauer geringer ist als die Raster-Rechendauer, so dürfte die GPU am Ende ALU-limitiert sein ohne dass es wirklich langsamer wird. Nachteil dieser Thematik wäre maximal der größere Delay zwischen Input und Frameausgabe, weil ja die RT-Berechnungen obendrauf für weitere Verzögerung sorgen.

Was ich allerdings nicht zu 100% weis, ob die ALUs einfach an einem anderen Frame weiter rechnen können während die RT/Tensor Cores den RT-Stuff da errechnen? Normalerweise müsste das aber irgendwie funktionieren. Wenn das nicht geht ist aber klar, dass es nur Leistung kosten kann - und das auch massiv.

Wobei man natürlich auch aufpassen muss beim Vergleich - die 9ms mehr, die da genannt sind ist das eine - aber was würde es denn kosten diese Art von Optik per Fake-Rasterizer Zeugs zu erzeugen? Oder wenigstens annähernd in die Region zu kommen? Und nur weil man "Raytracen" kann heist das ja lange nicht, dass man es überall und extrem übertrieben einsetzen muss...
Für die nähere Zukunft wird der optimale Weg wahrscheinlich eher darin liegen, einen möglichst optimalen Kompromiss aus RT-Aufwand, Optikgewinn und Alt/Fake-Rasterstuff zu finden. Wahrscheinlich ist aber genau das das größte Problem, weil man es denke ich zuanfang wieder maßlos übertreiben wird und der Leistungsbedarf einfach übel durch die Decke geht - in den Köpfen der weniger Technik affienen Anwender bleibt dann nur noch hängen, dass RT zu viel Leistung kostet und man dann lieber auf die Optik verzichtet.

 

[Don]

Woher stammt denn die Zahlenspielerei?

Die Zahlen stammen aus dem Vortrag des NVIDIA-Mitarbeiters auf der GTC18 in München.

Theoretisch können die RT Cores gleichzeitig neben den Shadern arbeiten ja, in der Praxis wird man aber immer zeitliche Abhängigkeiten sehen, in denen die Shader auf die RT Cores und umgekehrt warten. Das Ergebnis der Berechnungen der RT Cores muss ja auch wieder in die Shader Pipeline einfließen, da kann man nicht einfach asynchron zueinander weiterrechnen.

Wie hoch der "Overhead" durch das Ray Tracing nun im Mittel sein wird, ist die spannende Frage. Das alles gut auszubalancieren ist also der entscheidende Punkte und Kern der Optimierung durch die Entwickler.

 

[fdsonne]

Und NV hat gesagt, dass die 9ms auf die Berechnungszeit ohne RT drauf kommen?
Es ist ja Golem verlinkt - da steht auch nur irgendwas von einer Annahme auf 30 FPS mit den 33ms. Deswegen die Frage -> weil irgendwie erschließt sich mir daraus nicht wie die Zusammensetzung der Zeiten zueinander aufgehen soll. Dass da 9ms irgendwo in Summe für das RT Zeugs drauf geht - OK, kann sein und ist nice to know. Aber die interessante Frage ist eher, wie hoch ist der relative Anteil der Mehrarbeit im Vergleich zu non RT Stuff.

Und dafür hast du ja auch so Themen wie bspw. die pre rendered frames. Die GPU wird schon anfangen Teile der nächsten Frames anzufassen. Ich kann mir kaum Vorstellen, dass das schlicht und ausschließlich sequenziell passieren kann/wird. Weil dann bringt es überhaupt nichts die RT/Tensor Cores vom Rest zu entkoppeln, da eh nur links oder rechts genutzt werden kann. Auch heist das ja in Summe nicht, dass das Frame fix und fertig sein muss, bevor der RT Part ansetzt. -> es würde ja reichen an der entsprechenden Stelle im Prozess einfach die RT/Tensor Cores einzuklinken während dann im Hintergrund die Register gespeichert werden und die ALUs einfach schon das nächste Frame anfassen bis der RT Part soweit ist, dass mit dem anderen Frame fortgesetzt oder gar fertiggestellt werden kann. Und so kann das dann durchrotieren.

Der ganze Prozess vom ersten Punkt bis zum fertigen Frame im Framebuffer besteht ja aus ganz paar verschiedenen Prozessstufen. Die RT/Tensor Cores sind da wohl einfach nur spezielle Units die zur angemessenen Zeit eben entsprechend analog der FP oder INT Einheiten angefasst werden. Die Codeausführung so aufzubereiten, dass möglichst wenig Leerlauf entsteht ist Aufgabe der Scheduler.

 

[Don]

Genau, die 9,2 ms sind einfach die aktive Renderzeit für Ray-Tracing-Effekte. In wie weit es Übeschneidungen mit den Shadern gibt, sagte man nicht. Worst Case wären also + 9,2 ms, im Best Case sind es deutlich weniger. Ich habe dazu noch zwei Folien von NVIDIA mit in der News eingebaut, die das vielleicht etwas verdeutlicht.

 

[why_me]

Woher stammt denn die Zahlenspielerei?
Normalerweise sollte das ganze RT Zeugs während der Frameberechnung nebenbei stattfinden (können), einfach weil die RT Cores und Tensor Cores auch gleichsam neben den ALUs funktionieren und nicht nur entweder/oder.
Es sollte also so sein, dass nach Abschluss des Frames einfach dann die RT Berechnung drauf kommt -> aber gleichsam die GPU schon das nächste Frame berechnet. Da im Beispiel, so scheint es mir, die RT-Rechendauer geringer ist als die Raster-Rechendauer, so dürfte die GPU am Ende ALU-limitiert sein ohne dass es wirklich langsamer wird. Nachteil dieser Thematik wäre maximal der größere Delay zwischen Input und Frameausgabe, weil ja die RT-Berechnungen obendrauf für weitere Verzögerung sorgen.

Was aber voraussetzt, dass die RT-Cores die komplette RT Berechnungen erledigen.
Es gibt da ein recht interessantes Paper (klick) in dem es um die theoretische Beschleunigung von RT bei einer Hawaii GPU geht. Wenn man sich das ganze durchliest, gibt es ziemlich viele parallelen zu Turing. So werden z.B. spezielle RT-Cores vorgeschlagen mit geringer Genauigkeit, die nur eine grobe hit/miss Abschätzung machen und das eigentliche RT wird auf den Shadern berechnet.

Auch interessant, diese theoretischen RT-Cores würden die ALU-Fläche nur um ca. 4-8% aufblähen.

 

[fdsonne]

Ah OK, genau da wollte ich wissen
Der Text laß sich nämlich so, dass da die 9ms immer drauf kommen... Auch bei Golem lässt sich das so da raus interpretieren.

Na mal gucken, da kommen früher oder später mehr Details an die Öffentlichkeit.

Das ganze RT Zeugs wird mMn erst dann für den Endkunden richtig interessant, wenn die Entwickler das auch entsprechend richtig umzusetzen wissen. Ne Kombi aus DLSS/DLAA respektive dem, was da dahinter steht für RT um Leistung zu sparen bspw. wäre ne recht interessante Sache. Wozu Schatten mit hoher Auflösung raytracen lassen, wenn man bspw. den Spaß auch in niedrigerer Auflösung (und damit viel weniger notwendigen Rays) machen kann, den Denoiser drüber jagen kann und dann ähnlich DLSS/DLAA einfach via KI hoch skaliert? Das ist dann zwar wieder quasi Fake - aber optisch deutlich näher am echt geraytracten Ergebnis als gebackene Schatten oder sonstwelcher Schmuh, der zwar optisch hübsch ist, wenn es statisch sein darf - aber in Bewegung oder bei dynamisch wechselnden Bedingungen nicht funktionieren kann.

Die Lichtspielchen da in der Demo sind schon ziemlich gut. Selbst die TR Demo auf dem Marktplatz bei der Präsentation von NV beeindruckt ggü. einer statischen Umsetzung schon im Detail. Ob es einem das am Ende dann wert ist, ist halt ne andere Sache. Gerade Battlefield ist/war mMn einfach das falsche Spiel für solche Effekthascherei. Weil die Pros eh auf Low schalten...

- - - Updated - - -

Was aber voraussetzt, dass die RT-Cores die komplette RT Berechnungen erledigen.

So wie ich die bisherigen Aussagen verstanden habe, geht es eher darum, den rechenintensiven Part zu übernehmen.
Die RT Cores sollen wohl, wenn mich nicht alles täuscht, bspw. die Massen von Berechnungen bei der Strahlenverfolgung übernehmen. Und geben dann das Ergebnis zurück an die "Shader".
Es ist ja auch "nur" eine Art Hybrid Lösung. Theoretisch wäre das aber eigentlich noch recht weit weg von "komplett".

Der Infogehalt bei NV, wenn man nicht gerade die Whitepaper studiert ist aber leider quasi recht gering - keine Ahnung ob es schon Turing Whitepaper gibt wo es mehr Infos über die RT Cores gibt?

 

[Cippoli]

Ich frage mich auch in wie weit da die TDP eine Rolle spielt. Im Moment hängen alle Turing-Karten beim Rasterizing im TDP-Limit. Wenn nun noch Tensor- und RT-Kerne zum Verbrauch dazu kommen, reduziert dies dann nicht auch die Shaderleistung?

 

[Gamerkind]

Wenn nun noch Tensor- und RT-Kerne zum Verbrauch dazu kommen, reduziert dies dann nicht auch die Shaderleistung?

Müßte eigentlich so sein, wenn es nicht so ist, würde die Karten ja ihr Powerlimit überschreiten.

 

[Tech Enthusiast]

Genau, die 9,2 ms sind einfach die aktive Renderzeit für Ray-Tracing-Effekte. In wie weit es Übeschneidungen mit den Shadern gibt, sagte man nicht. Worst Case wären also + 9,2 ms, im Best Case sind es deutlich weniger. Ich habe dazu noch zwei Folien von NVIDIA mit in der News eingebaut, die das vielleicht etwas verdeutlicht.

Diese 9,2ms sind wenn alle RT Effekte maxed sind?

Worst case 9,2ms, dann hat man also noch 7,5ms Zeit um 60fps zu zaubern.
Wenn ein Spiel also in 4k bummelig bei 130-140fps laufen kann, dann kann es auch mit all maxed RT in 4k@60 laufen?
Also bei nicht total maxed RT effekten kann man die 9,2ms stark reduzieren und so "easy" 4k@60 erreichen.

Das klingt ehrlich gesagt deutlich besser als das was die Aluhutfraktion im Forum dauernd verbreitet.
Es ist ja fast so als ob die Leute von Enlisted das schon vor nem Monat vorgemacht haben und sich das nun bestätigt.

 

[Mo3Jo3]

Ich frage mich auch in wie weit da die TDP eine Rolle spielt. Im Moment hängen alle Turing-Karten beim Rasterizing im TDP-Limit. Wenn nun noch Tensor- und RT-Kerne zum Verbrauch dazu kommen, reduziert dies dann nicht auch die Shaderleistung?

Nur, wenn die RTs auch aktiviert sind. Und dann stellt sich wieder die Frage, wo der Flaschenhals liegt. BF mit Rtx soll doch ~60fps @FullHD liefern? Ich kann mir nicht vorstellen, dass die Shader bei dieser Auflösung/FPS am Limit sind, sondern gehe da mal von den RT Cores aus. Desshalb hat die Reduzierung der Shaderleistung für die RT Cores bezüglich des TDP-Limit also vllt gar nicht so viel Auswirkung.
Und sollte RTX off sein, kann die Karte die vollen TDP in die shader stecken.

 

[huberei]

Diese 9,2ms sind wenn alle RT Effekte maxed sind?

Worst case 9,2ms, dann hat man also noch 7,5ms Zeit um 60fps zu zaubern.
Wenn ein Spiel also in 4k bummelig bei 130-140fps laufen kann, dann kann es auch mit all maxed RT in 4k@60 laufen?
Also bei nicht total maxed RT effekten kann man die 9,2ms stark reduzieren und so "easy" 4k@60 erreichen.

Das klingt ehrlich gesagt deutlich besser als das was die Aluhutfraktion im Forum dauernd verbreitet.
Es ist ja fast so als ob die Leute von Enlisted das schon vor nem Monat vorgemacht haben und sich das nun bestätigt.

das ganze ist bei dieser berechnung nicht maxed out:

"Für zwei Samples bzw. Strahlen pro Pixel für die Schatteneffekte benötigte die GeForce RTX 2080 Ti inklusive Entrauschen 2,3 ms pro Frame und die Reflektionen kommen auf 4,4 ms. Kommt noch eine Global Illumination wieder mit Denoising hinzu, dauert das Rendering eines Frames noch einmal 2,5 ms länger. Insgesamt sprechen wir also von einer Rechenzeit von 9,2 ms für die erwähnten Berechnungen."

mit 2 strahlen dürfte man eher am unteren ende der eigentlich mögliche anzahl sein.

und wie schon oft erwähnt: wenn dein geliebtes Enlisted das alles schon könnte ohne bedeutende fps-einbrüche, wäre NV ja schön dämlich gewesen, die deutlich schlechtere BF5-Demo zu zeigen.
Schlussendlich werden diese beiden beispiele wohl eher das jeweilige extrem bedient haben. BF5 zu viele effekte und Enlisted eher nur wenige.
das würde sich dann auch wieder mit angaben der entwickler und dieses artikels decken, dass es stark von den verwendeten anzahl effekte abhängt obs nur in 1080p oder sogar in 4k läuft.


aber es dürfte klar sein, dass da wohl noch viel rausgeholt werden wird, wenn mehr erfahrung vorhanden ist.