News FidelityFX Super Resolution: DLSS-Konkurrenz ab 22. Juni für AMD- und Nvidia-GPUs

ThePlayer schrieb:
Aber wie sind da die Stückzahlen zum gesamten Markt? Bestimmt sehr gering.
Es sind laut unbestätigten info‘s ein paar tausend für Europa. Wären es extrem mehr würde der Preis überall fallen. Hier ist einfach nicht genug Material da. Aber es schaffen immer welche sich dort eine zu ergattern. Einer der bekanntesten threads ist in Hardwareluxx https://www.hardwareluxx.de/communi...platz-keine-skript-oder-bot-anfragen.1281486/

Anbei gibt es in dem Forum auch Verfügbarkeits thread für Nvidia/AMD Karten der über ein bot die bekanntesten Seite nachprüft und pushnachrichten in einen discordchannel oder Telegramm Channel sendet https://www.hardwareluxx.de/community/forums/verfügbarkeitshinweise.338/

sry fürs OT!!
 
  • Gefällt mir
Reaktionen: foo_1337 und ThePlayer
foo_1337 schrieb:
Die Verkaufspreise werden von den Händlern/Distributoren gemacht. Da verdient weder nvidia noch AMD nur einen Cent mehr.
Und AMD wird die Preise nicht nur theoretisch erhöht haben.
Das ist Unfug, der Verkäufer kann seine Preise als erstes und am schnellsten anpassen.

Aber die Lieferketten werden bis hin zum Auftraggeber AMD/Nvidia selbstverständlich nach den Gegebenheiten anpassen. Das gehört zum Markt anders klappt das nicht.
 
Yippie, meine Übergangs RX 470 kann es nutzen.

Dann wird die Wartezeit auf erträglichere GPU-Preise etwas erträglicher.
 
ThePlayer schrieb:
Aber wie sind da die Stückzahlen zum gesamten Markt? Bestimmt sehr gering.

Also in einer Discordgruppe haben vorgestern 24 Leute angegeben eine AMD Karte bekommen zu haben und der Bot hat eigentlich wie immer pünktlich um ca. 17.30 Uhr Verfügbarkeit gemeldet. + Jeder dort hat damit gerechnet, dass AMD jeden Moment dropt.

Bei NBB waren es gestern ab 14 Uhr (3090, 3080, 3080 Ti, 3060 Ti) ca. 90x erfolgreiche Kaufmeldungen - Mehrfachbestellungen nicht eingerechnet. Dafür gab es für die Gruppe am Releasetag der 3080 Ti kaum Chancen, da ja überall bekannt war, wann es die geben wird. Nur 16 User von über 300.

Die Mengen sind vergleichsweise sehr gering. Aber es gibt ja weltweit solche Privat/Händler/Scalper-Gruppen sei es auf Twitter oder in Foren wie Hardwareluxx.
 
Zuletzt bearbeitet:
Teralios schrieb:
Der "neuronale"-Teil des Algorithmus läuft auf den Tensore-Cores, es gibt aber auch Teile, die normal auf den Shadern ablaufen.
Exakt- Ähnlich wie bei den RT Cores läuft der Dispatch und die anschließende Verarbeitung (wie die Gridanordnung) wieder auf den Shadern.

Auch wenn NVIDIA ja betont, dass RT-Kerne, Shader, TC usw. alle ja gleichzeitig laufen können: Das tuen sie aber nicht!
Das klassische Auslastungs- bzw. Flaschenhalsproblem, mit welchen man auf jeder massiv parallel arbeitenden Maschine zu tun hat. Du kommst halt zwischenzeitlich doch immer wieder an den Punkt, wo du "syncen" musst.

Aber - Und das habe ich schon getestet. Du kannst alle Einheiten triggern (auch async), so dass sie gleichzeitig arbeiten und Ergebnisse liefern. Dass es immer wieder zu Abhängigkeiten und "interrupts" kommt, liegt in der Natur der Grafikpipelines, die immernoch stark seriell ablaufen.

