Intel Xe: Hinweise auf Raytracing-Support

Diese Extensions sind jedoch kein Bestandteil des Vulkan-API.
Trotzdem enthält diese Extension (SDK) den llv Loader und bestimmte Layer, das Windows auch unterstützt wird. Sie ist somit die Schnittstelle und nicht dx. Was sollte also dx mit proprietärer Hardwareunterstützung zu tun haben und dessen Schnittstellen dazu dienen dedizierte GPU Entwicklerhardware (wie es ZeroZerp beschreibt) zu unterstützen. Gar nichts.

Nur weil Microsoft keine offizielle Vulkan-API-Unterstützung liefert, heißt das nicht das es keinerlei Hardware gäbe die es könnte. Es gibt sie, nur nicht unter Windows.

Auf einem Mac lief doch Radeon Ray mit einer W9000. Das Raycasting fällt kaum geringer aus.
 
Ich identifiziere mich durchaus mit dem Stück Hardware in meinem PC, was ganz einfach daran liegt, weil ich dafür knapp eine Woche im Schichtdienst geschuftet habe und ich durchaus auf meine Grafikkarte stolz bin.
Mir ist es aber relativ von welchem Hersteller sie kommt. Ich nehme immer gerade das was ich derzeit als das beste erachte.
Und das war dieses mal keine AMD, sondern eine Nvidia GPU, denn sie soll wie schon die GTX 1060 mindestens 3 oder wenn nicht besser 4 Jahre halten.

Als nächstes werde ich den Prozessor aufrüsten und dort wird es ziemlich sicher ein AMD Prozessor werden.
Sehr wahrscheinlich ein Ryzen 7 3700x, nachdem die vierte Generation herausgekommen ist. Man muss ja nicht immer das aktuellste haben.

Nice Story, Bro. Du musst wirklich wahnsinnig stolz auf deine hart erschuftete GPU sein wenn du dich extra in einem Forum als RTX-Hobby-Drohne anmeldest, Grabenkämpfe kritisierst und dann selbst aktiv dran teilnimmst. Und dann die 1950XTX/3700x-Storys.. Wie aus dem Lehrbuch. Einfach zu köstlich. Schade das Nvidia keine CPU's baut, was? Erzähl hier was du erzählen willst, aber bitte versuch nicht mir irgendwas weiß zu machen. Das wird nicht klappen. Ich weiß vielleicht nicht genau wer du bist (obwohl ich ne Vermutung habe), aber ich weiß ganz genau was du bist.

Viel Spaß "euch" allen noch. Ich bin mal raus. Mit nur einem Account kann man hier eh schon lange nicht mehr mithalten.
 
Wie wäre es denn mal mit einem Coming out, der ganzen Nutzer die einen weiteren Account angemeldet haben?

Ich bin und bleibe nur ich!

Jetzt alle anderen bitte.

Wenn ich mich zurückerinnere was in den 90er Jahren abgelaufen ist, sind wir finanziell gesehen heute aus dem Schneider.
Ich habe meine GTX 1060 vor 4 Jahren gekauft und habe sie auch auch nur getauscht, weil sie den Geist aufgegeben hat.
Mein erster personal computer der Intel Compaq Presario CDS510 inkl. Windows 95 hat gerade mal 2 Jahre gehalten, um damit die neusten Filme und Spiele zu genießen. Danach war der PC nicht mehr auf der Höhe der Zeit.

2200 Mark habe ich dafür ausgegeben, was heute inkl. Inflation mal locker über 2000 Euro sind.
Heutzutage biste mit einem flotten System aus 2014 oder gar 2013 noch ganz gut dabei.
Also ich stimme dir zu! Es waren schöne Zeiten, die aber auch sehr, sehr teuer waren. :)



Nunja, abhängig von deinen Ansprüchen an Auflösung und eye-candy.
Ich wäre mit meiner 1060 noch ein oder gar zwei Jahre mit meinem WUXGA Bildschirm ausgekommen und dabei spiele ich fast immer alles auf ultra.
Gut, nicht jede Einstellung steht ganz rechts, aber fast alle.



Da könnte es sich, Gott bewahre, ja auch lohnen die Anschaffung mal etwas hinauszuzögern und bei der nächsten Generation zuzuschlagen.
Vor allem da Raytracing, Pathtracing oder wie auch immer es morgen oder übermorgen genannt wird, etwas später besser in Tritt kommt.
Ich habs damals mit Crysis genau so gemacht. Meine 1950XTX erst einmal behalten und dann mit GTX 285 Crysis noch einmal herausgekramt.

