Intel Xe: Hinweise auf Raytracing-Support

[eclipso]

Und was hat das jetzt wieder mit dem Thema zu tun, nämlich dass das BVH-Traversal sowohl bei nvidia, als auch bei amd durch fixed function Enheiten durchgeführt werden (was von AMD genau so auch nach außen getragen wird)?

Weisst Du es besser als der Hersteller? Kannst ja AMD erklären, dass sie sich in ihren Ausführungen irren und nur Du richtig liegst...

Wird sie auch bei Nv nicht vollständig, sondern von Shadern gesteuert, dass ist ja dein Problem. Die von dir genannte Einheit ist Teil des Texturinfrastructur, weil man genau diese Puffer verwendet um zwischenzuspeichern, was das Problem großer zusätzlicher Speicherbereiche für die Strahlenspeicherung und des BVH-Caching eliminiert (das ist ein Problem von RTRT und vor allem RTX). Man nutzt also vorhandene Universalregister die den Texturcache verwenden können.

Ich weiß es nicht besser als der Hersteller, aber als du. Das sollte dir zu denken geben! Hör also auf deine Fakenews zu verbreiten.

Die Berechnung wird parallel zum Texturprozess ausgeführt und hat mit Nv RTX-Core-Ansatz absolut nichts gemein und ist auch mit ihr nicht vergleichbar. Die Intersection ist also Teil der Textuierpipeline.

 

[ZeroZerp]

Ich weiß es nicht besser als der Hersteller, aber als du. Das sollte dir zu denken geben! Hör also auf deine Fakenews zu verbreiten.

Wieo stellst Du Dich dann hier in aller öffentlichkeit hin und behauptest es besser als der Hersteller zu wissen?
Und wieso führst Du hier den üblichen Nebelkerzen- Eiertanz auf, um nicht auf die Kernfrage eingehen und antworten zu müssen.

Es ist ganz einfach- Die Frage lautet:Wird das BVH Traversal bei nvidia und amds Patent mit fixed function Einheiten beschleunigt oder nicht?

Die Entwickler behaupten "ja". Du offensichtlich was anderes.
Jetzt stellt sich dem Leser die Frage, ob er Dir, oder den Entwicklern Glauben schenken soll.

Its that simple... und die (sinnlose) Diskussion somit beendet.
Jetzt kann jeder selbst für sich entscheiden, was Sache ist. Die Karten liegen auf dem Tisch.

 

[eclipso]

Wieo stellst Du Dich dann hier in aller öffentlichkeit hin und behauptest es besser als der Hersteller zu wissen?
Und wieso führst Du hier den üblichen Nebelkerzen- Eiertanz auf, um nicht auf die Kernfrage eingehen und antworten zu müssen.

Es ist ganz einfach- Die Frage lautet:Wird das BVH Traversal bei nvidia und amds Patent mit fixed function Einheiten beschleunigt oder nicht?

Die Entwickler behaupten ja. Du offensichtlich was anderes.
Jetzt stellt sich dem Leser die Frage, ob er Dir, oder den Entwicklern Glauben schenken soll.

Its that simple... und die (sinnlose) Diskussion somit beendet.
Jetzt kann jeder selbst für sich entscheiden, was Sache ist.

Das steht bei beiden Herstellern unter NDA, kannst du also nicht wissen.

Du hast immer noch Probleme Hardware- und Softwarelayer auseinander zuhalten was uns zum Ausgangspunkt deiner Diskussionsgrundlage zurückführt.

Du hast ein zu schwaches Verständnis für Hardware. Der "Unishader" (TCP) wird mit einem Texturprozessor ausgestattet, dass ist alles. Kein RT Core. Dieser Shader (Prozessor) kann dann vermutlich mehr als BVH, da der RT Core bereits Teil des Shaderprozessors ist. Es ist also KEIN dedizierter oder propietärer Core, an den etwas übergeben werden muss. Der Hardwareshader als Functionseinheit wird also um eine Function erweitert. AMD nennt diesen Intersectionseinheit. Die Kreuzungsergebnisse werden durch den Shader ermittelt.

Adieu RT Core!

 

[ZeroZerp]

Du hast ein zu schwaches Verständnis für Hardware.

