Az FSR Redstone megjelenésével párhuzamosan érkeztek olyan videók, amelyek a képgenerálás esetében a képek egyenetlen megjelenítéséről beszéltek. Többek között erről szólt a Hardware Unboxed bemutatója. Röviden tehát a média hiányolja a frame pacinget az FSR Redstone képgeneráló moduljából, ugyanakkor fontos kiemelni, hogy ez a modul soha nem tartalmazta ezt az eljárást, mert nem itt dől el maga a kérdés. A fentiek miatt érdemes tisztába tenni, hogy mi történik a háttérben, ugyanis a képgeneráló úgy működik, ahogy kell, az egész jelenséget az alapértelmezett DXGI swapchain okozza.
Mielőtt belemerülnénk a részletekbe tisztázni kell, hogy mi történik a képmegjelenítés során. Amikor a rendszer számolja az adott képkockát, akkor azt az úgynevezett háttérpufferbe írja, és ha a számítás befejeződött, akkor úgy kerül ki a kijelzőre, hogy a háttérpuffer lesz a képkockapuffer, aminek a tartalmát a monitor megjeleníti. Tehát a GPU-hoz tartozó memóriában, a manapság jellemző dupla pufferelés során két puffer van fenntartva, az egyikből a kijelző felé irányul az adat, a másikba pedig éppen a számolt tartalom leképezése történik. Ez a két puffer van cserélgetve, amikor egy adott képkocka számítása végbemegy, és ezt a műveletet hívják flipnek. Ha tehát a háttérpuffer elkészül, akkor az lesz az aktuális képkockapuffer, a korábbi képkockapuffer pedig ismét háttérpuffer lesz, várva az új adatokat. Fontos, hogy itt nem történik konkrét adatmásolás, egyszerűen csak a pufferek címe változik a memóriában.
Hirdetés
Ez persze nagyon leegyszerűsített magyarázat, mert kalkulálni kell olyan dolgokkal is, mint a szinkronizálás, hogy lehetőleg ne legyen képtörés, de az elvi működést jól szemlélteti. Az egész folyamatstruktúra működéséért az úgynevezett swapchain felel, ami menedzseli a képi tartalom lehetőleg optimális megjelenítését.
Ez mind nagyszerű addig a pontig, amíg az összes képkocka ténylegesen számolt, ugyanis az alapértelmezett DXGI swapchain pontosan tudja, hogy mit kell tenni velük. Csakhogy a képgenerálás során a képkockák legalább fele generált, és a gyárilag alkalmazott Windows implementáció ezeket nem tudja kezelni. Emiatt történt az, hogy amikor a képgeneráló technológiák bejöttek a képbe, mindegyik gyártó készített hozzájuk egy alternatív swapchaint, ami képes felismerni és megfelelően kezelni a generált képkockákat is. Ezeket a játékoknak szintén implementálni kellett, amikor beépítették az NVIDIA DLSS, az AMD FSR és az Intel XeSS képgenerálókat, ugyanis a frame pacingért, vagyis a számolt és generált képkockák egyenletes megjelenítéséért nem maguk a képgenerálók felelnek, hanem a hozzájuk tartozó swapchain modul.
Mindaddig semmi gond nincs, amíg a különálló képgenerálók implementációja natív, vagy ha nem is az, akkor a driverből betöltött frissítés támogatja azt a swapchain modul, ami implementálva van az adott játékban. Ha ez a feltétel nem valósul meg, akkor a játék kénytelen az alapértelmezett DXGI swapchaint használni, ami mellett a képgenerálás továbbra is megtörténhet, csak a frame pacinghez szükséges swapchain modul már nem tud betölteni. Ezt látjuk az FSR Redstone esetében az egyes címeknél, ugyanis a driver egy korábbi FSR képgeneráló implementációt cserél le az új verzióra, de a hozzá tartozó, programszinten implementált FSR swapchain már nem kompatibilis vele, így marad a Windows gyári megoldása, ami nem ismeri fel a generált képkockákat, így nem is tudja ezeket egyenletesen megjeleníteni a kijelzőn. Az új swapchain modul viszont ehhez is elérhető, méghozzá FSR Frame Generation SwapChain (ML) 4.0.0 jelzéssel, tehát abszolút implementálható a játékokba, ahogy a korábbi opciók.
A helyzet az, hogy ez nem egyedi jelenség. Minden gyártó képgenerálója küzd ettől, mert nem magukban a képgeneráló rendszerekben van a hiba, hanem az alapértelmezett DXGI swapchain nem támogatja a technikát. Tehát, amikor a driver kicseréli a játékba implementált képgenerálót egy újabb verzióra, de a natívan használt swapchain modul azzal nem kompatibilis, akkor mindig megszűnik a frame pacing, mert a Windows gyári megoldása nem ismeri fel valós képkockaként a generált képkockákat.
Az NVIDIA erre a problémára építette be a Blackwell architektúrájú GPU-kba a hardveres flip meteringet, ugyanis képgeneráló folyamatosan fejlődik, és ezzel egyetemben az új DLSS verziót az egyes címekben le tudja cserélni a driver. De pont ugyanaz ezzel a gond, mint az FSR Redstone esetében, egy ponton túl az alternatív swapchain felé megszűnik a kompatibilitás, a DXGI swapchain pedig hozza a magával a képgenerálással kapcsolatos problémáit.
Az optimális az lenne, ha a játékok mindig frissülnének a legújabb DLSS, FSR és XeSS swapchain modullal. És igen, ez a legújabb DLSS esetében is fontos, mert hiába van beépítve egy hardveres flip metering a Blackwell dizájnokba, amikor a szoftveres modul működőképes, akkor azt használják az alkalmazások. Ennek oka, hogy a hardveres megoldás fix logikája bizonyos körülményekhez kötött, így a legjobb eredményt akkor adja, ha a flipek ütemezése nem ütközik a változó szinkronizációval. Ha már van valamilyen VRR implementációt használó adaptív frissítés, akkor a hardveres flip metering pontatlan flip időzítést produkálhat, különösen a képkockasebesség ingadozásánál, ami különböző problémákhoz vezet, például képkockacsúszás, vagy apróbb akadozás. Szoftveres szinten ezt a problémát az alkalmazás azért tudja kezelni, mert ismeri a képkocka GPU-ba érkezésének pontos idejét, és ezért van az, hogy az NVIDIA is kínál az új DLSS-hez alternatív swapchaint, mert a hardveres flip metering nem tud mindent körülményt kezelni.
A fentieknél is jobb megoldás lenne, ha maga az alapértelmezett DXGI swapchain frissülne egy olyan verzióval, ami valós képkockaként képes értelmezni a generált képkockákat, de egyelőre a Microsoft nem szentel túl nagy figyelmet a képgenerálásnak.
Mivel a jelenlegi helyzetben mindegyik képgenerálóhoz szükséges az alternatív swapchain, amit a gyártók biztosítanak is, az a legjobb, ha az éppen aktuális legújabb DLSS, FSR és XeSS képgeneráló verziót natívan támogatja egy játék. Ha a driverből lesznek ezek engedélyezve, akkor lehetnek problémák, és ez az oka annak, amiért az NVIDIA, az AMD és az Intel is kikapcsolhatóvá teszi a felülírást, hogy a felhasználó visszatérhessen a biztosan natívan implementált, alternatív swapchaint használó verzióhoz. A valóságban viszont eleve számolnak a cégek azzal, hogy magát a képgenerálást másodpercenként legalább 120 képkockára tervezik, vagy még többre, ha nem csak a képkockák felét generálják így. Emiatt nem vette ezt korábban észre senki, most is csak úgy derült ki, hogy a külső eszközzel rögzített felvételt lelassították úgy, hogy egy másodpercnyi valós tartalom lejátszása nagyjából két percbe telt, ami hozzávetőleg százszoros lassítás. Viszont ez a jelenség azóta velünk van, amióta a képgenerálást a gyártók felülírják driverből, csak eddig még senki sem lassította le százszorosan a felvett képet, hogy ezt megnézzék.
Mindezek mellett a képgenerálás nem valós számítás, inkább csak a folyamatosságot próbálják vele növelni. Tehát másodpercenként 120 képkocka élménye félig generált tartalommal közelebb van a másodpercenkénti 60, valóban kiszámolt képkockához, mint a tényleges és hamisítatlan 120 képkocka/másodperces élményhez. Emiatt sem ajánlják ezt a cégek az említett képkockasebesség alatt, hogy ne látszódjanak a rendszer tipikus problémái, származzanak azok a DXGI swapchainből, az optikai áramlás, illetve a színek rossz meghatározásából, vagy a pontatlanul időzített flipből. A cél tehát nem az, hogy megduplázzák a sebességet, hanem az, hogy a valóban számolt képkockasebességnél valamivel jobb élményt adjon a képgenerálás, és ezt jelenleg mindegyik megoldás hozza. A legjobban persze akkor, amikor natívan implementálva van a játékba, így nem kell a driverből kényszeríteni az újabb verziók betöltését, különböző extra problémákat bevállalva.