Ich hab mir jetzt genug Diagramme zur Verteilung der Rechenleistung auf Ampere-Karten und auch die Karten davor angesehen, auch mit DLSS1.0, DLSS2.0 und 2.1 und wann welche Rechenwerke wie aktiv sind im Frame und oh wunder: Sind die RT-Cores am arbeiten, bricht INT+FP - also die Shader - stark ein
Geh mal in den NSIGHT und wirf einen Blick auf die Kommunikationspipelines/Bandbreiten. Da wird dann langsam klar, warum in den Karten die Kommunikationswege und Bandbreiten massiv aufgewertet wurden.

und werden nicht stark beansprucht und zum Ende hin, wenn DLSS ausgeführt wird, haben weder RT-Cores noch die Shader viel zutun, sondern die Hauptlast liegt auf den TCs.
Exakt - Ist halt wieder das Problem, dass DLSS seine Heuristik mit endgültigen Farbwerten durchführen muss.

Die AI ist ja in Sachen DLSS 2.0 letztendlich ein extrem schneller Memory und Puzzle- Spieler:
Ups- Da ist ein Pixel. Wo war der vorher, wie ist der bis jetzt "gewandert" wie ist die Rotation von Geometrie in Abhängigkeit der Projektionsmatrix im Bild (motion vectors) und welche anderen Geometriebereiche drohen im Z-Buffer dafür zu sorgen, dass das Pixel im Zielframe verdeckt ist und somit verworfen werden muss (parralax effekt). Nebst dem variablen clamping (ich deck einfach gleich ein par memory Karten auf, um meine Chancen zu erhöhen, aber auch Fehlgriffe zu verifizieren und Ghosting zu minimieren und mixe im Sinne von Supersampling noch meine neu abgetasteten Pixel hinzu). Da sind eben nicht nur Matrizen involviert.

Achtung- Das ist vereinfacht dargestellt.

In control kannst Du DLSS2.x übrigens rudimentär beim Arbeiten zusehen, indem Du in den INI- Files die interne DLSS Renderauflösung der Originalauflösung annäherst:
1622881682187.png



Und bei DLSS kann man sagen, dass ca. 80 % auf den TCs laufen, 20 % auf den Shadern als INT-Operatonen, weil das Bild ja auch skaliert werden muss.
Da würde ich PI mal Daumen konform gehen.

Also, dass die Radeons "nur" Shader haben, ist da kein Problem, weil die Aufgaben ohnehin nach einander ablaufen.
Grundsätzlich wäre das so. Was man dabei aber nicht vergessen darf, sind die Bearbeitungszeiten der Units.
Selbst wenn wir annehmen würden, dass alles streng seriell ablaufen sollte, so ist das Zeitbudget für die Berechnung auf den tensor cores ein Vielfaches unter der Berechnung auf den Shadern.

Letztendlich wiederholen wir die Geschichte der fixed- functions Spezialisierung (ähnlich der alten Vertex- und Pixeleinheiten), die dann meines Erachtens irgendwann später wieder zu einer optimierten multi- purpose Einheit verwachsen.

Und warum? DLSS 1.0 hat auch, sagen wir mal, eher durchwachsene Ergebnisse geliefert und wurde erst mit 2.0 wirklich gut.
Ja- Letztendlich hat man dafür das ursprüngliche DLSS in die Tonne getreten und ein komplett neues generiert.
Das alte DLSS war ja eher das, was hier viele mit der klassischen künstilichen Intelligenz in Sachen Bildanalyse und Annäherung an die ground truth assoziieren.

Für den ersten Wurf, sieht FXSR nicht mal SO schlecht aus, wobei man da auch eher mal auf die Spiele warte muss um dann zu sehen, was kommt.
Ich war enttäuscht, weil ich mir insgeheim gewünscht hätte, dass sie mehr "hervorzaubern" würden, als altbekannte Verfahren. Aber- Da ist das letzte Wort noch nicht gesprochen.
Mal sehen, was im Release dann zum Vorschein kommt.
Ich zumindest kann es trotz der gedämpften Erwartungen nicht erwarten, das mal testweise einzubauen.

