A PC jelenleg egy gigantikus átalakulást él meg. Gyakorlatilag két éven belül a teljes iparág behozta azt a lemaradást, ami a hagyományos API-k lassú fejlődéséből keletkezett. Az idei GDC ebből a szempontból történelmi jelentőségű volt, hiszen megszületett az egységes jövő a DirectX 12 és a Vulkan API formálódásával.
A váltást és egyben a szabványosítást technikai szempontból minden érintett üdvözli. Brad Wardell, a Stardock elnök-vezérigazgatója szerint elfogadhatatlan volt, hogy a többmagos processzorok korában csakis egyetlen processzormag adhat parancsokat a grafikus vezérlőnek, és ezzel az érvvel mindenki egyetért. Persze vannak kisebb stúdiók, akik szerint kétségtelen ugyan az új API-k által kínált előny, de mégis problémás az újítások ömlesztett bevezetése, hiszen a Microsoft (DirectX 12) és a Khronos Group (Vulkan) gyakorlatilag egy év alatt lezavar gyakorlatilag öt-hat évnek megfelelő fejlesztést, ami nagyon kedvez a tehetős stúdióknak és kiadóknak.
A régi és az új modell hatása a processzorhasználatra [+]
A Vulkan előadásán a problémát a gyakorlatban is prezentálta Dan Baker, az Oxide Games motorprogramozója, és a fenti két képen látható, hogy mennyire működik az új modell.
Röviden összefoglalva az új API-k lehetővé teszik, hogy mostantól több processzormag is adhasson parancsokat a grafikus vezérlőnek, emellett bizonyos compute futószalagok a grafikus vezérlőn belül nem csak soros, hanem párhuzamos formában is futtathatók más compute vagy grafikai futószalagokkal. Mindemellett az új modellben az alkalmazás felel a hazárdok kezeléséért, a VRAM menedzsmentjéért, illetve az állapotszűrésért, és emiatt konkrétan eltűnik a grafikus meghajtó, amit a fejlesztők csak úgy jellemeznek, hogy eltűnik az a feketedoboz, amely véletlenszerűen elvette az erőforrást a program előle.
Egy csomó problémát tehát kipipáltunk, de közel sem az összeset. Azzal, hogy a fejlesztők nagyobb kontrollt kapnak a grafikus vezérlők felett felmerül a jobb programozhatóságra való igény. Ugyanakkor a DirectX 12 még mindig a HLSL nyelvet használja, lényegében komolyabb előrelépés nélkül, de a Vulkan API a SPIR-V-vel már tett egy lépést a hatékonyabb kódolás irányába, így a fejlesztők számára itt már nem csak a GLSL az egyetlen alternatíva.
A GDC-n azonban többször felmerült, hogy hosszabb távon komolyabb előrelépés kell. A jó hír, hogy egy darabig bőven jók azok a lehetőségek, amelyeket a Vulkan API biztosít a SPIR-V-vel. Rossz hír viszont, hogy a rekurzió, a kivételkezelés, a függvény pointerek, és a más fontosabb funkciók már most előkerültek, mint fejlesztői igény. Ezeket egyetlen aktuális grafikus API-val sem lehet lefedni, így az iparág a sok – ezúttal megérdemelt – mosolygás mellett hozzáláthat az újabb fejlesztésekhez.
Az egyik legnagyobb gond egyébként, hogy az új igényeket nem egyszerű egységesíteni. Több gyártó szerint a jövőben a kompatibilitást mindenképpen egy közösen támogatott virtuális utasításarchitektúra szintjén kellene kezelni és semmiképp sem felette. Ezzel lehetőség adódna a mostani grafikus API-k alapos továbbfejlesztésére, illetve a programozhatóság kiterjesztésére. Nyilván ez egy logikus lehetőség, hiszen a virtuális utasításarchitektúra a legalsó még egységesíthető szint. Persze bárhogy is alakul, azt mindenképp jó látni, hogy máris megkezdődtek az előkészületek a PC hosszabb távú jövőjének biztosítására.