Was Du bis jetzt einfach nicht verstanden hast ist, dass Du gegen die Aussagen der Hersteller argumentierst und mir aber dabei Unwissenheit und schwaches Verständnis diesbezüglich unterjubeln willst.

Jetzt lassen wir das mal kurz auf uns wirken...
Kannst der Entwicklungsabteilung von nvidia und amd ja mal nen Brief schreiben, dass sie keine Ahnung haben und dann die Story von frei Programmierbaren Shadern erzählen- am besten eine 1:1 Kopie aus diesem Thread.

Das wird sicher für heitere Momente und noch mehr Kopfschütteln sorgen.

Die Kreuzungsergebnisse werden durch den Shader ermittelt.

Nein- Das Ergebnis wird an die Shader übermittelt (bzw. die hit-/miss closest/any Routinen/Software- Shader angestoßen).
Würde der Shader die Kreuzungsergebnisse ermitteln, brächte es keine Einheiten mehr, die fixed function die Kreuzungsanalyse durchführen.

 

[eclipso]

Was Du bis jetzt einfach nicht verstanden hast ist, dass Du gegen die Aussagen der Hersteller argumentierst und mir aber dabei Unwissenheit und schwaches Verständnis diesbezüglich unterjubeln willst.

Jetzt lassen wir das mal kurz auf uns wirken...
Kannst der Entwicklungsabteilung von nvidia und amd ja mal nen Brief schreiben, dass sie keine Ahnung haben und dann die Story von frei Programmierbaren Shadern erzählen- am besten eine 1:1 Kopie aus diesem Thread.

Das wird sicher für heitere Momente und noch mehr Kopfschütteln sorgen.

Das steht in dem Patent das AMD angemeldet hat! Der TCP verwendet sogar die gleiche Speicheradresse wie ein TA. Bedeutet also, AMD verwendet einen völlig anderen RTRT BVH-Node. Die Durchquerungslogik mit fester Funktion, ist eine Pipeline die auf einer dafür vorgesehenen programmierbarer Einheit ausgeführt wird. Die feste Programmierbarkeit ist dabei perse nicht von nöten. Sie braucht auch keinen RT Core, sondern wird während des Textuierprozess errechnet. Texturprozessoren erhalten immer Anweisungen von einem Shader und dieser kann eine vierstufige Rayboxintersection berechnen, wobei das Ergebnis durch die ALUs geschleust wird. Dazu stellt AMD ein spezielle Engine bereit, die als Schnittstelle zu DXR fungiert.

Ja, Kopfschütteln...und viel Blah blah.

 

[ZeroZerp]

Ja, Kopfschütteln...und viel Blah blah.

Wie gesgt- Kannst AMD ja ihr...

AMD will be using both existing shading units and "fixed function" hardware while saying "flexibility is preserved" for developers.

..um die Ohren hauen. Und ihnen mal erklären, was WIRKLICH Sache ist.

Vielleicht winkt auch eine Anstellung, wenn Du ihnen erklärst, wies richtig geht. Die können schlaue Köpfe sicher dringend brauchen.

 

[eclipso]

Wie gesgt- Kannst AMD ja ihr... ..um die Ohren hauen. Und ihnen mal erklären, was WIRKLICH Sache ist.

Vielleicht winkt auch eine Anstellung, wenn Du ihnen erklärst, wies richtig geht. Die können schlaue Köpfe sicher dringend brauchen.

Abbildung 10 in dem Patent und ja, dein Hardwareverständnis ist gleich null und dein Verhalten erinnert mich stark an schaffe89.

Ich brauch mich dort nicht bewerben, also lasse bitte dein persönliches Geplänkel!

 

[ZeroZerp]

Abbildung 10 in dem Patent und ja, dein Hardwareverständnis ist gleich null und dein Verhalten erinnert mich stark an schaffe89.

Ich brauch mich dort nicht bewerben, also lasse bitte dein persönliches Geplänkel!

Du bist doch derjenige, der hier allen anderen regelmäßig Ahnungslosigkeit unterstellt und das unter einem mich wirklich langsam irritierenden Uhrvertrauen, dass das was Du Dir teilweise ausdenkst, den Tatsachen entspräche.

Wäre alles nicht so schlimm, würdest Du anderen mit Deinen nicht den Tatsachen entsprechenden Vermutungen dann nicht auch noch herabsetzen.

