SFR wird auch Super Tiling gennant:
Ähm nein... Bitte nicht solche technischen Unwahrheiten verbreiten!
SFR steht allgemein für Split Frame Rendering. Das beschreibt einfach mal ganz generell nur ein Verfahren, welches ein Frame in zwei oder mehr Teile aufteilt (eben splittet). Wie die Aufteilung vollzogen wird, ist völlig nebensächlich, damit sich das SFR schimpfen darf.
Kurzum, um es dir in einem Beispiel zu verdeutlichen. Ein Quadrat ist IMMER ein Rechteck. Ein Rechteck aber nicht zwangsweise ein Quadrat.
Heist unterm Strich, Super Tiling ist sozusagen immer SFR. Aber SFR ist keineswegs immer Super Tiling! Somit kann "SFR wird auch Super Tiling gennant" einfach mal nicht stimmen!
Denn es gibt noch ganz paar andere Methoden, das Frame im SFR Mode aufzuteilen. Nämlich horizontal oder vertikal geteilt. Somit berechnet eine GPU die linke, die andere die rechte Bildhälfte. Oder eine GPU berechnet die obere, die andere die untere Bildhälfte. Beides wäre NICHT Super Tiling. Beides wäre aber trotzdem SFR.
Auch lese ich hier im Thread ziemlich viele Unwarheiten oder Halbwissen. SFR ist eigentlich ein ziemlich alter Hut. Älter sogar noch als AFR, wenn man es genau nimmt...
SFR wurde dem Namen nach bspw. seinerzeit schon von 3dfx für die Dual GPU Voodoo Modelle genutzt bzw. bei der Nutzung zweier Karten. Hier steht/stand "SLI" auch für "Scan Line Interleave" -> was sozusagen vom Namen her schon SFR bedeutet. Zeilenweise Berechnung sozusagen.
Die ATI Rage Fury MAXX hingegen nutzte glaube ich AFR.
Ebenso das Thema mit der VRAM Verdopplung ist viel zu heiß gekocht, als es gegessen wird... Stellt euch doch mal die Frage, wie das technisch gehen soll?
Wo man ein einziges statisches Bild berechnet, ohne jegliche Dynamik, da mag das noch funktionieren. Wie soll das aber in Bewegung funktionieren? Selbst mit SFR?
Auch hier ist wieder entscheidend, den Hintergrund wenigstens ansatzweise zu kennen -> anstatt dem Marketinggeblubber von wegen VRAM GPU1 + VRAM GPU2 = VRAM in DX12 und SFR zu glauben!
Der überwiegende Teil der Daten im VRAM sind während der Spielzeit einfach mal Texturdaten. Und diese Daten sind keineswegs alle samt immer zu jeder Zeit in Nutzung. Sondern die GPU(s) halten diesen VRAM Pool für Texturdaten über eine Zeit lang, damit die Texturen im schnellen Zugriff sind. Dabei bedient man sich oftmals auch gewisser Methoden, die einem Prefetching nahe kommen. Was habe ich da vor geraumer Zeit mal gelesen? -> Du sitzt abends auf dem Sofa und willst mit Bier den TV Abend versüßen. Also schickst du deine Frau zum Bierholen an den Kühlschrank -> da der Weg von Sofa zu Kühlschrank zu weit ist (analog dem Weg von GPU über PCIe zum RAM). Deine Frau ist ziemlich klever uns weis, dass es sowieso nicht bei einem Bier bleiben wird, also holt sie gleich mal zwei oder drei aus dem Kühlschrank und stellt sie auf den Tisch vors Sofa. Du brauchst aber erstmal nur ein Bier -> dann ggf. das zweite. Und selbst wenn du das dritte nicht willst, ist auch egal. Der Tisch am Sofa ist der VRAM und somit im schnellen Zugriff für dich.
Wenn man das mal zusammen fasst, heist das unterm Strich, dass im VRAM Daten liegen, auch teils völlig ohne direkt echten Bedarf. -> das ist schonmal Punkt 1, der dieser VRAM Verdopplung in die Suppe spuckt.
Der zweite Punkt ist, dass, egal wie man das einzelne Bild nun verteilt. Durch eine Bewegung des Sichtfeldes mit sehr hoher Warscheinlichkeit der Fall eintreten wird, dass die Texturdaten, die vorher von GPU 1 benötigt werden, nun von GPU 2 benötigt werden. -> Wir erinnern uns zurück, die GPU hält die Texturdaten länger als eigentlich benötigt. Somit liegen bei Bewegung des Bildes ziemlich viele Daten doppelt im VRAM, weil eben auf beiden GPUs. Da beide GPUs schnellen Zugriff auf diese Daten benötigen.
Und der dritte Punkt, Texturen sind shared Ressourcen. Diese werden sehr häufig wieder verwendet. Die reine Texturbasis ist oftmals gar nicht so verschieden. Die Möglichkeiten zur Veränderung während der Laufzeit hingegen sind gewaltig. So lassen sich bspw. von einer einzigen HighRes Textur spielend große Bodenflächen texturieren mit gedrehten und random generierten Zufallswerten, welche die Ausrichtung der Textur verändern.
Heist unterm Strich, die gleiche Basistextur wird in dem Fall sogar aktiv von beiden GPUs genutzt und muss somit auch in beiden VRAM Pools vorhanden sein! -> sicher zwar ein extremes Beispiel. Aber auch in Top Modernen Titeln sind wir lange nicht an dem Punkt, wo wir so extremst viele unique Texturen nutzen, das jedes Objekt dediziert eine eigene Textur (oder eigene Texturen) bekommt -> diese wären aber für die Addition des VRAMs von diesem Gesichtspunkt aus notwendig um Überschneidungen zu verhindern. -> dafür steigt der VRAM Bedarf wieder so derart drastisch an, dass es ebenso nicht aufgehen würde. -> also ebenso keine Lösung.
Unterm Strich? Das wird so nicht gehen... Zumindest nicht in der Praxis.
Mit DX12 erwarte ich mir ehrlich gesagt eher einen völlig anderen Weg. Man wird, so meine Vorstellung, via SFR und MGPU Verfahren die einzelnen Objekte des Bildes, welche dargestellt werden sollen, möglicherweise auf verschiedene GPUs verteilen. Eventuell sogar soweit runter gebrochen, dass (Stichwort ASync Computing) die GPU selbst noch mit Teilen des Bildes beschäftigt ist und gleichzeitig aber schon Compute Aufgaben wahrnimmt. Um so mehr verschiedene Teilaufgaben man hat, desto höher könnte da die Effizienz und somit die Skalierung durch/von MGPU SFR werden...