DLSS hat in Version 1.0 sehr viel "Training" für das Spiel gebraucht und Version 2.0 ist ausgereifter und genereller, ist aber durchaus auch noch sehr aufwendig zu implementieren und auch Version 2.1 ist da nicht unbedingt "besser" und muss teilweise auch entsprechend aufwendig implementiert werden.
Bei 2.x fällt der Trainingsaufwand weg. Zudem erhältst Du von NVIDIA eine proxy- bibliothek, die Du letztendlich mit einer funktionierenden TAA Integration zu 90% schon füttern kannst.
Ich persönlich sehe da im Augenblick auf Entwicklerseite einen kaum höheren Aufwand. Da war nvidia die letzten Monate extrem rührig. Vielleicht auch wegen des drohenden FSR Gewitters ;)

Im Endeffekt wird man jetzt mal abwarten müssen, was AMD macht und ob sie FXSR nun mit der Zeit auch weiter verbessern.
Ich hoffe zumindest darauf, dass sie in irgendeiner Form (sei es Implementationsvereinfachend) oder technisch (effektivere kombination von Filtern (KI oder nicht KI gestützt) Impulse liefern, die das Thema in der Gesamtheit etwas nach vorne bringen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: xBitwinSDKx, Klever, Tanzmusikus und 4 andere
Nolag schrieb:
Es hat niemand behauptet, dass AMD keine ML Cores entwickeln könnte. Nvidia hatte nur die Weitsicht früh darauf zu setzen und hat mit DLSS eine sinnvolle Anwendung dafür gefunden. AMD wird sicher nachziehen.
Es wird ja hier auch nur die aktuelle Situation bewertet. Es hat auch niemand behauptet, dass das langfristig so bleiben wird.
Leider liest sich das aber in den GPU und CPU Threads aber immer wieder so. AMD kann nichts und alles ist Schrott. Und man sollte gleich bei Nvidia und Intel bleiben. Um so Stillstand und teuere Hardware zu fördern.
Ja ich finde es auch blöd das FSR im ersten Moment nicht an DLSS2.1 heran kommt. Aber AMD ist über 1 Jahr hinten dran ehr zwei. Und das R&D Budget von Nvidia entspricht sicherlich einem vielfachen von AMD. Und da finde ich es bemerkenswert wie AMD mithalten kann. Und vielleicht sollten hier einige Leute von ihren hohen Ross Mal runter und es honorieren. Und nicht nur mit Kommentaren ala "Da muss jetzt Nvidia aber mit den Preisen runter. Da wird dann meine nächste Nvidia Karte günstiger!" Denn wenn keiner AMD kauft sind sie wieder raus aus dem Markt und eine 4080 oder 5080 kostet dann locker 1500 Euro ohne Mining Boom und Chip Knappheit.
Ergänzung ()

Taxxor schrieb:
amd.com, wo du immer noch die 6800XT für ~630€ kaufen kannst(ist seit release kontinuierlich von 649 runter gegangen), wenn mal wieder welche reinkommen, widerspricht dir da ^^
Ich meine die GPU Preise für die Hersteller der Karten. Die bezahlen jetzt sicherlich mehr als vor 3-6 Monaten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Slayn
ZeroStrat schrieb:
Wusste ich noch gar nicht. Böse Wissenslücke... ^^
Kannst dir ja mal im CDNA-Whitepaper die Seiten 5-6 durchlesen. Es ist bisher kaum bekannt, dass AMD so etwas bietet und ich kann mir das nur dadurch erklären, dass sie das nicht sauber kommuniziert haben. Wenn man sich den CB-Artikel anschaut, der zur Hälfte von Nvidia spricht, gibt es nur diese Erklärung.

@.Sentinel. Das war ein super interessanter Beitrag. Danke dir.
 
  • Gefällt mir
Reaktionen: .Sentinel., foo_1337 und ZeroStrat
ThePlayer schrieb:
Ich meine die GPU Preise für die Hersteller der Karten. Die bezahlen jetzt sicherlich mehr als vor 3-6 Monaten.
Das hätte man mitbekommen, so viel wie sich zu Release von den AIBs von Nvidia z.B. über deren geringe Marge aufgeregt wurde
 
  • Gefällt mir
Reaktionen: foo_1337
DLSS taucht doch vor allem dann auf, wenn Nvidia etwas pusht(finanziell, rein aus Marketinggründen).
Aber wenn Entwickler von sich aus entscheiden, FSR lohnt sich, da Konsolen, Radeons und Nvidia-GPUs(vielleicht sogar Pascals) es nutzen können, wäre das ne ganz andere Hausnummer.


Bin dahingehend echt mal auf die unabhängigen Tests von CB hier gespannt.

Falls FSR gute Ergebnisse liefert und neben den AMD GPUs auch auf Konsolen und auch auf Nvidia GPUs, wie Pascal läuft, dann könnte mir DLSS ehrlich gesagt gestohlen bleiben.
Ich brauch das nicht unbedingt.

In der Vergangenheit kam man ja auch ohne DLSS klar und nutze als Kantenglättung andere Sachen, wie z.B. TAA.

Sieht auch nich schlecht aus.
WQHD:

RDR2_2021_06_05_10_18_32_488.jpg

RDR2_2021_06_05_10_19_24_251.jpg

RDR2_2021_06_05_10_20_55_319.jpg

Settings:
25.jpg

Also wenn FSR ähnliche Ergebnisse liefert, wie TAA Mittel(+Nachschärfung) nativ, dann wär ich zufrieden damit.
Hauptsache das Bild wird nicht zu zermatscht und blurry.


Also her mit den unabhängigen Tests ! :D
 
ChrisMK72 schrieb:
In der Vergangenheit kam man ja auch ohne DLSS klar und nutze als Kantenglättung andere Sachen, wie z.B. TAA.
Einfach nur TAA benutzen glättet einem zwar die Kanten(naja eher zeichnet sie weich), es geht bei DLSS aber ja vor Allem um die 50-100% gestiegene Performance.
Ich glaube die wenigsten nutzen DLSS als reine Kantenglättung und TAA Ersatz, auch wenn das durchaus möglich ist.

Das würde bedeuten, dass man z.B. auf einem 1440p Bildschirm die Auflösung per VSR erst auf 4K hochschraubt, um sie dann per DLSS in 1440p rendern zu lassen.

Dann hätte man ein in 1440p gerendertes Bild auf einem 1440p Monitor, welches besser aussieht, als natives 1440p, dafür aber auch etwas schlechter läuft (~10%)
 
  • Gefällt mir
Reaktionen: ChrisMK72
ChrisMK72 schrieb:
Also wenn FSR ähnliche Ergebnisse liefert, wie TAA Mittel(+Nachschärfung) nativ, dann wär ich zufrieden damit.
Hauptsache das Bild wird nicht zu zermatscht und blurry.
Nach dem aktuellen Kenntnisstand wird FSR TAA und Sharpening nicht ersetzen, sondern das Bild nach sämtlichen Postprocessing Effekten skalieren. In der bekannten Demo handelt es sich um einen klassischen Super Resolution Filter, der Flächen leider kaum verschärft darstellen kann und lediglich kontrastreiche Kanten in einer höheren Auflösung strukturell rekonstruiert (Self Similarity Super Resolution). Texturierte Flächen mit wenig Kontrast werden also wohl häufig "blurry" dargestellt werden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ChrisMK72 und USB-Kabeljau
.Sentinel. schrieb:
Exakt- Ähnlich wie bei den RT Cores läuft der Dispatch und die anschließende Verarbeitung (wie die Gridanordnung) wieder auf den Shadern.
.Sentinel. schrieb:
Das klassische Auslastungs- bzw. Flaschenhalsproblem, mit welchen man auf jeder massiv parallel arbeitenden Maschine zu tun hat. Du kommst halt zwischenzeitlich doch immer wieder an den Punkt, wo du "syncen" musst.
Was ich bereits zur Vorstellung von Ampere bereits mehrfach ausgeführt habe in langen Beschreibungen, dass die RT-Cores zwar "asynchron" laufen können - also neben dem Shader arbeiten können, es aber für de Shader (Programm) irrelevant ist, sobald man dort auf die entsprechenden Daten warten muss zum verarbeiten.

Und ich glaube mich zu erinnern, dass ich diese Erläuterungen sogar gegen dich ein wenig mit Nachdruck durchsetzen muss. Aber da kann meine Erinnerung mir auch ein Streich spielen.
.Sentinel. schrieb:
Aber - Und das habe ich schon getestet. Du kannst alle Einheiten triggern (auch async), so dass sie gleichzeitig arbeiten und Ergebnisse liefern. Dass es immer wieder zu Abhängigkeiten und "interrupts" kommt, liegt in der Natur der Grafikpipelines, die immernoch stark seriell ablaufen.
Und auch hier erzählst du mir nichts neues, weil ich entsprechende Tests zur A100 als auch später zur 3090 und ich weiß dass Tensore-Cores, Shader und RT-Cores "gemeinsam" arbeiten können. Nur ist das - wenn man das nutzen will - auch mit entsprechendnen aufwand verbunden und die Grafikpipeline muss das auch hergeben.
.Sentinel. schrieb:
Geh mal in den NSIGHT und wirf einen Blick auf die Kommunikationspipelines/Bandbreiten. Da wird dann langsam klar, warum in den Karten die Kommunikationswege und Bandbreiten massiv aufgewertet wurden.
Auch das weiß ich. AMD und NVIDIA haben alles dafür getan die Kommunikationswege zu reduzieren, die Caches in der nähe größer zu gestalten usw. ;)
.Sentinel. schrieb:
Exakt - Ist halt wieder das Problem, dass DLSS seine Heuristik mit endgültigen Farbwerten durchführen muss.
Japp.
.Sentinel. schrieb:
Grundsätzlich wäre das so. Was man dabei aber nicht vergessen darf, sind die Bearbeitungszeiten der Units.
Selbst wenn wir annehmen würden, dass alles streng seriell ablaufen sollte, so ist das Zeitbudget für die Berechnung auf den tensor cores ein Vielfaches unter der Berechnung auf den Shadern.
Ja, das ist bekannt. Wobei ich in letzter Zeit mal ein paar Matrix-Operationen auf VecALUs optimiert gesehen habe, die da zumindest doch einiges an "Leistung" noch gewinnen. Gut, die Tensore-Cores sind dann immer noch um den Faktor 2 - 4 schneller als die Vec-ALUs, aber nicht mehr so die ganze Vollkatastrophe wie vorher.