Ich mache es Dir aber jetzt NOCH einfacher:

[0022] A texture processor based ray tracing acceleration and method are described herein.
A fixed function BVH intersection testing and traversal (a common and expensive operation in ray tracers) logic is implemented on texture processors. This enables the performance and the power efficiency of the ray tracing to be substantially improved...

[0023] In particular, a fixed function ray intersection engine is added in parallel to a texture filter pipeline in a filter processor....

[0024] The hybrid approach (doing fixed function acceleration for a single node of the BVH tree) and using a shader .... still get the performance advantage of the fixed function hardware. .... which substantially saves area and complexity of the hardware- solution.

Direkt aus Deinem Patent. Seite 23 des PDFs.

Ich werden AMD vorschlagen, aufgrund Deines Posts das Patent korrigieren zu lassen und die "fixed function" Passagen und "fixed function hardware" bzw. hardware- solution streichen zu lassen.
Irgendwie müssen die lt. Deiner Aussagen ihr eigenes Patent missverstanden haben.

Ich bin gespannt auf die nächste Runde Eiertanz....wobei Du mir hiermit

Die Durchquerungslogik mit fester Funktion, ist eine Pipeline die auf einer dafür vorgesehenen programmierbarer Einheit ausgeführt wird.

Ja eigentlich schon recht gegeben hast...

Es stand hier nebenbei nie zur Debatte, dass AMD seine proprietäre RT Integration anders gestalten würde als nvidia, weil Du gerade immer so penetrant auf irgendwelchen RT- Cores rumreitest.

Und es steht auch nicht zur Debatte, dass AMDs Lösung unter Umständen charmanter wirkt....

 

[eclipso]

Du bist doch derjenige, der hier allen anderen regelmäßig Ahnungslosigkeit unterstellt und das unter einem mich wirklich langsam irritierenden Uhrvertrauen, dass das was Du Dir teilweise ausdenkst, den Tatsachen entspräche.

Wäre alles nicht so schlimm, würdest Du anderen mit Deinen nicht den Tatsachen entsprechenden Vermutungen dann nicht auch noch herabsetzen.

Ich mache es Dir aber jetzt NOCH einfacher:


Direkt aus Deinem Patent. Seite 23 des PDFs.

Ich werden AMD vorschlagen, aufgrund Deines Posts das Patent korrigieren zu lassen und die "fixed function" Passagen und "fixed function hardware" bzw. hardware- solution streichen zu lassen.
Irgendwie müssen die lt. Deiner Aussagen ihr eigenes Patent missverstanden haben.

Ich bin gespannt auf die nächste Runde Eiertanz....

Du langweilst mich immer noch, sieh dir einfach mal die RDNA Compute Unit an und wo die TMU-TFU sitzt, die ist anders aufgebaut als die von GCN. Genau dort findest du auch das Intersect und nein, man kann dieses Ding sogar umgehen damit die Flexibilität in der Programmierung erhalten bleibt. AMDsTextur RT ist dabei eine Mischung aus Pipelinestufen in Hard- und Software. Die Texturprozessoren als Teil der Compute Unit wurden also um diese Funktion erweitert. Es ist kein dedizierter Core, wie ein RT Core von Nöten, das Intersect kann parallel durchlaufen werden.

Einfach mal mit RDNA beschäftigen, bevor man hier Blödsinn behauptet und dazu noch unterstellt dx fördere proprietäre Hardwareansätze und unterstützt sie. Tut es überhaupt nicht! Es schafft gemeinsame Standards mit Shaderprotokollen seit Einführung von dx8.

Navi vs. Turing: An Architecture Comparison - TechSpot

 

[ZeroZerp]

AMDsTextur RT ist dabei eine Mischung aus Pipelinestufen in Hard- und Software.

Ja- Mit einer fixed function Einheit.
Und ja- Wie alle fixed function Einheiten kann man diese auch per Software abbilden, was AMD ja in diesem Zusammenhang in Unterparagraphen zwar zu Wahl stellt, jedoch immer wieder die dedizierte Lösung erwähnt.
Und ja- AMD lässt einem die Wahl die fixed function Einheit zu übergehen.

Was trägt das zum Thema bei, außer dass Du Dich, wie erwartet, in alle Richtungen windest.

