Az AMD egy komoly szikladarabot dobott az állóvízbe, amikor az újabb Radeonokra bejelentette a Fluid Motion Frames (FMF) eljárást, amely egy friss eszközillesztőn belül ki is próbálható. Ez önmagában működik, ahogy egy ilyen jellegű technológia, meghajtóból erőltetve működhet, de viszonylag kevés hardvert támogat, hiszen RDNA 2 vagy RDNA 3 architektúrára épülő Radeon kell hozzá. Ezzel gyakorlatilag nem csak a régebbi Radeonok, de a teljes NVIDIA GeForce és Intel Arc termékskála ki van zárva a képgenerálás, külsőleg kényszerített lehetőségéből.
Hirdetés
A Steamen megvásárolható Lossless Scaling program újítása ezt a nagy réteget szeretné megszólítani, ugyanis a fejlesztést végző szakember, a 2.5.0-s verzióba implementálta a saját képgeneráló technológiáját. Az LSFG, vagyis a Lossless Scaling Frame Generation eléggé trükkös módon működik, mivel egy külső segédprogramnak azért nincs annyi lehetősége az efféle technika alkalmazására, mint például az AMD-nek a saját meghajtóján belül. Éppen ezért az LSFG a népszerű OBS streamelő program által használt képkockafelvevő API-t alkalmazza, hogy megszerezze a számolt képkockák adatait. Ezután két egymás utáni képkockából készít egy generált képet. Ehhez teljes egészében compute shadereket használ, vagyis a GPU-k általános feldolgozóin történik meg a munka, így gyakorlatilag minden compute shadert támogató grafikus vezérlővel kompatibilis.
Az LSFG algoritmusnak az általános jellege nagy előnye az AMD-féle FMF-hez viszonyítva, utóbbi ugyanis architektúraspecifikusan PAL-ban van megírva, amit csak a Radeonok képesek értelmezni, ráadásul az egyedi optimalizálások miatt nem is az összes architektúra, hanem csak a két legújabb. Ugyanakkor az LSFG az alkalmazott, teljesen általános módszerrel pár hátrányt is magára vállal. Egyrészt a rendszer képtelen magát dinamikusan kikapcsolni a gyors mozgásoknál, így az itt keletkező, generálásból származó képi hibákat muszáj bevállalni. Másrészt a felvett majd generált képkockák visszajátszása egy overlay felületen történik meg. Utóbbi azt jelenti, hogy az LSFG nem kompatibilis az olyan programokkal, amelyek overlay felületen keresztül közvetítik az információkat a kijelzőre, ugyanis a saját adataival ezeket végül felül fogja írni egy másik overlay felületen.
Ezen túlmenően fontos megjegyezni, hogy az LSFG az AMD-féle FMF-fel ellentétben nem alkalmaz kiegyenlítést a képkockák megjelenítése szempontjából. Vagyis a számolt és generált tartalmak aszerint jelennek meg egymás után, ahogy kész lesznek, és a helyzet az, hogy a generálás mindig sokkal gyorsabb a számolásnál. Ez gyakorlatilag állandó mikroakadásokat eredményezhet. Az LSFG eljárás fejlesztője tud erről, és azt javasolja a felhasználóknak, hogy manuálisan limitálják a valós képkockasebességet az alkalmazott kijelző frissítési frekvenciájának felére. Vagyis, ha egy megjelenítő 60 Hz-es, akkor a játékot manuálisan 30 képkocka/másodperces sebességgel érdemes futtatni, és ilyenkor jelentősen megritkulnak az apróbb akadások, mivel a monitor a frissítési frekvenciával szinkronban jelenít meg egy valós és egy generált képet. Persze különböző, nem várt tényezők miatt ez lehet, hogy nem teljesül minden egyes pillanatban, de a futtatási idő nagy részében igaz lesz.
Az LSFG fejlesztője egyébként leginkább 120 Hz-es kijelzőt javasol, méghozzá 60 képkocka/másodperces limittel futtatott játékkal, így relatíve jó lesz a kapott élmény.
Természetesen a Lossless Scaling képgeneráló megoldása közel sem optimális, de külső segédeszközként a program nagyon limitált lehetőségekből gazdálkodik, és ehhez mérten az LSFG kihozza a legtöbbet. Ennél jobbat tényleg csak meghajtóba építve lehet kínálni, ahol azért a gyártók még mindig eléggé uralják a képmegjelenítés futószalagját, tehát jobban tudnak igazodni a képgenerálás specifikus problémáihoz. Ha azonban gyári technológiával nem kecsegtet az adott grafikus vezérlő meghajtója, akkor a Lossless Scaling képgenerálója is jobb lehet a semminél.
