Mindenféle inputra reagál a Boost, csak az AMD elmondta, hogy figyelembe veszik a képkockasebességet is, és ha a rendszer úgy ítéli meg, hogy nem kell nagyon emelni a tempón, akkor inkább nem állítja dinamikusan a felbontást. A press meghajtóban direkt ezért aktív a developer mód, hogy ha valaki tesztelni akarná a minőségcsökkenést, akkor elég csak a shiftet nyomogatnia, és arra azonnal reagál a Radeon Boost, mert az algoritmus alapján nincs kőbe vésve, hogy minden gombnyomásra, vagy bemozdulásra csökkenni fog a felbontás, ahhoz teljesülnie kell egyéb feltételeknek is, és ebből a szempontból eléggé bonyolult a rendszer, nincs egy fix mozdulatsor, ami alapján ez biztosan kiváltható. A végleges meghajtóban ez a trükk a shifttel nem lesz benne.
Régi Boost működést az AMD azért mellőzi, mert olyan megoldást akartak, ahol erős odafigyelés nélkül nagyon nehezen legyen észrevehető a minőségcsökkenés. Egy képkockasebességhez kötött módszerrel a jelenethez lenne kötve a minőség, vagyis simán tudnál úgy nézelődni, hogy nem natív részletességet kapsz. Ezzel a módszerrel ezt nem tudod igazán megtenni, mert ahhoz, hogy nézelődj, mellőznöd kell a gyors mozgásokat, és ezek nélkül a Boost nem igazán működik extrém minőségcsökkentéssel. Mozgás mellett pedig egy rakás olyan tényező van, ami elmossa a Boost minőségcsökkentését, a legtöbb játék már eleve alkalmaz valamilyen motion blurt, de pusztán a gyors mozgás ténye is elég ahhoz, hogy maga a minőségvesztés kevésbé legyen látható. Emiatt mondják azt a reviewekben, hogy ha csak játszanak, és nem keresik a felbontáscsökkenés hatását, akkor nem igazán veszik ezt észre, és pont ez volt a koncepció, hogy elérjék ezt a hatást. Szimplán sebességszintekhez kötve nem lehetett volna megcsinálni.
A fentiek mellett a dinamikus felbontásskálázást rendkívül egyszerű beépíteni egy játékba. Az API-k minden tartalmaznak ahhoz, hogy a fejlesztő írjon a motorba egy ilyen rendszert. Egy input alapján működő felbontásskálázást viszont nem lehet csinálni, mert az API-knak az az alapvető követelése megakadályozza, hogy legyen parancslista. Lényegében illegális dolgot csinálna a játék, ha ezt valahogy elkezdené kontrollálni, mert ezek menedzselése az OS és a driver feladata. Alapvetően nem is tudnák megcsinálni a fejlesztők anélkül, hogy az OS-en belül bizonyos fájlokat felül nem írnának. Tulajdonképpen az AMD is ezt csinálja a Chillel, megkerülik a Microsoft korlátjait. Ilyen szempontból ugyanaz a helyzet a Boosttal is, mint a Chillel. Nem tudja senki sem lemásolni, nem mellesleg a szabadalmak is az AMD-nél vannak. Ez gyakorlatilag egy egyedi funkció ismét a driverben, amit se fejlesztő, se konkurens nem tud felkínálni. Ez innentől egy marketinges szempont is, mert csináltak egy olyat, amit előttük még senki, és a szabadalmakat figyelembe véve, valószínűleg utánuk sem. Ugye a Chillt se másolják a konkurensek. Túl bonyolult, túl sokáig tartana megcsinálni, és még fizetni is kellene az AMD-nek érte.
(#44687) Tyrel: Lehet a képkockasebességhez kötni. Igazából az nem is olyan nehéz. Kb. olyasmi meló, mint az Anti-Lag. Ugye ott is az alap a Chill, csak nem a Chill működéséért felelős bonyolult algoritmus fut rajta, hanem egy jóval egyszerűbb, és így nyilván sokkal kevesebb idő volt tesztelni is, mert nem dimanikus a helyzetekre való reakciója. Ha mondjuk az fps-hez kötnék ezt, akkor ott is az lenne, hogy adott az alap a Boostban, csak a döntésért felelős algoritmus változik. Elképzelhető, hogy ha megcsinálják a Boostot blacklistesre, tehát úgy, hogy működjön mindennel, mint a Chill, akkor raknak be egy alternatív algoritmust. Ez tényleg nem egy nagy meló. Viszont ennek a minősége biztos nem lenne olyan jó, mint a mostanié. De kivitelezhető és viszonylag egyszerűen megvalósítható nekik, csak kérdés, hogy akarnak-e vele foglalkozni. Első körben biztos nem, mert a fókuszt biztosan a Boost befejezése jelenti. Utána lehet, ha kész a Boost, akkor onnan nem lenne több három hónapnál egy módosított algoritmussal működő rendszer.
(#44689) Tyrel: Az AI az jó dolgot csinálna a DLSS-nél, ha az NV rakna bele pénzt. Alapvetően a DLSS-nek nem a technológiai háttere a rossz, hanem az, hogy az NVIDIA egyszerűen nem ad ingyen gépidőt a fejlesztőknek. Így meg azért rohadt nehéz ám jó eredményt elérni, hogy kell egy rakás számítási kapacitás a tréninghez, de közben egy órát is marha drágán mér az NVIDIA. A Microsoftnak van egy ugyanilyen megoldása DirectML-re. Csontra ugyanezt csinálja, csak a különbség, hogy a neuronháló tréningelését ingyen mérik a DirectML-t támogatók között. És elég jók is az eredmények, ha nem azt kell nézni, hogy van x pénz, és az elég y órára, ha pedig nem jó a neuronháló, akkor ez van, ennyire volt zseton. Az AI az nem ilyen, ott nem lehet előre megmondani, hogy mennyi idő múlva készül relatíve jó eredményt biztosító neuronháló, emiatt lenne kritikus ezeknél a megoldásoknál, hogy legyen a fejlesztőknek ingyen elérhető számítási kapacitás, mert egy helyi munkaállomáson ez a munkafolyamat nagyon sokáig tartana, úgy kb. örökké.
Itt valószínű egyébként, hogy az NV erre üzletet akart építeni, tehát amíg a Microsoftnak megéri ingyen Azure kapacitást adni csak azért, mert a fejlesztő DirectML kódot ír (ez nincs Linuxon->több Windowst adnak el->profit), addig az NV-nek nem feltétlenül éri meg ez, mert drágábbra jön ki gépidőt adni, mint lehúzni a WC-n a technológiát. Ettől függetlenül a DLSS koncepciója jó, csak a piszkos anyagiak elrontják a gyakorlatot. Ugyanakkor, ha bevállalnának egy rakás anyagi veszteséget ezen, akkor bőven jobb lehetne a minőség, mint amit az alternatívák adnak. Jensennek azonban kell a zsé új bőrkabátra. 
[ Szerkesztve ]