Einfach mal mit RDNA beschäftigen, bevor man hier Blödsinn behauptet

Du verstehst es wohl immer noch nicht? Das sind Zitate von AMD. Was hat das Patent mit RDNA zu tun?

Wieso bringst Du auf einmal GCN ins Spiel? War da jemals dediziert beschleunigtes Ray Tracing angedacht? Wieder nur was um in einem Post 1000 Themen anzuschneiden, nur um nicht Farbe bekennen zu müssen?

Du weisst doch noch nicht mal, ob das Patent genau so zum Tragen kommt.

und dazu noch unterstelle dx fördere proprietäre Hardwareansätze und unterstützt sie.

Uii- Wieder Themenwechsel und neue Nebelkerze. Jetzt bin ich ja mal gespannt, wo ich geschrieben hätte, dass DX proprietäre Hardwareansätze fördere. Wird ja immer wilder hier...

Rede Dich doch einfach nicht weiter um Kopf und Kragen. Du hast die Lage falsch eingeschätzt und gut ist es.
Wie gesagt- Weiter oben hast Du mir ja im weitesten Sinne schon zugestimmt.

 

[eclipso]

Du verstehst es wohl immer noch nicht? Das sind Zitate von AMD. Was hat das Patent mit RDNA zu tun?

Rede Dich doch einfach nicht weiter um Kopf und Kragen. Du hast die Lage falsch eingeschätzt und gut ist es.
Wie gesagt- Weiter oben hast Du mir ja im weitesten Sinne schon zugestimmt.

Ich stimme dir nirgends zu, weil dir nicht klar ist, dass auch eine Software fixed function sein kann. Das ist ein Oberbegriff für eine Zuordnung von Prozessen, was man bereits vor Beginn der Entwicklung plant und richtet sich auch an den verfügbaren Hardwareressourcen aus. Es geht dabei ziemlich allgemein um die Organisation und Zuordnung, innerhalb einer API oder Engine, damit in der
Programmierabstraktion Grafikpipelinestufen ausgeführt werden können. Das generische Modell ermöglicht vor allem hohe Fexibilität beim modelieren der Daten. AMD geht beim "Texturraytracing" daher von fixed function aus. Dabei handelt es sich um shaderbasierende APIs und auch Engines.

Wenn es ist wie du behauptest, wie stellt man unter der Duniaengine Wasser dar? Klar, ich rede mich um Kopf und Kragen. Von dir kommt ja nichts weiter als cop&paste und dein eigner Erguss an Fehlinformation. Du hast nie und nimmer jemals etwas unter GCN, egal welche Iteration programmiert. Weil du glaubst mit einem Nv RT umhergespielt zu haben, outest du dich hier als AMD Experte für proprietäre Hardware und meinst AMD täte es Nv gleich. Tun sie nicht, dass scheint du nicht verstehen zu wollen.

 

[ZeroZerp]

Nv RT umhergespielt zu haben, outest du dich hier als AMD Experte für proprietäre Hardware und meinst AMD täte es Nv gleich. Tun sie nicht, dass scheint du nicht verstehen zu wollen.

Ich schrieb erst in Post #228 noch:

Es stand hier nebenbei nie zur Debatte, dass AMD seine proprietäre RT Integration anders gestalten würde als nvidia, weil Du gerade immer so penetrant auf irgendwelchen RT- Cores rumreitest.

Was für mich der letzte Sargnagel dafür ist, dass Du mich mit Deinem Geschreibsel doch nur veräppeln willst. Denn so einen instatant- Gedächtnisschwund hat niemand.
Wolltest mir ja vor kurzem erst noch andichten, dass ich behaupten würde, dass DX proprietärem Hardwaredesign Vorschub leiste.

Dann immer wieder damit kommen, dass RT auch anders betrieben werden kann, Dinge statt in dedizierten Einheiten oder gern auch in Silikon gegossenen Logiken, in frei programmierbaren Einheiten erledigt werden können.
Echt jetzt? Das sind ja ganz neue Erkenntnisse....

Wieso nutzen wir für Grafikberechnungen denn keine 08/15- CPUs? Hier winkt captain obvious.
Geht das mit dedizierten Spezialeinheiten vielleicht schneller? Kann es sein, dass die in Silikon gegossenen BVH Traversal/Ray intersection Einheiten vielleicht einfach schneller sind, als die 08/15 unified Shader?

