Zumindest bei der X-Box-Demo war deutlich zu sehen, dass SFS während Kameraschwenks drastisch erhöhten Speicherbedarf hatte. Es werden also zunächst viele unbenötigte Daten geladen und erst später evicted, nicht der Bedarf vorhergesagt. Der von dir zitierte Satz ist in meinen Augen auch weder schlüssig noch etwas wofür man Sampler Feedback benötigt: Welche Texturen in der Szene sind ergibt sich aus deren Geometrie, in welcher Auflösung sie benötigt werden aus der Entfernung zur Kamera. Beides ist lange vor dem Sampling schon dem auf der CPU laufenden Teil der Engine bekannt. Dementsprechend beginnt der Satz auch mit "... request of Mip 0 ...". Das heißt die gewünschte Qualität ist von Anfang an bekannt, aber wegen einem zu lahmen Speichersubsystem (DirectStorage von SSD statt Texturepool im RAM?) zeigt das beschrieben Systeme eine zeitlang trotzdem Matsch an. Neuerung ist gegebenfalls, dass es das automatisch macht – wobei die Differenzierung zwischen bestehenden automatischen Systemen, die Entwickler in ihre Engines integriert haben und einem neuen Automatismus, den Entwickler in ihre Engine integrieren müssen, nicht nachvollziehen kann. Wenn die Devs nichts machen, haben sich auch kein SFS.
Was ich und auch dein vorangehender Link dagegen beschrieben haben sind Mechanismen, um Teile einer Mip-Map nie in hoher Qualität zu laden, weil man dank Shader Feedback im zweiten Renderingpass weiß, welche Texturteile unsichtbar sind, was sich aus der Geometrie nicht ohne weiteres im voraus ableiten lässt. Aber das geht, wie geschrieben, nur bei hohe Frameraten sinnvoll. Mit 60 Fps oder gar 30 Fps sind zu viele Bildteile zu oft in Pass 1 zu sehen, wären also ständig sichtbar matschig. Selbst bei 120 Fps würde ich temporale Artefakte erwarten, beispielsweise einen mehrere Pixel breiten schmierigen Streifen wenn man um eine Ecke strafed, weil eben nur der bereits sichtbare Teil der dahinter liegenden Texturen im Speicher liegt, während sichtbar werdende Teile erst nachladen müssen. Da sind prognostizierende Ansätze, die einem sagen, was gebraucht werden wird, die deutlich bessere Alternative zu einem Feedbacksystem, das einem sagt, was gebraucht wurde.
(Gilt, wie gesagt, alles nur für PCs/System mit exklusivem VRAM. Wenn man Texturspeicher dynamisch vom Systemspeicher abzwackt, kann es sich dagegen gerade bei niedrigen Frameraten lohnen, einiges davon kurzzeitig freizuschaufeln, weswegen ich die Technik für Konsolen auch spannend finde.)
Was ich und auch dein vorangehender Link dagegen beschrieben haben sind Mechanismen, um Teile einer Mip-Map nie in hoher Qualität zu laden, weil man dank Shader Feedback im zweiten Renderingpass weiß, welche Texturteile unsichtbar sind, was sich aus der Geometrie nicht ohne weiteres im voraus ableiten lässt. Aber das geht, wie geschrieben, nur bei hohe Frameraten sinnvoll. Mit 60 Fps oder gar 30 Fps sind zu viele Bildteile zu oft in Pass 1 zu sehen, wären also ständig sichtbar matschig. Selbst bei 120 Fps würde ich temporale Artefakte erwarten, beispielsweise einen mehrere Pixel breiten schmierigen Streifen wenn man um eine Ecke strafed, weil eben nur der bereits sichtbare Teil der dahinter liegenden Texturen im Speicher liegt, während sichtbar werdende Teile erst nachladen müssen. Da sind prognostizierende Ansätze, die einem sagen, was gebraucht werden wird, die deutlich bessere Alternative zu einem Feedbacksystem, das einem sagt, was gebraucht wurde.
(Gilt, wie gesagt, alles nur für PCs/System mit exklusivem VRAM. Wenn man Texturspeicher dynamisch vom Systemspeicher abzwackt, kann es sich dagegen gerade bei niedrigen Frameraten lohnen, einiges davon kurzzeitig freizuschaufeln, weswegen ich die Technik für Konsolen auch spannend finde.)
