A PSO és shader-specializálási "probléma" a kezdetektől fogva megvolt, csak az implicit APIk esetében a driver gondoskodott az összerakásukról (a Draw és Dispatch API-hívások pillanatában meglevő állapotból), a szükséges fizikai (GPU bájtkódos) shadervariánsok fordítgatásáról, cache-eléséről, stb., tipikusan háttérszálon.
Az explicit APIkkal (DX12, Vulkan) az volt az említett "forradalmi" lépés, hogy mindezt már nem csinálja meg a driver, az egész feladatot odadobja a fejlesztőnek, aki cserébe akár több szálon is építhet command listeket, és akár kínlódhat a videómemória manuális lapozgatásával is (régen az is automatikus volt). Tyuhaj, végre nem csak egy CPU mag dolgozik egyetlen cmdlist-en, hanem többet is be lehet fogni, ha a rendering egymással párhuzamosítható részekre osztható, és a csúnya memórialapozás sem akasztgatja meg a folyamatot, szép sima konzolos játékélményt kapunk jó CPU-kihasználtsággal!
Illetve volt még egy "forradalmi" lépés: megjelentek a magasabb szintű (IL) shader kódok, amelyek GPU-s bájtkódra történő fordítása több időt vesz igénybe, mint a régi DXBC, amely olyan alacsonyszintű fogalmakkal dolgozik, mint pl. a regiszter. Ezt pont azért dobta a MS az újkeletű, modernebb DXIL kedvéért, mert pl. a GPU wave-műveletek leírására már nagyon nem volt alkalmas. Sőt, a MS tovább is ment, ha a driver támogatja a DXIL-t, akkor DX12-höz a DXBC-s shader kódot röptében DXIL-re konvertálja, és csak úgy adja oda a drivernek (dxilconv.dll).
A gyakorlatban explicit API-hoz vagy egy kiforrott engine-t vagy keretrendszert használ az ember, vagy inkább neki se álljon, mert egyrészt a pipeline-objektumok kezelését szinte biztos nem fogja olyan hatékonyan megoldani, mint egy driver a korábbi API-kkal, másrészt háttérszálon sem fogja mindezt olyan hatékonyan vagy egyáltalán kezelni, mint egy driver a korábbi API-kkal, tehát ha csak a korábbi lineárisan renderelő (egy cmdlist-es) cuccunkat írjuk át explicit API-ra, akkor még lassabb és xarabb is lesz.
Ja, a shaderek "elő"- és "utótagja" alatt valószínűleg az input/output signature-t érti a szerző, vagy esetleg a kódtörzs elején levő dcl_* (declare) pseudo-utasításokat, amelyek metainformációt adnak arról, hogy a kód milyen becsatolt erőforrásokat ér el (textúrák, konst bufferek, stb), milyen formában (pl. statikus, dinamikus indexelés), hány temporális regisztert használ, stb. Shader model 4.0 előtt ezek nagy része nem volt meg, akár assembly-ben is írhattál shadert, és a metaadatot (shader reflection) a drivernek (vagy esetleg az API frontendnek a driver számára) kb. magából a kódtörzsből kellett kibányásznia, ami egy plusz interpretációs menetet is jelenthetett (mint a kétmenetes assemblernél ).
Nem tudom, hogy ezeken az elő- és utótagokon mit kell a cikk szerint változtatni, mert kb. semmit. A szerző arra gondolhatott, hogy a konkrét GPU-s bájtkódot nemcsak maga az absztrakt shaderkód határozza meg, hanem a pipeline más állapotai is, ebből következően az FXC-vel vagy DXC-vel lefordított bájtkódok csak template-ek a driver számára, amiből aztán a PSO-k összerakásakor különböző verziók fordulnak. Egy példa erre: ha írsz egy SM2.0-s pixel shadert DX9-hez, de a pipeline-on az alpha testing vagy a pixelköd engedélyezve van, akkor azt modern hardveren jó eséllyel magába a shaderbe kell belefordítani, mert az már nem támogatja a régi "fixed function" jellegű dolgokat, mint a korabeli GPU-k, amikre az API-t kitalálták. Jó élmény volt ezekkel elszórakozni, rengeteg cache hatékony kezelését kívánja meg.
Egyébként nem tudom, mit csinálnak a mai játékok, mi a francot fordítgatnak olyan sokáig. Régen a sok shadervariáns elkerülése miatt írtak übershadereket, mindenféle feltételes elágazásokkal és paraméterezéssel. A mai GPU-khoz ez pont illene, hiszen arra mennek rá, hogy minél kevesebb Draw-hívással inkább a GPU-t dolgoztasd, úgyis sok feldolgozó pipeline-ja van. De über-shaderekhez miért kell ennyi fordítási idő?
Az Oblivion IV (DX9) pl. azzal kezdi, hogy induláskor legyárt az API-n kb. 300+ vertex/pixel shadert, amit aztán használni is fog, de ezek DXIL-re konvertálásából sem láttam semmi drasztikus perfromance-csökkenést, nemhogy percekig tartó fordítgatást.