Du koppelst ein seit Jahrzehnten unabhängiges Verfahren zur Errechnung realistischer Grafik an irgendwelche RT- Cores? Wie kriegt denn nvidia RTRT dann mit den GTX Grafikkarten hin?

Dann zu Deinem Definitionswust- Ist eine CPU ein Hardwarebeschleuniger, weil sie Berechnungen schnell durchführt?
Wieso und welche fixed function Einheiten existieren genau auf CPUs und GPUs?

Du wirfst so viele Dinge auf so viele Ebenen in einen Topf, dass es einem schwindlig wird.
Und unterstellst mir im gleichen Zug noch allerlei Dinge, gegen die Du anschliessend einen Scheinkampf führst.

Viel Spaß noch mit Dir selbst ...

 

[gaussmath]

Und was hat das jetzt wieder mit dem Thema zu tun, nämlich dass das BVH-Traversal sowohl bei nvidia, als auch bei amd durch fixed function Enheiten durchgeführt wird (was von AMD genau so auch nach außen getragen wird)?

Bist du sicher? Das Traversieren der Dreiecksmenge wird ja zum einen durch die optimierte Datenstruktur beschleunigt und zusätzlich in meiner Vorstellung durch eine spezielle Cache Struktur. Sobald die Untermenge an Dreiecken so weit wie möglich runtergebrochen/gefiltert sind, greifen die fixed function Einheiten und berechnen die Ray Intersection. Im Vergleich mit einfachen Arithmetiken muss die relativ komplexe Operation mit spezialisierten Einheiten berechnet werden. Alles andere erscheint mir widersinnig, wenn man sich die Gleichung mal hinschreibt und auf sich wirken lässt.

 

[ZeroZerp]

Sobald die Untermenge an Dreiecken so weit wie möglich runtergebrochen/gefiltert sind, greifen die fixed function Einheiten und berechnen die Ray Intersection.

Genau so ist es- Eine berechtigte Korrektur, weil das BVH Traversal an sich bei AMD Softwaregesteuert ist.

LG
Zero

 

[hks1981]

Anstatt man sich dem Thema widmet wirft man wieder mit Fachbegriffen, angekratzten Ego und wer weiß mehr herum. Schade, denn somit ist das immer eine never ending story was einem 08/15 User wie ich es bin einfach nur gewaltig nervt.

 

[eclipso]

?

Das Problem ist das du immer noch nicht verstanden hast, dass AMD genau das Gegenteil von dem beschreibt was du behauptest, sie wollen keine reine fixed function und ich weiss auch nicht woher du diesen Quatsch hast! Die Filterunit oder die Intersectionsengine lässt sich einzeln oder eben nicht benutzen/einbinden, oder beides zusammen, wird aber immer von einem Shader controlled!

The hybrid approach (doing fixed function acceleration for a single node of the BVH tree) and using a shader unit to schedule the processing addresses the issues with solely hardware based and/or solely software based solutions. Flexibility is preserved since the shader unit can still control the overall calculation and can bypass the fixed function hardware where needed and still get the performance advantage ofthe fixed function hardware. In addition, by utilizing the texture processor infrastructure, large buflersfor ray storage and BVH caching are eliminated that are typically required in a hardware raytracing solution as the existing VGPRs and texture cache can be used in its place, which substantially saves area and complexity of the hardware solution.

Du kapierst das einfach NICHT. Lies diesen Text doch mal so, dass du NICHT RTX ähnliches ausführen willst, sondern genau das Gegenteil!

[0036] FIG. 10 is a more detailed block diagram of an example texture processor based ray tracing accelerator system 1000 in accordance with certain implementations. The texture processor based ray tracing accelerator system 1000 includes a shader unit or shader processor 1005 connected to or in communication with (collectively “connected to”) a texture processor 1010, which in turn is connected to a cache 1015. The texture processor 1010 includes a texture address (TA) unit 1020 which is connected to a texture cache (TCP) 1025, which in turn is connected to the cache 1015. The texture address unit 1020 and the texture cache 1025 are also connected to a texture data (TD) unit 1030. The texture data unit 1030 is a data filtering unit and includes a filter pipeline unit 1040 which is functionally in parallel with an intersection engine 1045. The intersection engine 1045 is connected to the shader unit 1005 via a texture data retum path 1050. In an implementation, the filter pipeline unit 1040 and the intersection engine 1045 can be integrated. In another implementation, the texture data unit 1030 can include only the intersection engine 1045.