Crysis habe ich rythmisch gespielt ;) erts auf einem Laptop in 720p, dann jedes Jahr fast einmal mit neuer GPU !

Viel Spaß "euch" allen noch. Ich bin mal raus. Mit nur einem Account kann man hier eh schon lange nicht mehr mithalten.

Das befürchte ich auch, aber ich werde weiter machen wie gehabt. Egal ob mir ein und die selbe Person mit 20 Accounts die Welt erklären will, oder nicht. Habe vor einigen Jahren schon wilde Dinge miterlebt rund ums Thema Wakü und Leuten die alles besser wussten, sogar besser als eigene Messungen, die auch noch durch öffentliche Messungen bestätigt wurden.

Niemals aufgeben! ;)
 
W
Da könnte es sich, Gott bewahre, ja auch lohnen die Anschaffung mal etwas hinauszuzögern und bei der nächsten Generation zuzuschlagen.

Und manche schlagen eben heute schon zu und freuen sich als early-adopter diese Effkete zu genießen. Jedem das seine.

Nice Story, Bro. Du musst wirklich wahnsinnig stolz auf deine hart erschuftete GPU sein wenn du dich extra in einem Forum als RTX-Hobby-Drohne anmeldest, Grabenkämpfe kritisierst und dann selbst aktiv dran teilnimmst.

Kann schon sein, dass er ein Doppelaccount ist, kann auch sein, dass er keiner ist, letztendlich eh wurscht.
Ich sehe aber nicht wo er an Grabenkämpfen teilnimmt oder provoziert -also sich auf dein Level begibt.
Ich würde vorschlagen du respektierst seine Meinung, so wie jeder hier auch andere respektieren sollte - solange sie halbwegs im realistischen Rahmen bleiben.

Erzähl hier was du erzählen willst, aber bitte versuch nicht mir irgendwas weiß zu machen. Das wird nicht klappen. Ich weiß vielleicht nicht genau wer du bist (obwohl ich ne Vermutung habe), aber ich weiß ganz genau was du bist.

In erster Linie ist er als neuer User zu behandeln und nicht sofort derart anzufeinden,nur weil er vielleicht eine dediziert andere Meinung hat.
Kann auch Flankendiskriminator der 10te oder Mimimimimi der 5te sein.:ka:
Aber prinzipiell respektlos von dir.

Wie wäre es denn mal mit einem Coming out, der ganzen Nutzer die einen weiteren Account angemeldet haben?

Ich bin und bleibe nur ich!

Ja, wäre mal nicht schlecht. Ich bin seit jeher mit einem Account hier, habe nur den Namen ändern lassen.
Ich würde mal sagen, es steht 50:50. So groß ist das Forum ja nicht mehr.:ugly:
 
Zuletzt bearbeitet:
Und manche schlagen eben heute schon zu und freuen sich als early-adopter diese Effkete zu genießen. Jedem das seine.



Kann schon sein, dass er ein Doppelaccount ist, kann auch sein, dass er keiner ist, letztendlich eh wurscht.
Ich sehe aber nicht wo er an Grabenkämpfen teilnimmt oder provoziert -also sich auf dein Level begibt.
Ich würde vorschlagen du respektierst seine Meinung, so wie jeder hier auch andere respektieren sollte - solange sie halbwegs im realistischen Rahmen bleiben.



In erster Linie ist er als neuer User zu behandeln und nicht sofort derart anzufeinden,nur weil er vielleicht eine dediziert andere Meinung hat.
Kann auch Flankendiskriminator der 10te oder Mimimimimi der 5te sein.:ka:
Aber prinzipiell respektlos von dir.



Ja, wäre mal nicht schlecht. Ich bin seit jeher mit einem Account hier, habe nur den Namen ändern lassen.
Ich würde mal sagen, es steht 50:50. So groß ist das Forum ja nicht mehr.:ugly:

Bevor man andere über den Umgangston belehren möchte, kann man ja selbst versuchen den Anfang zu machen.

Und da helfen Formulierungen wie "also sich auf dein Level begibt" ganz sicher nicht ;) DAs meine ich natürlich nicht böse!