Aber bei meinem Beitrag ging es weniger um das, was per Hardware möglich ist, sondern dass sich in letzter Zeit hier ein gefährliches "Halbwissen" verbreitet hat, in dem einige Spezies behauptet haben, dass ja DLSS bereits "asynchron" abläuft zum Bildaufbau her, und das ist eben so nicht richtig.
 
  • Gefällt mir
Reaktionen: .Sentinel. und Colindo
Taxxor schrieb:
es geht bei DLSS aber ja vor Allem um die 50-100% gestiegene Performance.

Ja, da bin ich dann auch mal gespannt, wie's in Tests zu FSR aussieht.

Nolag schrieb:
Texturierte Flächen werden also wohl häufig "blurry" dargestellt werden.

Hm ...
Das wär' allerdings nicht so meins.

Nativ mit TAA sieht ja auch schon leicht blurry aus.
Noch mehr mag ich dann eigentlich eher nicht.
Dann würd' ich eher bei anderen Sachen + nativ bleiben.

Mal schaun, wie's wird, mit FSR.

Taxxor schrieb:
Dann hätte man ein in 1440p gerendertes Bild auf einem 1440p Monitor, welches besser aussieht, als natives 1440p, dafür aber auch etwas schlechter läuft (~10%)

Also was das angeht, bin ich auch auf DLSS in RDR2 gespannt und wie das Ergebnis wird.
Werd's dann mit nativ + TAA vergleichen und mir meine Meinung dazu bilden.
Eine Chance geb' ich DLSS noch. ;) Bisher war ich nicht so total begeistert.