Es scheint sogar soweit prorammierbar zu sein, dass die Intersectionseinheit durch eine CPU ersetzt werden kann. Mit einstufiger fixed function [Single Node in Hardware] meinen sie Nv RT Cores ohne sie direkt anzusprechen und glauben ihre Shaderbasierende Variante hat Vorteile gegenüber dieser ff-Hardware oder einer reinen Softwareemulation wie PIX!

 

[HardwareHighlander]

... dass auch eine Software fixed function sein kann.

Der war geistreich.^^

Bist du sicher? Das Traversieren der Dreiecksmenge wird ja zum einen durch die optimierte Datenstruktur beschleunigt und zusätzlich in meiner Vorstellung durch eine spezielle Cache Struktur.

In der Demo von Crytek wird das ja durch die CPU´s beschleunigt bzw. auch in World of Tanks.
In der bisherigen DXR Versionen wird das Traversieren der Dreiecksmenge und die Schnittpunktberechnung durch die RT-Cores beschleunigt, oder nur letzteres?
Soviel ich weiß beides?

Das Problem ist das du immer noch nicht verstanden hast, dass AMD genau das Gegenteil von dem beschreibt was du behauptest...

Verstehe ich nicht. Wo wird der elementare Unterschied zwischen AMD und Nvidia liegen? Den sehe ich, wenn man sich eure Diskussion anschaut und das was bisher bekannt ist, einfach nicht.

 

[gaussmath]

In der Demo von Crytek wird das ja durch die CPU´s beschleunigt bzw. auch in World of Tanks.
In der bisherigen DXR Versionen wird das Traversieren der Dreiecksmenge und die Schnittpunktberechnung durch die RT-Cores beschleunigt, oder nur letzteres?
Soviel ich weiß beides?

Gute Frage. Sobald die Menge der gefilterten Dreiecke, nachdem alle Vorbedingungen geprüft wurden, die nicht einer expliziten Schnittberechnung bedürfen, größer 1 ist, muss man streng genommen annehmen, dass die RT-Cores am Traversieren der Datenstruktur beteiligt sind.

Und nochmal zum Thema "fixed function". Selbst simpelste Arithmetik wie z=x+y muss ja "fixed", also fest verdrahtet sein. Die bisherige Diskussion hat sich sehr auf den Begriff "fixed function" versteift, dabei geht es ja letztlich darum, dass eine komplexe Operation mit weniger Zyklen abgearbeitet werden kann, als wenn diese einfach nur mit Basisoperationen kombiniert abgebildet wird. In der Mathematik nennt man übrigens das Hintereinanderausführen von Funktionen eine Komposition. So gesehen sind RT-Einheiten spezialisierte Hardware-Einheiten, die eine hinsichtlich der Zyklen optimierte Komposition ermöglichen.

Wo wir beim Thema Begriffe sind, ich finde es schade, dass sich in der modernen Informatik und insbesondere Technik-Szene im Bereich Computergrafik die Begrifflichkeiten von der Basis abgespalten haben. Es gibt teilweise 200 Jahre alte Grundlagen aus der (analytischen) Geometrie, die einfach so ignoriert werden. Das gilt auch für Graphentheorie, Mengenlehre und Geometrische Topologie. Das finde ich bedauerlich, weil ich so ausgebildet wurde. Wenn ich Papers über das Thema lese, habe ich teilweise arge Verständnisprobleme, weil die Begrifflichkeiten für mich aus einer anderen Welt sind.

Das Problem dabei ist nicht nur, dass mir das Unbehagen bereitet, sondern, dass Mathematiker über hunderte von Jahren hinweg konsistente Begriffsgebäude aufgebaut haben, die teilweise komplett eingerissen werden, weil es modern und fancy klingen soll. Kann man ja machen, aber dann bitte nur fürs Marketing.

 

[ZeroZerp]