Nur als gut gemeinter Tipp natürlich. Ich versuche es auch.
 
Diese ganze Doppelaccount Geschichte erinnert mich irgendwie an asus1889 aka. Knut1234 aka. Fluffy82 aka. olaf aka. Norbie61 aka. Eisvogel196 aka. [...]
 
Du schreibst wirres Zeug; etwas mehr Fokus würde dem Verständnis deines Posts zugute kommen.

Trotzdem enthält diese Extension (SDK) den llv Loader und bestimmte Layer, das Windows auch unterstützt wird. Sie ist somit die Schnittstelle und nicht dx.

Ändert nichts daran, dass Vulkan selbst derzeit keine Raytracing-Unterstützung bietet. nVidia kann diese Funktionalität derzeit nur aufgrund der für Erweiterungen offenen Struktur von Vulkan selbst beisteuern und genau das machen sie hier mit VK_NV_ray_tracing.

Was sollte also dx mit proprietärer Hardwareunterstützung zu tun haben [...]

Das weiß ich nicht, das hast Du geschrieben. DirectX geht hier den genau entgegengesetzten Weg und stellt ein von der Hardware abstrahierendes API zur Verfügung. In Bezug auf Raytracing hat es ein paar Datenstrukturen und API-Funktionsaufrufe definiert, die die Treiberentwickler von nVidia/AMD/Intel erfüllen müssen, sodass deren Hardware mit DXR zusammenarbeitet.

Nur weil Microsoft keine offizielle Vulkan-API-Unterstützung liefert, heißt das nicht das es keinerlei Hardware gäbe die es könnte. Es gibt sie, nur nicht unter Windows.

Noch kryptischer geht es nicht? a) Was hat Microsoft mit Vulkan zu tun? Das ist so als wenn man sagen würde "Nur weil Mercedes keine BMWs baut ...". b) Und was haben 3D-APIs wie Vulkan oder DirectX mit konkreter Hardware zu tun? Auch relativ wenig, denn auch Vulkan verfolgt wie DirectX und OpenGL das Ziel von der Hardware zu abstrahieren. c) Und in welchem Kontext sollte jetzt irgendwelche Hardware stehen, die was können soll oder auch nicht? Weder Microsoft noch die Khronos Group fertigen Hardware.
Wie ich schon schrieb, selbst mein i486er konnte Raytracing, jedoch ist das für das was hier im PCGH-Forum wohl die meisten interessieren dürfte, irrelevant, da es hier um (hybrides) Echtzeitraytracing geht und da kommt man erst mit dedizierter Hardware (sinnvoll) hin. Insbesondere, wenn man sich das Haupteinsatzgebiet Gaming ansieht, das unvorteilhafterweise das Ganze auch noch gleich mit hohen Bildraten und Auflösungen kombiniert, sodass einmal mehr reguläre Hardware (wie bspw. eine einfache Berechnungn über die Shader-Prozessoren) nur zu ungenügenden Ergebnissen führen. *)

Auf einem Mac lief doch Radeon Ray mit einer W9000.

Was hat das mit PCGH und Games zu tun, oder mit Windows und DirectX? Wie schon zuvor gesagt, du kannst auch Raytracing mittels einer alten Kepler-GPU via CUDA berechnen lassen, nur hat das nichts mit Echtzeitraytracing zu tun.
Abseits dessen weist AMD sein Radeon Rays SDK nur als für Windows und Linux verfügbar aus. ;-)


*) Entsprechend verwendet man mit der Einführung der Technologie auch keine reinen Raytracing-Engines sondern ein Hybridrenderingverfahren, denn für vollständiges Raytracing reicht die Rechenleistung noch längst nicht aus und daran wird sich auch in den kommenden Jahren nichts ändern.
Pascal bricht nicht umsonst ein, sobald zu viel Raytracing-Rechenlast im Sichtbereich anfällt (gut zu testen in BF5) wohingegen Metro Exodus mit seiner GI-Implementation eine gleichmäßig hohe Raytracing-Last pro Frame erzeugt, sodass das Spiel hier auf Pascal in FullHD mit aktiviertem Raytracing grundsätzlich unspielbar ist.
Die im März'18 vorgestellte Star Wars Elevator-Demo lieft nicht umsonst auf einer DGX mit vier Volta-Karten, da hier noch die regulären Shader herhalten mussten, jedoch kann man ein 20.000+ US$-System nicht wirklich als mainstreamtauglich bezeichnen.


