A LucidLogix számos technológiával gazdagította már a PC-s piacot, de egyelőre ezekből egyik sem vált széles körben alkalmazottá. A Hydra a több GPU-s rendszereket szerette volna forradalmasítani, de már a technológia mellett álló cégek is letettek az alkalmazásáról. Noha az alapötlet nagyon jó, a kivitelezéssel problémák vannak, mivel az objektumalapú feladatmegosztás sok finomhangolást igényel a VGA-k grafikus driverében is, így megfelelő sebesség mellett csak házon belül lehet kivitelezni. A Virtu névre keresztelt technológia már sikeresebb volt, de az asztali piacon a felhasználók nem szeretnek kompromisszumokat kötni, márpedig a rendszer működése lassította a VGA sebességét. Ettől függetlenül sokaknak számított, hogy a dedikált GPU lekapcsolt a terhelésmentes időszakokban, amivel energiát lehetett megspórolni, így ha nem is beszélhetünk kirobbanó sikerről, a technológiát úgymond elfogadta a piac.
A vállalat a Hydra fejlesztéséről alapvetően letett, a terméktámogatás ugyan megmaradt, de a jövőben valószínűleg nem lesz új hardver a technológiához. A Virtu esetében már más a helyzet, ugyanis a rendszert több extrával turbózta fel az elmúlt hónapokban a LucidLogix. Ezek közül a Virtual Vsync-et és a HyperFormance-t reklámozták. Előbbi működését egy korábbi hírben ecseteltük, míg utóbbiról túl sokat nem árult el a vállalat, de elméletben 30-70%-kal képes növelni az adott rendszer teljesítményét, mégpedig úgy, hogy csökkenti a grafikus magra ható terhelést. Ezzel kapcsolatban anno szkeptikusak voltunk, sőt konkrétan még mindig azok vagyunk, mivel nincs konkrét magyarázat, hogy ez miképp működik. Találgatások persze vannak, de azok kapcsán még rengeteg kérdés maradt megválaszolatlanul.
A CES alkalmával szerencsére rengeteg információ szivárog, így sok adatot gyűjtöttünk arról, hogy a HyperFormance miképp működik. A technológia a kötelezően aktív Virtual Vsync mellett kihasználja, hogy egy Virtu driverrel működő rendszeren belül a kijelző az integrált grafikus vezérlőre van csatlakoztatva. Az elméleti működést nehéz lenne szakzsargonnal elmagyarázni, így érdemes az egészet gyakorlati példákkal bemutatni.
Tegyük fel, hogy a csatlakoztatott megjelenítő 60 Hz-en működik, ilyenkor a panel másodpercenként 60 képkockát jelenít meg. A legjobb az, ha a grafikus kártya is szinkronban 60 képkockát számol másodpercenként, de ez kivitelezhetetlen, így ez az érték nagyon változó lesz. Ilyenkor szokott előjönni a képtörés, amit az alábbi ábra szemléltet.
[+]
Látható, hogy az első képkocka két helyen is el van törve, vagyis a kijelzőre összesen három képkocka egy-egy része van kirajzolva. Ez ellen lehet védekezni a vertikális szinkron alkalmazásával, ami addig nem küldi ki az adott képkockát a monitorra, amíg az be nem fejezte az előző kirajzolását. Tulajdonképpen így lehet elérni a szinkronizált működést, ám ilyenkor elő lehet hozni az input lag kérdését.
Ha az adott program 60 képkocka/másodperces tempóval fut, és a megjelenítő frissítése is 60 Hz-re van állítva, akkor a beviteli eszközön kiadott parancs és a megjelenített kép között 40 ms telik el, ami az adott szituációt tekintve megközelítőleg két és fél képkocka késés. Véleményünk szerint ez a legtöbb felhasználó számára több mint megfelelő érték, főleg abból kiindulva, hogy az extrém játékosok rétege rendszerint kétutas CrossFire, illetve SLI konfigurációkat épít, melyek AFR technológiát használnak, és a késés ugyanilyen szituációban öt képkockára nő. Nem is beszélve a négyutas kiépítésekről, ahol már 10 képkocka késéssel kell számolni. Utóbbi érték már tényleg sok, így maximum két, AFR módban működő GPU beépítését javasoljuk a felhasználóknak. Persze ebből a szempontból ne írjuk le idő előtt a HyperFormance módot, inkább vizsgáljuk tovább, hogy mit is talált ki a LucidLogix!
A fenti ábrán látható törések rendszerint akkor keletkeznek, ha a GPU gyorsabban számolja a tartalmat, mint ahogy azt a monitor meg tudja jeleníteni. A képen látható, hogy tulajdonképpen három képkocka részletéből lett egy, és alapvetően rögtön adódik a kérdés, hogy a legfelső részt minek is számolta ki a rendszer. Tulajdonképpen a teljes képkocka számítása elhagyható lett volna, hiszen a kép úgyis megtörik, így újra lehetett volna hasznosítani az előző képkocka felső részét. A HyperFormance mód lényegében így működik. Egyszerűen a rendszer még a rajzolási parancsok kiadása előtt eldönti, hogy szükség van-e arra a képkockára, aminek a számítása megkezdődne. Ezt a szoftver kiértékeli, és vagy eldobja a jelenetet, vagy engedélyezi annak továbbadását a GPU-nak, amiből természetesen egy új képkocka születik. Ez önmagában nem hangzik túl jól, hiszen csak a GPU-t mentettük meg némi munkától, de a monitoron megjelenő kép ettől még megtörik.
Az tehát látható, hogy hol lehet sebességet nyerni, de az egész nem ér semmit, ha a kép folyamatosan szétesik. A hagyományos vertikális szinkron alkalmazása lehetetlen, hiszen az már önmagában szinkronizálja a feldolgozást, ami a LucidLogix számára nem jó. Itt jön képbe a Virtual Vsync technológia.
A Virtu csak olyan konfiguráción működik, ahol a VGA mellett ott van a processzorban egy IGP. Az biztos, hogy erre lesz rácsatlakoztatva a kijelző, vagyis aktívan lehetne használni ezt az egységet. Itt szó sincs a számítások megosztásáról, csupán az történik, hogy a LucidLogix kontrollálja a monitorra kiküldött képkockákat. A lényeg annyi, hogy a dedikált GPU dolgozik a számításokon, majd a végső képkocka mindig átkerül az IGP által lefoglalt memóriaterületre. Itt dolgozik a Virtu drivere, és csak azokat a képkockákat küldi ki a monitorra, melyek úgymond teljesek, vagyis a képtörés lehetősége kizárt. Ez természetesen igényel némi kommunikációt az IGP és a GPU között, illetve a rendszermemóriából is használ fel területet, de utóbbiból úgyis hozzá van rendelve egy fix partíció az IGP-hez, így probléma nélkül lehet hasznosítani.
A technológiák eredménye tulajdonképpen viszonylag sok képkocka másodpercenként, mindezt képtörés nélkül a vertikális szinkron mellőzésével. Azt talán mondanunk sem kell, hogy egy 60 Hz-en üzemelő monitor semmiképp sem tud 60 képkockánál többet kirakni, így nagyobb sebesség lényegében csak alacsonyabb input lagot eredményez. Például ha a rendszer képes 120 képkocka kiszámítására másodpercenként, akkor az eszközön kiadott parancs és a megjelenített kép között 20 ms telik el. Az előző oldalon erről már kifejtettük a véleményünket. Jó dolog az alacsony input lag, de egy bizonyos érték alatt az ember számára nem igazán érzékelhető. A vertikális szinkronnal megtámogatott 60 Hz-es megjelenítés mellett már bőven jó az élmény, de ha bárki igényli az alacsonyabb értékeket, akkor természetesen a Virtual Vsync megfelelő alternatíva erre.
Innentől már csak egy kérdés maradt. Tényleg gyorsít a HyperFormance mód? Ezt megválaszolni nem olyan egyszerű. Az egésznek megvan az elméleti alapja, ami a gyakorlatban is működhet, sőt meggyőződésünk, hogy működik is. A kérdés tehát mégsem az, hogy gyorsít-e, hanem sokkal inkább az, hogy mikor? Tegyük fel, hogy egy adott rendszer alkalmazza a HyperFormance módot (szokás szerint a kötelezően aktív Virtual Vsync mellett). Ha a géphez egy 60 Hz-en működő monitor csatlakozik, és a gép nem képes magából másodpercenként 60-nál több képkockát kipréselni, akkor a HyperFormance konkrétan nem ér semmit, mert minden számítás értékes, vagyis nem lehet spórolni. Ha a teljesítmény jóval több 60 képkocka/másodpercnél, akkor már más a helyzet. Ilyenkor nagy esély van az egyes számítások kihagyására, és így a HyperFormance nyilván gyorsít.
[+]
Az előző bekezdés arra is válasz, hogy a LucidLogix miért mérte a rendszer működését olyan körülményekhez, ahol a VGA segítség nélkül is kiköhögte magából a 150-300 képkockát másodpercenként. A HyperFormance tehát csak akkor előny, amikor a gép teljesítménye már eleve az egekben van, így a technológia pont olyan helyzetben nem gyorsít, ahol a legnagyobb szükség lenne rá.
Hogy mindennek mennyire van értelme, mindenki döntse el maga. A mi véleményünk szerint a Virtu driver új technológiái inkább akkor hasznosak, ha az input lag csökkentése a cél.
XLR8, azaz HyperFormance mobilon?
A Virtual Vsync és a HyperFormance mód működését alapvetően azért elemeztük részletesen, mert a vállalat bejelentette az XLR8 nevű szoftvert, ami lényegében ugyanezt valósítja meg, csak mobil szinten. Itt nincs segítsége a rendszernek egy IGP személyében, hiszen csupán egy integrált grafikus vezérlő lesz azokban a termékekben, amelyeket a fejlesztés megcéloz. Ez persze alapvetően nem gond, mivel a Virtual Vsync és a HyperFormance módhoz sem szükséges egy extra grafikus mag, csupán ha már ott van, akkor érdemes hasznosítani. Az alkalmazást a gyártók igényelhetik, így egy adott tablethez, okostelefonhoz, netbookhoz vagy notebookhoz, illetve LCD-PC-hez kötött szolgáltatásról lesz szó.
A LucidLogix támogatni fogja az AMD Fusion és az Intel Ivy Bridge APU-kat, valamint az ARM MALI IGP-ket, illetve az NVIDIA Tegra lapkákat. Az anyagiakról a vállalat a termék gyártójával egyezik meg, így a felhasználónak az adott masina kifizetése után joga van használni az XLR8 nevű szoftvert. Természetesen ez távolról sem kötelező, így akár aktiválni sem kell a működést.
Az XLR8-ról a LucidLogix hasonló rébuszokban beszél, mint a HyperFormance módról, így a fentiek alapján lehet sejteni, hol érhető majd el a gyártó által előzetesen megadott, 200%-os gyorsulás. Az XLR8-nak azonban mégis több értelme van. Egy mobil termék esetében a fogyasztás igen fontos kritérium, és azzal, hogy a rendszer nem számol felesleges képkockákat, energiát takarít meg. Természetesen, ha eleve nem fut valami fényesen a program, akkor nincs mit eldobni a leendő számítások közül, de sok alkalmazás esetében bizony lehet spórolni. Csodára persze nem érdemes számítani, de szokás szerint alacsony input lagra igen, illetve programtól függően tényleg csökkenhet – ha csak csekély mértékben is – az eszközök fogyasztása.
A LucidLogix újításai között még feltűnik egy VGWare nevű szoftver, ami lényegében az otthoni felhőt valósítja meg. Az alkalmazás két részből áll. Az adott környezeten belül lesz egy szerverként üzemelő számítógép, mely a tényleges számításokat fogja elvégezni a VGWare alkalmazáson keresztül. A vállalat itt aránylag erős masinát ajánl a jó játékélmény és sebesség érdekében. Ezzel kapcsolatban konkrét követelmény, hogy az adott PC-ben Radeon vagy GeForce legyen, akár IGP, akár dedikált GPU formájában. Az Intel IGP-it egyelőre a rendszer nem támogatja, de ez később még változhat.
A VGWare programot futtató kliensgépek a fő masinához vezetékes vagy vezeték nélküli hálózaton keresztül csatlakozhatnak, és így lényegében létrejön egy otthoni számítási felhő, mindez internethozzáférés nélkül. Hasonló elgondolást mutatott be az NVIDIA nemrég, ám a Splashtop THD a szervergépben GeForce VGA-t követel, míg a kliensnek kötelező Tegra 3-as táblagépnek lennie. A VGWare természetesen kliensoldalon bármit elfogad, csupán a szoftver telepíthetősége a követelmény.
A működés alapvetően ismert. A kiszolgáló és a kliens között ki kell alakítani a hálózatot, majd azon keresztül a kliensgép elküldi a beviteli adatokat a PC-nek. Utóbbi kiszámolja a képkockát, amit a hálózaton keresztül visszaküld a kliensnek. A minőség szempontjából némi kompromisszum szokás szerint lesz, mivel igazodni kell a hálózatok sebességéhez, és a képkockák tömörítése elengedhetetlen; emellett az input lagot is növeli a távoli kapcsolat, de közel sem olyan mértékben, ahogy azt az interneten keresztül elérhető OnLive vagy Gaikai teszi, vagyis a rendszer vállalhatónak tűnik.
Talán nem is a tabletek és okostelefonok esetében lesz a VGWare-nek értelme, hanem az otthonokban található többi PC-n. Akár egy alacsony fogyasztású HTPC-n is lehet játszani, mivel a kiszolgáló mindent kiszámol az apró masina helyett. Sőt, nem csak egy kliensgép kezelése lehetséges, hanem technikailag akármennyié. A fő számításokat végző PC teljesítménye persze véges, de elméletben a szoftver nem korlátozza a csatlakozó kliensek számát. Szintén érdekesség, hogy ha a szervergépben több grafikus vezérlő van, akkor azt a VGWare ki tudja használni, illetve megoldható, hogy a csatlakozó kliensekhez külön GPU-t rendeljen a szoftver.
A VGWare megjelenéséről egyelőre nincs információnk, de valószínűleg hamarosan debütál a szoftver. Sajnos úgy néz ki, hogy fizetős lesz az alkalmazás, és ebben az esetben a költségek közvetlenül a vásárlók pénztárcáját terhelik.
A LucidLogix láthatóan érdekes fejlesztésekkel operál. Túlzás lenne mindre azt mondani, hogy gyakorlati értelemben is hasznos elgondolás, de talán mindegyiknek lesz valamekkora piaca. Gyakorlati tapasztalattal sajnos nem tudunk szolgálni, de remélhetőleg ennek is eljön az ideje. Az XLR8 és a VGWare mindenképpen megérhet egy-egy tesztet.
Abu85