Das Problem ist das du immer noch nicht verstanden hast, dass AMD genau das Gegenteil von dem beschreibt was du behauptest, sie wollen keine reine fixed function und ich weiss auch nicht woher du diesen Quatsch hast!

Ich weiss auch nicht woher Du das Dir schon wieder aus den Fingern saugst.

Wieder gleiches Prinzip. Mir unterstellen irgendwelche Dinge behauptet zu haben (dass AMD alle Operationen fixed function durchführen würde). Natürlich wieder all das vergessen, was noch 2-3 Posts vorher eben genau Gegenteiliges geschrieben wurde und dann quasi gegen den Strohmann argumentieren.

Du führst hier eine Diskussion mit Dir selbst und den Aussagen von AMD. Immernoch nicht verstanden?

Die Filterunit oder die Intersectionsengine lässt sich einzeln oder eben nicht benutzen/einbinden, oder beides zusammen, wird aber immer von einem Shader controlled!

Das hat nichts mit dem Thema zu tun. Ich kann bei nvidia auch die gesamte RTX Pipeline umgehen und das ganze per Compute lösen, wie sie es übrigens auf den non- RTX Karten schon lange machen.
Dennoch hat die Karte fixed function Einheiten, genau wie sie es das Patent von AMD in zig Paragrafen, von welchen ich Dir einige schon auf dem Silbertablett serviert hab, anführt.

Sie schreiben sogar warum sie das so machen, weil sie die Vorteile der fixed function Einheiten (hohe Geschwindigkeit) mit der Flexibilität/Wahl einer "Shadersteuerung" verbinden wollen.

Und Du zitierst es sogar noch, dass sie weder eine rein hardwaregestützte Umsetzung noch eine rein softwaregestützte Umsetzung beschreieben und hintelegst es auch noch fett.
Behauptest aber, dass die Lösung rein Shaderbasiert sei, was ja einer Softwarelösung gleichkäme.

Ich stelle Dir eine ganz einfache und eindeutige Frage (die Du mir wie immer nicht beantworten wirst).
Wird es innerhalb des Texturprozessors dedizierte Schaltungen geben, die die ray intersection engine darstellen oder nicht? Es dabei schon, dass ein einziger Transistor dazu kommt oder eben nicht.
Und jetzt bitte nur EIN EINZIGES MAL Farbe bekennen.

Du kapierst das einfach NICHT. Lies diesen Text doch mal so, dass du NICHT RTX ähnliches ausführen willst, sondern genau das Gegenteil!

Du kapierst nicht, dass das Endergebnis der Berechnungen beider Hardwarelösungen gleich ist.
Und Du kapierst nicht, dass sich die Rechenoperationen zur Ray Intersection und der Art und Weise, dass diese fixed function in silicon ausgeführt werden, nicht unterscheiden.
Und Du kapierst immer noch nicht, dass AMD das schwarz auf weiss sowohl in seinem Patent, als auch der Öffentlichkeit gegenüber genau so kommuniziert.
Wieso unterstellst Du also die ganze Zeit AMD Unwissenheit und dass sie keine Ahnung von ihrer Hardware hätten?
Findest Du das nicht selbst etwas schräg?

Es scheint sogar soweit prorammierbar zu sein, dass die Intersectionseinheit durch eine CPU ersetzt werden kann.

Leidest Du wieder an Gedächtnisverlust? Was schrieb ich denn noch kurz zuvor? Eben genau das!
Du kannst alles über Software bzw. eine genügend komplexe CPU berechnen, was aus Performancegründen alles andere als anzuraten ist.
Genau wie es dämlich wäre die ray intersection engine für deren spezialisierte Berechnungen zu umgehen, weil sie es einfach schneller macht.
DAS IST DER EINZIGE Zweck von fixed function Einheiten!!!
Siehe Video De-/Enkodierung auf den GPUs.

Essential the fixed function pipeline is a hardwired implementation of a, well, fixed program, through which each piece of data a GPU processes traverses, without the ability to change the details of any step. The only thing you can parameterize are the occasional branch to switch between hardcoded paths in the program ...

Siehe auch hier- Das gleiche Prinzip:
AMDs Video Coding Engine
Fixed Function:
File:AMD VCE fixed mode.svg - Wikipedia

Hybrid:
File:AMD VCE hybrid mode.svg - Wikipedia