Ergänzend dazu der Hinweis, dass viele fälschlicherweise immer gerne dazu neigen nVidia's "RTX"-Begriff mit Raytracing gleichzusetzen, was schlichtweg falsch ist. Ersteres ist ein Produktname für nVidia's LowLevel-Raytracing-Softwarestack, der auch für die Neubenennung der aktuellen Grafikkartengeneration ausgeschlachtet wurde, letzteres ist ein bereits im letzten Jahrtausend entwickeltes mathematisches Verfahren zur Berechnung dreidimensionaler Bilder. (Und genaugenommen kann man den Begriff sogar auch nur als Oberbegriff für mittlerweile eine Vielzahl differenzierter, noch viel komplexerer Methoden für noch realistischere, physikalisch korrekte Bilder verstehen.)
Schlussendlich ist das, was nVidia derzeit als "RTX" vermarktet, nur eine mögliche, technisch Implementation. AMD wird in diesem Zuge seine RDNA2-Architektur in den Markt bringen, die die notwendigen Funktionalitäten anscheinend etwas anders als nVidia implementieren wird und wer weiß, welche Art der Implementation Intel sich vorbehält. Solange sich aber bspw. alle an die zusammen mit Microsoft definierten API-Spezifikationen halten, werden diese unterschiedlichen GPUs alle Raytracing unter DirectX 12 bieten.


Der Vollständigkeit halber: Natürlich brauch man nicht unbedingt eine Turing-GPU für Raytracing, denn am Ende gibt es hier nur zwei einfache Operationen die ausgeführt und auch in Hardware unterstützt werden: a) Die Intersection-Berechnung alias Strahlverfolgung/Schnittberechnung und das Traversieren der Szenen-Datenstruktur (BVH), d. h. man muss in einer großen Datenmenge von Polygonen/Dreiecken möglichst schnell diejenigen finden, die für den Intersection-Test sinnvoll infrage kommen.
Entsprechende Verarbeitungsschritte kann man bei Bedarf auch komplett in Software erledigen. Beispielsweise das DX12 SDK enthält einen kompletten Software-/CPU-basierten Renderpfad für das Debugging von Raytracing, der aber natürlich extreeem langsam rendert.
Intels Embree Raytracing-Kernels sind da weitaus leistungsfähiger, die eine vollständige Raytracing-Engine über viele CPU-Kerne verteilen und selbst AVX-512 für ein beträchtliches Leistungsplus ausnutzen können. Die Leistung ist immens taugt aber immer noch nur für bspw. einen interaktiven Viewport-Renderer für das Modelling, nicht jedoch für Games.
Der nächstschnellere Weg ist die Ausnutzung der universellen Rechenleistung der GPUs über die Shader-Prozessoren, die seit Jahren unentwegt zunimmt. nVidia's RTX-Entwicklung begann auf diese Weise, indem man den RTX-Softwarestack entwickelte, der die Raytracing-basierten Funktionsaufrufe bündelte und hinten heraus auf die Shader-Prozessoren der Volta-GPUs verteilte. **)
Entsprechenes sah man dann auch Anfang 2019, als nVidia die Verwendung der Shader-Prozessoren für Raytracing in die Pascal-Treiber rückportierte, sodass auch Pascal nun als RTX-fähige GPU genutzt werden kann, natürlich mit geringerer Leistung, aber immerhin.
Und einen ähnlichen Weg geht Crytek mit ihrer neuen Engine-Version 5.6/5.7 die u. a. ebenfalls die universell verfügbaren Shader für einige Raytracing-Effekte bemühen, wahrs. in Verbindung mit FP16-Berechnungen. (Hier wird es zweifelsfrei aber auch einen Upgrade-Pfad für eine entsprechende Hardwareunterstützung geben, so anscheinend über DX12 und ggf. auch Vulkan.)

