foo_1337 schrieb:
Hier wird dir das ganze so abstrahiert, dass der (in diesem fall) drm entwickler hier keinen Unterschied sieht.
Ja, Frage ist in wie weit MS hier die Möglichkeit schon bietet, oder ob AMD ggf. sogar - sie kennen ja ihre AMD-Vi als Erweiterung sehr gut, sogar optimierten Code nutzt ggf. sogar auf neue Möglichkeiten in Zen3 zugeschnitten hat, da muss man schauen!
Ich weiß nur, dass ich in den Beiträgen bei Kernel.org durchaus noch sah, dass es durchaus auch Sachen gibt, die man bei Intel als auch AMD beachten muss. Mal weiter suchen.
KlaraElfer schrieb:
Ist das nicht Nvidias gutes Recht, wenn sie DLSS nur auf Turing gewährleisten/sicherstellen wollen/können?
Dein Beitrag ist lang, aber misst mit zweierlei Maß und erklärt AMD zur guten Firma und Nvidia zur bösen Firma, lächerlich.
Nein, man misst hier nicht mit zweierlei Maß, um das zu verstehen, muss man aber etwas mehr auf dem Kasten haben und sich auch mal mit den Grundlagen beschäftigen.
Zudem schadet es nicht, wenn man weiß, was Treiber-Funktionen sind, was Hardware-Funktionen sind, wozu man einen Treiber braucht und was dieser macht, was dadurch, weil man es im Treiber implementiert, kein Nachteil für uns als Nutzer ist und erst recht keine künstliche Benachteiligung der Konkurrenz darstellt.
SAM baut auf WDDMv2 und WDDMv2.7 auf und dort der Möglichkeit BAR und ist damit eine Treiberfunktion, die zudem unabhängig von Optimierungen der Spieleentwickler genutzt werden kann. NVIDIA wird hier nicht benachteiligt, denn denen steht es frei eine ähnliche Funktion in ihren Treiber zu implementieren. NVIDIA wird hier auch nicht ausgeschlossen, denn alles, was SAM nutzt, ist frei zugänglich.
AMD nutzt hier die Möglichkeiten von PCIe, CPU, GPU und dem OS, es gibt hier keine künstlichen Schranken, die NVIDIA daran hindern eine entsprechende Treiber-Funktion zu implementieren.
SAM => Nutzt die Funktionen der eigenen CPU sowie der GPU aus und stellt daher eine Funktion zur Verfügung, die die Leistung erhöhen kann. Stark vereinfacht: SAM ist eine Optimierung.
DLSS => Stellt ein Stück Software da, die bereits sogar nachgewiesen, auf den Shadern laufen kann, die man per DirectML sowie Vulkan ML implementieren kann. Die Software schließt jedoch von Anfang an alle anderen aus.
Wenn du hier den Unterschied nicht erkennst, und es weiter auf die gleiche Stufe stellen willst, dann ist mein Eindruck von dir, dass du nur ein trollender Fanboy bist, dessen Beiträge maximal den Nährwert des Hamburgers bei McDonalds haben, voll bestätigt.
matty2580 schrieb:
Bei Nvidia wird man das in dieser Form nicht nutzen können.
Ja und? SAM ist eine Funktion des Treibers, soll jetzt AMD anfangen auch für NVIDIA einen Treiber zu entwickeln? Oder soll NVIDIA jetzt ihren Memory-Controller der GPUs AMD zur Verfügung stellen?
Oder soll NVIDIA jetzt RTX IO auch für AMD öffnen? RTX IO baut auf DirectStorage auf, ich seh da keinen Grund warum NVIDIA das für AMD öffnen sollte. Genau so sehe ich kein Grund warum NVIDIA jetzt ihre Treiberfunktionen für AMD öffnen sollte.
SAM baut auf WDDMv2 und WDDMv2.7 auf, nutzt deren Möglichkeiten dem VRAM zu optimieren, NVIDIA steht es frei eine entsprechende Funktion in ihren Treiber zu implementieren, damit der Treiber auch entsprechend den VRAM optimieren kann.
matty2580 schrieb:
Oder man entwickelt eine eigene Technik ähnlich wie SAM.
Da es eine Treiberfunktion (nach jetzigem Stand) ist, wird NVIDIA ohnehin genau das machen müssen.
Die einzigen, die hier mit zweierlei Maß messen, das seid ihr, weil ihr nun fordert, dass AMD für NVIDIA eine Treiberfunktion öffnet, obwohl alle Bestandteile dafür bereits offen sind.
AMD hat ein eigenen Memory Controller für ihren GPUs entwickelt mit seinen Eigenheiten. NVIDIA hat einen eigenen Memory Controller, alle Techniken sind für NVIDIA frei zugänglich, dass sie eine SAM ähnliche Funktion in ihren Treiber implementieren können. Zumal wir aktuell nicht mal genau wissen, ob AMD für SAM nicht noch die ISA »GCN« für RDNA2 anpassen musste, damit die GPU ggf. entsprechende Befehle verarbeiten kann. Sollte es sogar so sein, dass die ISA um entsprechende Befehle erweitert wurde, dann handelt es sich um eine Hardware + Treiberfunktion.
Und genau das ist hier der Unterschied: Es handelt sich hier um eine Treiberfunktion, die ggf. sogar Hardware-Anpassungen benötigt. Keiner hier verlang von NVIDIA, dass sie ihre »RT-Cores« AMD zu Verfügung stellen, keiner verlangt hier, dass NVIDIA ihre Tensore-Cores AMD zur Verfügung stellt. Keiner verlangt hier, dass NVIDIA CUDA als API für AMD öffnet. Und genau so erwarte ich nicht von AMD, dass sie ihr SAM NVIDIA geben oder für NVIDIA öffnen.
Die Grundlagen für SAM - WDDMv2 sowie WDDMv2.7 - sind für NVIDIA zugänglich, sie können also eine eigene Treiberfunktion entwickeln, damit ihr Treiber den VRAM optimieren kann.
Den Beitrag von Leo von 3d-center.org kann ich zudem an der Stelle nicht ganz ernst nehmen, zeig dieser Beitrag doch eindeutig, dass man da zwar mal wieder viel schreibt, aber so überhaupt kein Interesse vorhanden war sich mit den Grundlagen zu befassen. Auch hier wieder: Der Herr sollte mal sich in einige Entwickler-Foren von Linux schlaumachen, bevor er hier ein Urteil ablässt. AMD nutzt hier das, was man in Linux BAR nennt. BAR baut auf AMD-Vi sowie Intel VT-d auf. Beides sind proprietäre Erweiterungen, die die gleichen Möglichkeiten bieten, aber doch unterschiedliche Befehle mit ihren Eigenheiten haben. Bei BAR in Linux gibt es dafür eine recht einheitliche API mit von Intel als auch AMD gepflegten »Treibern«. Zumal Intel bereits genau das gemacht hat, was er nun bei AMD verurteilt. Intel Xeon + Intel Xeon Phi. Der »BAR«-Support dort funktioniert auch nur, wenn man Xeon Phi mit einem Xeon nutzt, nutzt man Xeon Phi + Epyc, geht es nicht - ja man kann es durch »Work-a-rounds« hinbiegen.
Die einzige Firma, die man hier als »Opfer« sehen kann, ist Intel, da diese wegen den gleichen Hardwaremöglichkeiten bei ihren Prozessoren ausgeschlossen werden von der Nutzung von SAM. Aber hier kann man dann auch die Argumentation von so einigen Fanboys hier gegen sie wenden:
AMD-VI ist nicht Intel Vt-d. Beide Extensions haben ihre eigenen Befehle und man kann von AMD nicht erwarten, dass sie ihre Bibliotheken für Intel optimieren, denn beide Extensions sind wirklich »unterschiedlich«.*
*Natürlich gilt das jetzt erst mal unter Vorbehalt. Sollte AMD hier »künstlich« Intel ausschließen, weil man wirklich nur Windows Board-Mittel nutzt, dann ist das für mich alles andere als ein feiner Zug und genauso unnötig, wie in den Intel-Bibliotheken die Tatsache, dass man da AVX-1 und AVX-2-Codes nur auf Intel CPUs ausführt.
Wenn ihr hier schon mit »zweierlei« Maß messen anbringen wollt, dann würde ich euch eher mal empfehlen mit den Grundlagen anzufangen und worin der Unterschied zwischen »Effekten«, Treiber-Funktionen sowie Optimierungen besteht und warum es eben etwas anderes ist bei einem »Effekt« jemanden künstlich auszuschließen, obwohl man es mit den Verfügbaren APIs umsetzten könnte, und einer Funktion im Treiber, die es ermöglicht den Datenfluss zu optimieren.
- und die 6800XT sieht schon mal sehr nett aus