Software:
Bei dieser Methode würde der VCE Block komplett wegfallen...

Mit einstufiger fixed function [Single Node in Hardware] meinen sie Nv RT Cores ohne sie direkt anzusprechen und glauben ihre Shaderbasierende Variante hat Vorteile gegenüber dieser ff-Hardware oder einer reinen Softwareemulation wie PIX!

So ist es! Aber nur weil sie shaderbasiert ist (ist sie in gewisser Weise bei RTX auch), schliesst das nicht aus, gewisse Berechnungen schneller durch spezialisierte in Hardware gegossene Einheiten zu beschleunigen (wie es das Patent eben auch beschreibt).

@gaussmath
Die Problematik der Begrifflichkeiten, die Du hier ansprichst, ist in meinen Augen überhaupt erst für 99% dieser überflüssigen Diskussionen ursächlich.

Geht ja schon los bei "Shader". Der eine meint den Prozessor, der andere die Software/das Programm.
Und so gibt es wie Du richtig anmerkst so viel Unschärfe und Mehrdeutigkeiten dieser Begriffe, so dass es in vielen Bereichen zu solchen Verwirrungen kommen muss...

LG
Zero

 

[eclipso]

Ich weiss auch nicht woher Du das Dir schon wieder aus den Fingern saugst.

Du kapierst nicht, dass das Endergebnis der Berechnungen beider Hardwarelösungen gleich ist.

Siehe auch hier- Das gleiche Prinzip: AMDs Video Coding Engine

Ich glaube du versuchst nur an Informationen zu kommen, die du nicht hast. Untermauert mit wilden Spekulationen wie das dick markierte.

Das Ergebnis kann absolut nicht gleich ausfallen, was auch immer du damit meinst, weil die Intersectengine, wenn nur eine Boundingebene beim BVH building process in Hardware erstellen könnte. Wurde den Devs schon ab Vega experimentell mit RR-SDK zur Verfügung gestellt. Das hilft Dram Schreib- und Lesezugriffen zu vermeiden. Das heißt, die vorhandene Schnittpunktmenge wird lokal gehalten und gleichzeitig auf Traversen in der Nähe befindlicher Ray übertragen. Anscheinend ist dir nicht klar, dass wenn die Daten an den RT Core übergeben werden und er rechnet, der Shader warten muss. Im Gegensatz zu Nvs Modell mit dedizierten RT Cores, fällt das Ganze also kohärenter aus und braucht weniger Durchläufe, damit auch deutlich weniger Cachezugriffe und Zeit.

Was VCE oder Microsoft's Mediaengine angeht, ist es tatsächlich so, dass diese auch unter dx dediziert ausgeführt wird, werden darf. Das ist Absicht und seither so.

Die RT-Textur-Modelle werden übrigens mit 10 Methoden und weiteren 10 Konfigurationen zum Schluss des Patents zusammengefasst, wobei überhaupt nicht klar ist, ob es jemals zur Anwendung kommt. Es könnte breit gefächert auf verfügbarer Hardware übertragen werden (Asics, APUs, CPU+GPU, GPU).

AMDs Roundmap führte RTRT zuerst als Softwared based aus, dann Hardware funktional und dann aus der Cloud heraus. Ob sie diese zwischenzeitlich verworfen haben, ist nicht klar und nehmen sie dazu keine Stellung.

Du schreibst also einen Haufen wilder Spekualtionen mit deiner Behauptung es funktioniere wie bei Nv oder führe zum gleichen Ergebnis. Tut es nicht! Das versuche ich dir Seitenlang zu erklären. Ob das hier in die Vorstellungskraft einiger passt, ist mir dabei relativ egal.

Den RT Core gibt es vermutlich nur, weil er einen stackbasierenden Algorithmus beschleunigt und die Cachegeschwindigkeiten in der Nv GPU Hierachie nicht ausreichen würden, die Daten schnell genug bereitzustellen, was AMD anders angeht. Sie verfügen intern über eine geringere Latenz. Nv müsste wohl einen weiteren schnellen Cache verbauen. Wenn der RT Cores rechnet oder überlastet ist, ist er überlastet, er rechnet nicht schneller und die Ausgabelatenz ist nicht beeinflussbar. Shader kontrolliert wird der Berechnungsschritt verworfen.