Unterm Strich werden umfangreiche, Raytracing-basierte Berechnungen jedoch erst sinnvoll mittels dedizierter Hardware möglich sein. Das sieht man sowohl beim Vergleich Volta zu Turing in Games als auch in der aktuellen Blender-Entwicklung, die gerade als zusätzliche Alternative zu CUDA nVidia's OptiX in Verbindung mit den "RT-Cores" implementiert. Die letztgenannte Variante erreicht teilweise bis zur doppelten Performance der CUDA-Variante. Und wenn man jetzt noch den Schrei vieler leidender Gamer berücksichtigt, die ohne 4K nicht mehr leben können, kann man sich leicht ausmalen, dass Emulationen (bzw. Berechnungen über general purpose Funktionseinheiten) bestenfalls nur eine kurze Übergangslösung darstellen können.


**) In Verbindung mit der demonstrierten Star Wars Elevator Demo verteilt auf die über 20.400 Shader-Prozessoren der vier Volta-GPUs in der DGX. In Verbindung mit Turing hat man die betreffende RTX-Funktionalität herausgelöst und in den Turing-Treiber übertragen und den Stack so umgeschrieben, dass er statt der Shader-Prozessoren die hierbei leistungsfähigeren "RT-Cores" von Turing verwendet.
 
Zuletzt bearbeitet:
Ein sehr schöner Post @gerX7a

Hier auch mal, weil die Elevator Demo in diesem fiel, eine kleine Idee, was die dedizierten RT Cores inkl. DLSS hier wirklich anrichten und wie schwerwiegend diese Neuerungen sind (gibt ja immernoch Leute, die behaupten, dass die RT- Cores Fake wären):
YouTube

Wir reden hier von Faktoren an Beschleunigung durch fixed function Einheiten (wie sie übrigens von AMD inzwischen auch angekündigt wurden - AMD Patent Shines Raytraced Light on Post-Navi Plans | TechPowerUp).

LG
Zero
 
Zuletzt bearbeitet:
Auf einem Mac lief doch Radeon Ray mit einer W9000. Das Raycasting fällt kaum geringer aus.

Wow - dein PC kann Software laufen lassen..... eine SNES kanns auch.


Wir reden hier von Faktoren an Beschleunigung durch fixed function Einheiten (wie sie übrigens von AMD inzwischen auch angekündigt wurden - AMD Patent Shines Raytraced Light on Post-Navi Plans | TechPowerUp).
Aufpassen - AMD spricht hier von einer Softwareimplementierung die nur einen extra Cache als "Beschleunigung" hat - so wie zB normale Shader auch einen Textur-Cache haben.
 
Aufpassen - AMD spricht hier von einer Softwareimplementierung die nur einen extra Cache als "Beschleunigung" hat - so wie zB normale Shader auch einen Textur-Cache haben.
Es ist ein flexiblerer Hybrid. Aber:" (doing fixed function acceleration for a single node of the bounded volume hierarchy (BVH) tree)".

Das heisst, dass wir für diesen Zweck eine "harte Verschaltung" haben. Ob die im Texturprozessor liegt (was in meinen Augen aufgrund der eh schon vorhandenen Breitbandigen Anbindung und den von Dir genannten Cachestrukturen, eine effiziente Idee scheint), oder in einer dedizierten Einheit steckt, bleibt letztenendes egal... Das wirkt sich dann eher auf die Komplexität der Anbindung dieser Einheiten aus.