Um richtig mehr performance zu kriegen für RT alles on, brauche ich eher den performance mode von DLSS(z.B. in CP77). Und das sah dann auch nicht mehr so dolle aus.

Naja ... abwarten, Kaffee trinken und weitere Ergebnisse checken. :)
 
Teralios schrieb:
Ja, das ist bekannt. Wobei ich in letzter Zeit mal ein paar Matrix-Operationen auf VecALUs optimiert gesehen habe, die da zumindest doch einiges an "Leistung" noch gewinnen. Gut, die Tensore-Cores sind dann immer noch um den Faktor 2 - 4 schneller als die Vec-ALUs, aber nicht mehr so die ganze Vollkatastrophe wie vorher.
Faktor 2-4? Was können diese VecALUs denn? Nur Skalarprodukt reicht nicht für Faktor 2-4.
 
Taxxor schrieb:
Das hätte man mitbekommen, so viel wie sich zu Release von den AIBs von Nvidia z.B. über deren geringe Marge aufgeregt wurde
Vielleicht halten sie die Klappe weil die Chips zwar teurer sind aber sie dafür auch viel mehr vom Handel verlangen.
 
Zuletzt bearbeitet:
Matrix FP16 zum Beispiel war in der MI50 noch per optimiertem VecALUs. Faktor 2 im Vergleich zur MI100 (pro Core)
1622885041060.png

