Kann man sich mit dem Thema nicht tiefergreifend beschäftigen, bevor man anfängt Nvidia als Referenz hinzustellen?
Die Referenz bildet die API, in diesem Fall DXR, an der AMD mitgewirkt hat.
Kein Grund hier was in Richtung NVIDIA und proprietär drängen zu wollen, wie es all diejenigen tun, die sich mit dem Thema nur oberflächlich beschäftigen oder einen gewissen BIAS an den Tag legen.
Es gibt keine Vorgaben wie das BVH beschleunigt wird und ja genau das stimmt, die Entwickler setzen bisher einheitlich auf eine Beschleunigung die RTX passt und genau deshalb sieht man Unterschiede.
Es gibt noch nicht mal eine Vorgabe, wie die AC darunter aussehen muss.
Es ist wie immer, Nvidia gibt einen Schei** auf gemeinsame Standards.
Nebst dem, dass das völlig daneben liegt, weil die Hersteller von Standards profitieren, könnte man leider den Eindruck erhalten, dass Du letztendlich genau dem unterliegst, was Du den anderen vorwirfst.
NVIDIA unterstützt DXR und die Vulkan RT extensions. Hat zu beiden APIs maßgeblich beigetragen und das zu einer Zeit, als bei AMD RT- Beschleunigung für die eigenen Karten noch kein Thema war.
So hatte AMD hier alle Zeit der Welt, sich die vorhandenen Gegebenheiten anzusehen, hat auch noch auf fertige Beispiele (AAA- Games) für kommende DXR Integrationen als Vorlage zugriff gehabt (sogar das open- source Quake 2 von NVIDIA, welches viele Technologien offengelegt hat) und war offenbar bis jetzt nicht fähig, ihre Treiber erstens vollständig kompatibel und zweitens die Hardware gemäß dieser Anforderungen, die nicht immer nur in inline- RT bestehen kann und wird, entsprechend performant zu gestalten.
Hier den Bock zum Gärtner zu machen zeugt von einer erheblich voreingenommenen Sichtweise.
Wer zuletzt kommt, mahlt zuletzt.
Wenn wir die ersten Portierungen für die neuen Konsolen sehen, dann bin ich gespannt wie ihr den Artikel hier aktualisiert
AMD arbeitet nach dem Motto: Best raytracing usage is, when u don´t have to use it. Und selbst mit inline- raytracing gewinnt AMD trotz fast- path Nutzung dort keinen Pokal.
Nochmal:
Sie liegen eine Generation zurück, haben kein DLSS- Derivat und haben obwohl Ihnen die sich bereits am Markt befindliche Software bekannt war und sich deren DXR Aufrufe ansehen hätten und in depth profilen hätten können, nicht in der Lage erstens bis jetzt mit ihren Treibern keine volle Kompatibilität herzustellen und zweitens ihre Karten auf ein entsprechendes Anforderungsprofil abzustimmen.
Aber das ist ja sowieso eine alte Krankheit bei denen, dass sie trotz guter Technik auch schonmal gerne am bestehenden Markt vorbeientwickeln.
Dahinter könnte man auch eine perfide Strategie vermuten, nämlich dass man durch den Vorteil der Nähe zu den Konsolen (die von Dir angesprochenen Ports für PCs) seine Vorstellung der Integration von Raytracing in den Markt zwingen will.
Im Augenblick arbeitet AMD also AUGENSCHEINLICH eher auf genau das hin, was Du NVIDIA hier vorwirfst und wil hier mit der Marktmacht der Konsolen dahinter den eigenen Stiefel durchdrücken.
. Zu vermuten ist das Nvidia dann ziemlich alt aussieht und jedes Spiel per Treiber scripten muss.
Dann vermute mal.
Auf welche technischen Grundlagen stützt sich denn Deine Vermutung?
Wieviele gewerksunabhängige dedizierte Einheiten, die auch noch concurrent am VRAM nuckeln hat denn AMD?
Wie siehts denn mit async und concurrent in den TMUs aus, wenn Du nicht auf einen uber- shader setzt, auf den hier AMD solch exklusives Vertrauen setzt, was den Spieleentwicklern wie uns wieder Flexibilität nimmt und einen Weg vorgibt bzw. uns zwingt wieder zwei Versionen des ganzen Shader- bzw. Renderpaths zu pflegen.
Sorry- Dafür hab ich kein Verständnis, denn das wozu man hier wieder gezwungen wird, wäre wieder ein Rückschritt.
Manchmal MÖCHTE ich als Entwickler aus einer Shaderbatterie rays verschießen und nicht einen uber- shader für alles anstoßen. Das ist erstens performancetechnisch alles andere als immer ein Vorteil und zweitens verkompliziert es die Shaderprogrammierung.
Es ist nicht immer toll, alles auf inline- Raytracing zu zwingen, was ich aber müsste, dass AMD ordentlich Traktion erhält.
Ist das einleuchtend?
Ich bin mal gespannt wie lange sie das RTX Pferd noch satteln.
So lange AMD das RX Pferd sattelt? Da es der Name einer Plattform bzw. einer Kartengeneration ist, die RTRT beherrscht unter Umständen bis zum Ende der Welt. Die dedizierten RTX- Extensions oder Frameworks, falls Du Dich darauf beziehst, sind dem professionellen Bereich vorenthalten und haben mit Spieleentwicklung nichts am Hut.
Da war NVIDIA von Anfang an durch DXR und jetzt Vulkan komplett standardisiert.
Der Pfad sieht für alle Firmen so aus: Eigene Software - DX12/R/Vulkan/RT - Herstellertreiber - Hardware
Das einzige, was hier immer proprietär ist, ist die Kette ab Herstellertreiber.
Und nein die Shader sind überhaupt nicht für Nvidia geschrieben. Was für ein Quatsch. Die Shaderintegration beruht jeweils auf einem Sprachmodell und wird im individuellen Fall für die jeweilige Hardware übersetzt, da wird nichts expliziet für Nvidia geschrieben sondern z.B. über die Sprache in der Assetpipeline.
Check
Das in der Engine implementierte Sprachmodell muss von der Fexlibilität her, nicht jeder Hardware liegen. Insgesamt kann abrufbare Leistung aber von ganz anderen Faktoren abhängen, dem Szenenmanager, dem Terrainrenderer, Mapping, Decals, Particel, Illumination usw.. Es wird unter DXR nicht auf Nvidia optimiert, daher hat das mit Shadern abolut nichts zu tun.
Check. Und das ist genau DER springende Punkt. Hinter DXR sind alle Hersteller "gleich". Entweder sie können die Befehle in ihrer Hardware-/Treiberkombi gut und schnell umsetzen oder eben nicht.
Das liegt allein in der Verantwortung des Herstellers der Grafikkarten.
Es wird eher am Scriptcompiler liegen und nicht dem Shader. Dabei greifen C++ kompatible direkt auf Windows API Funktionen zu, wobei Nvidia dort oft ihr eigenes Ding mit Cuda machen und mit Treibern diese umgehen.
Es gibt unterschiedliche Wege, die man da gehen kann, wobei NVIDIA Cuda im professionellen Bereich einsetzt, weil sie da die schnelle und umfangreiche Bibliotheken bieten können. Das hat nichts mit Spielen zu tun.
und... ein Shader- Compiler ist auch nur ein Stück Software, das z.B. HLSL in dxil umsetzt.
Abschließend - Die Nummer hier NVIDIA irgendwie einen schwarzen Peter von wegen "proprietär" etc. zuschieben zu wollen ist in Sachen RTRT geradezu abenteuerlich.
Die haben so viel geforscht und so viele ihrer Ergebnisse öffentlich und open- source gestellt (auch einen DLSS Ansatz ohne Deep- Learning- Komponente). Das DLSS AI Modell wurde an Microsoft für eine Direct ML Implementation zur Verfügung gestellt. Sie halten sich vorbildlich an die Standards (kann jeder der ein Capture der DXR Befehle macht, die an die Karten gehen überprüfen). Keine Sonderlocken, nichts.
Sie haben sich den Ärger und den Zorn der User aufgehalst durch die ersten schweren Schritte, die man mit RTRT gegangen ist.
AMD setzt sich jetzt ins gemachte Nest (haben sie leider bis jetzt nicht richtig hinbekommen), profitiert von der Vororabeit und hätte die Technik nur noch adaptieren müssen.
Sorry- Es ist DEREN Problem, wenn sies nicht hinbekommen, dass das standardisierte Zeug auf ihren Karten richtig läuft. Sie schreiben ja selbst dazu, dass ihre Treiber noch nicht so weit sind.
Erneut wird hier eine Beta an den Usern getestet. Hat man NVIDIA bei Turing nicht noch dafür gekreuzigt?
Wieso passiert das bei AMD nicht? Wieso nimmt man die plötzlich in Schutz und pocht auf "Speziallösungen" und schiebt die Verwantwortung für deren RTRT- Leistung (die ich im Übrigen garnichtmal für so schwach erachte, wie es einige tun), in Richtung Entwickler/NVIDIA?
Immerhin liegt sie in Version 1 schon leicht über dem Level der 2080TI. Das ist doch eine ordentliche Leistung.
Nur weil NVIDIA in dieser Generation die RTRT Leistung deutlich ausgebaut hat, muss doch das andere nicht plötzlich schlecht sein?
.gif "sm_B-) :-)")
.
. Läuft halt dann im Raster Mod.
.