Essentially, AMD will be introducing what it calls a "fixed function ray intersection engine", which is specialized hardware that only handles BVH intersection (processing BVH calculations in a stream processor solely via a software solution isn't a pretty option,

Das Scheduling/Dispatching soll allerdings shadergesteuert sein, was das ganze flexibler hält und auch ein wenig in DXR 1.1 reinspielt...
Gerüchtehalber soll der Turing- Nachfolger diesbezüglich auch mehr Flexibilität besitzen.

Die Funktionsweise der fixed function BVH traversal Sache, also nebst der Erstellung der Beschleunigungsstruktur die rechenintensivste Geschichte, ist also ähnlich zum nvidia Ansatz und heisst dort ray intersection engine.

Hier das vollständige Patent:
A texture processor based ray tracing accelerator method and system are described. The system includes a shader, texture processor (TP) and cache, which are interconnected. The TP includes a texture address unit (TA), a texture cache processor (TCP), a filter pipeline unit and a ray intersection engine. The shader sends a texture instruction which contains ray data and a pointer to a bounded volume hierarchy (BVH) node to the TA. The TCP uses an address provided by the TA to fetch BVH node data from the cache. The ray intersection engine performs ray-BVH node type intersection testing using the ray data and the BVH node data. The intersection testing results and indications for BVH traversal are returned to the shader via a texture data return path. The shader reviews the intersection results and the indications to decide how to traverse to the next BVH node.
LG
Zero
 
Zuletzt bearbeitet:
Es ist ein flexiblerer Hybrid. Aber:" (doing fixed function acceleration for a single node of the bounded volume hierarchy (BVH) tree)".
Wenn man das ganze durchliest merkt man das zu keiner Zeit eine Hardwarebeschleunigung der Berechnung (der schwere teil) erwähnt wird - nur eine beschleunigung durch einen Cache.

Das Scheduling/Dispatching soll allerdings shadergesteuert sein, was das ganze flexibler hält und auch ein wenig in DXR 1.1 reinspielt...
Gerüchtehalber soll der Turing- Nachfolger diesbezüglich auch mehr Flexibilität besitzen.
Der Dispatch ist von DXR seiten bereits so vorgegeben und genau so auch bei RTX. Mehr flexibilität als bereits frei programmierbar geht nicht.
 
Wenn man das ganze durchliest merkt man das zu keiner Zeit eine Hardwarebeschleunigung der Berechnung (der schwere teil) erwähnt wird - nur eine beschleunigung durch einen Cache.

The TP includes a texture address unit (TA), a texture cache processor (TCP), a filter pipeline unit and a ray intersection engine.
Im Patent ist die ray intersection engine als eigener Block im Texturprozessor abgebildet- Somit fest verdrahtet/fixed function.

Der Dispatch ist von DXR seiten bereits so vorgegeben und genau so auch bei RTX. Mehr flexibilität als bereits frei programmierbar geht nicht.


Inline raytracing gives developers the option to drive more of the raytracing process. As opposed to handing work scheduling entirely to the system. This could be useful for many reasons:...
DispatchRays() calls via ExecuteIndirect()
This enables shaders on the GPU to generate a list of DispatchRays() calls, including their individual parameters like thread counts, shader table settings and other root parameter settings. The list can then execute without an intervening round-trip back to the CPU.

This could help with adaptive raytracing scenarios like shader-based culling / sorting / classification / refinement. Basically, scenarios that prepare raytracing work on the GPU and then immediately spawn it.
Damit Du weisst, worauf ich hinaus will...

LG
Zero
 
Im Patent ist die ray intersection engine als eigener Block im Texturprozessor abgebildet- Somit fest verdrahtet/fixed function.
AMD bezeichnet auch die Shader als Engine - also nicht fix verdrahtet.


Damit Du weisst, worauf ich hinaus will...
Es ist in keiner weiße flexibler als bereits voll flexibel. Ist so als würde man sagen ein Zeppelin lässt sich flexibler steuern als ein Luftschiff.
 
AMD bezeichnet auch die Shader als Engine - also nicht fix verdrahtet.
Auch die Shader sind fest verdrahtet.

Es ist in keiner weiße flexibler als bereits voll flexibel. Ist so als würde man sagen ein Zeppelin lässt sich flexibler steuern als ein Luftschiff.
Es heisst z.B. um bei der Analogie zu bleiben, dass ich, wo vorher die Voraussetzung für eine grünen Ampel zur Vorbereitung des Start eines Luftschiffs gegeben war, nachdem eine gewisse abfolge von Checks stattgefunden hat, man nun die Vorbereitung unter gewissen Szenarien parallel zu den Checks stattfinden lassen kann.

Das kann z.B. künftig im Zusammenspiel mit Mesh Shadern eine beschleunigende Rolle spielen.

LG
Zero
 
Auch die Shader sind fest verdrahtet.
..................................................... dann wäre jeder Software-algorithmus hardware-beschleunigt und die nomenklatur wertlos ...............................


Es heisst z.B. um bei der Analogie zu bleiben, dass ich, wo vorher die Voraussetzung für eine grünen Ampel zur Vorbereitung des Start eines Luftschiffs gegeben war, nachdem eine gewisse abfolge von Checks stattgefunden hat, man nun die Vorbereitung unter gewissen Szenarien parallel zu den Checks stattfinden lassen kann.
Es ist aber einfach in KEINSTER WEISE anders als es mit DXR bereits ist. es ändert sich 0, Nüsse, Nada.
 
Es ist aber einfach in KEINSTER WEISE anders als es mit DXR bereits ist. es ändert sich 0, Nüsse, Nada.
Du kannst die tracing Funktionen z.B. auch aus compute shadern ansprechen.

Jeder Software Algorithmus, der durch eine gesonderte Schaltung beschleunigt wird ist fixed- function hardwarebeschleunigt. Schreibt AMD ja selbst, das die Beschleunigung fixed function ist.
AMD will be using both existing shading units and "fixed function" hardware while saying "flexibility is preserved" for developers.

Spezialisierte, dedizierte Einheiten sind nunmal dafür da, die Dinge schneller abzuhandeln, die eben die 08/15 Einheiten nicht so schnell abarbeiten können.
Oder wie würdest Du die spezialisierten Einheiten, die auf dem Chip sitzen um EINE Funktion zu beschleunigen denn sonst nennen?

Sind universelle Rechenwerke schnell genug, kann sich der fixed- function Ansatz auch wieder auflösen. Siehe Verschmelzung der dedizierten pixel und vertex Einheiten zu Universalshadern.
Und ja- Grundsätzlich liesse sich alles über Software emulieren. Mit einhergehenden Geschwindigkeitsnachteilen.

Die Frage, die sich aber generell stellt ist nur, ob die Art und Weise wie Big Navi RT abwickeln wird dem Patent entspricht.

Sorry casurin- Irgendwas versuchst Du mir zu sagen, was ich wohl nicht richtig auf die Kette kriege... Hmmm...
Irgendwo liegt ein Missverständniss vor...

LG
Zero
 
Zuletzt bearbeitet:
Auch die Shader sind fest verdrahtet.
Und was soll das damit zu tun haben, dass es ab dx8 und frei programmierbarer Pipelines, die mittlerweile sogar parallel ausgeführt werden können, es keine fixed functionen mehr in Hardware gibt? TnL wurde ab dx8 hinfällig. Natürlich musst du einen Teil der Shader Vertex- oder Pixelshaderfunktionen zuordnen. Selbst Cuda erlaubt ein frei programmierbares Modell, nur macht der Großteil der Entwickler davon keinen Gebrauch, weil Nv einen anderen Ansatz verfolgt und zwar mit Gameworks. Sogar Raytracing Funktionen lassen sich völlig fixed functionsless auf der Computepipeline ausführen. Da die Berechnungsdurchläufe abhängig von der Genauigkeit der benötigten Ergebnisse mehrfach stattfinden müssen, bleiben die Einheiten solange der Funktion zugeordnet. In einer Rasterpipeline zun Beispiel muss ein Teil der Shader dem Parametisierungsprozess zugeordnet bleiben. Die Shader können dabei mehrere Stufen transformieren. Die dazugehörigen Leseregister bleiben bis zur Generierung der Rechenergebnisse auch in der Echtzeitshaderprommierung, als Art feste Funktionspipeline dem Prozess zugeordnet. Das Transforming, die Vertex-und Pixelshader sind jedoch frei programmierbare Einheiten. Das ist unter opengl und dx so, seit Jahren. Selbst Cuda bietet dazu eine flexible Steuerung an. Die Einheiten werden seit geraumer Zeit in Hardware auftragsunabhängig ausgeführt und können verschiedene Rechenaufgaben parallel ausführen. Lediglich die Dreiecksrasterizierung bleibt ein fixed function Renderingalgorithmus.

Tue also nicht so als wüsstest du darüber irgendetwas wesentliches. Die benötigten Referenzen lassen sich in der Pipeline, den frei programmierbaren Einheiten zuordnen. Die API liefert dazu Befehlsfunktionen. Die Schnittstellenfunktionen werden durch herstellereigene Tools unterstützt. Feste Funktionen gibt es seit dx7 nicht mehr.

Was soll das mit dem Bounding zu tun haben, oder irgendeiner Verdrahtung?
 
Zuletzt bearbeitet von einem Moderator:
Und was soll das ...
wall of text... Was soll das mit dem Bounding zu tun haben, oder irgendeiner Verdrahtung?
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)?

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...

Und lt. Dir gibt es keine fixed function Einheiten mehr in Hardware?
Ich geh mal davon aus, dass Du Dich verschrieben hast, oder den generalisierenden Charakter Deiner Aussage beim Schreiben nicht im Kopf hattest.
 
Zuletzt bearbeitet:
Zurück