Ergänzung ()

ComputationA100V100
Matrix FP16512128
Matrix INT8102464
Sieht gegenüber Nvidia gar nicht so schlecht aus (Daten pro Tensor Core). AMD verliert letztlich durch die geringe Anzahl CUs im Vergleich zu Tensor Cores.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: foo_1337, .Sentinel. und Teralios
ZeroStrat schrieb:
Faktor 2-4? Was können diese VecALUs denn? Nur Skalarprodukt reicht nicht für Faktor 2-4.
1. Ich habe geschrieben, dass die Tensore-Kerne - bei optimierten Algorithmen zur Matrizen-Operationen - immer noch um den Faktor 2 - 4 schneller sind, also 200 % - 400 % mehr leisten.

2. Geht es nicht um Skalarprodukte sonder um ADD, MUL und MAD. Wenn du weißt wie eine Marizen-Multiplikation geht, dann kann man sich die Eigenschaften von VecALUs zu eigen machen.

Matrizen-Operationen sind ein klassischer Fall - gerade bei VecALUs: Nimm dir deutlich mehr Speicher und man kann echt etwas erreichen.
 
leonavis schrieb:
Das kann ja jeder sehen, wie er möchte. Allerdings habe ich schon ein kleines Problem mit propietärer Software, lässt sich ganz gut an der letzten größeren Microsoft-Sicherheitslücke sehen.

darf ich an Heartbleed erinnern eine Sicherheitslücke die 2011 in den openssl code implementiert wurde und 2014 dann released wurde. Das ist niemanden aufgefallen soviel zum thema closed source sei hier problematischer.
 
  • Gefällt mir
Reaktionen: xBitwinSDKx und foo_1337
Benji18 schrieb:
darf ich an Heartbleed erinnern eine Sicherheitslücke die 2011 in den openssl code implementiert wurde und 2014 dann released wurde. Das ist niemanden aufgefallen soviel zum thema closed source sei hier problematischer.
Das ist eine Diskussion, die man sehr ausgiebig und lange führen kann und bei der man am Ende dennoch sich nur im Kreis gedreht hat.

OpenSource bedeutet nicht automatisch, dass in der Software keine Sicherheitslücken sind oder dass diese sofort erkannt werden.

Der Vorteil von OpenSource ist aber, dass jeder denn Quelltext prüfen kann und man daher sieht, ob jemand absichtlich auch Schabernack treibt, was bei ClosedSource nicht möglich ist.
 
  • Gefällt mir
Reaktionen: jonderson, Tanzmusikus, foo_1337 und eine weitere Person
Zurück
Oben