» »

Čudežno popotovanje skozi grafični cevovod II

V prvem delu smo si ogledali strukturo sodobne grafične kartice. Med drugim smo omenili shaderje, ki so zaradi svoje programabilnosti, nekakšno srce in duša sodobnih GPU-jev. Različni shaderji so odgovorni za različne strukture v grafiki (v Direct3D 10 so to oglišča, trikotniki in pike) in omogočajo programerjem, da na teh točkah cevovoda izvajajo komplicirane izračune, katerih končni rezultat je v relnem času generirana slika nekega virtualnega okolja na zaslonu. Tudi predstava, da so shaderji tukaj šele od predstavitve DirectX 8 (novembra 2000), ne bo držala. Shaderji so z nami že vse od začetkov 3D pospeševalnikov, samo o kakšni resni programabilnosti ni bilo ne duha ne sluha. Kot ste verjetno že ugotovili, se je zopet vse začelo z Voodoo Graphics...


Čarovnije v ROP enotah

Torej, domov ste prinesli pisano svetlečo škatlo v kateri se bohoti Voodoo Graphics ali celo Voodoo 2 in na škatli vam piše nekaj o 45 milijonih tekslov ali v primeru Voodoo 2 kar 180 milijonov tekslov. Zakaj potrebujemo več tekslov, kot bomo izrisali pikslov? Če se za začetek malo oddaljimo in najprej pogledamo kaj nam prikazuje monitor, ugotovimo, da je slika na njem sestavljena iz majhnih pik (pixel), ki so sestavljene iz treh še manjših pik (sub pixel). Vsaka od teh treh majhnih pik lahko sveti v samo eni barvi: rdeče, zeleno ali modro. Tako pridemo do RGB trojice (red, green, blue) in ker so vse tri barve zelo tesno skupaj jih oko zazna kot eno samo piko. Tri definitivno ni preveč računalniško število, zato srečujemo še četrto komponento (zelo posebno) običajno imenovano alpha. Skupaj torej štiri števila in kratica ARGB, oziroma matematično gledano 3D ali 4D vektor. Vektorje lahko seštevamo, odštevamo, množimo po komponentah, računamo skalarni in vektorski produkt... Vendar vseh teh operacij ne znajo izvajati kar vse grafične kartice. Še več, tudi današnji GPU-ji lahko v ROP enoti samo seštevajo (odštevajo) in množijo po komponentah.

Struktura ROP enote, dva množilnika in ena splošnejša enota

Primer uporabe ROP enot: če renderiramo hišo, potem moramo izrisati tudi okna, ki seveda niso povsem nevidna. Tega se lotimo tako, da najprej izrišemo hišo brez oken, potem ves teren okrog hiše in potem še oblačke na nebu, šele na koncu se lotimo izrisa prosojnih oken. Na tem koraku moramo predvsem dopovedati ROP enoti, da naj prebere piko nazaj v grafični čip. To piko (ARGB vektor) moramo sedaj nekako sestaviti skupaj s piko, ki nam jo je dostavila TMU enota (še en ARGB vektor). Dober način kako to naredimo je, da vzamemo alpha vrednost pike iz TMU enote in jo pomnožimo z barvo te iste pike. Na to vzamemo isto alpha vrednost in jo odštejemo od ena, rezultat tega pa spet množimo, tokrat z barvo ozadja, ki jo je ROP prebral nazaj. Sedaj obe izračunani vrednosti še seštejemo in rezultat zapišemo nazaj v pomnilnik. Tako, pa imamo svoj prvi shader za polprosojna okna. Če se nam zahoče lahko na njih naredimo tudi kakšno packo, s tem da postavimo alpha vrednost na teksturi na 1.


Več teksturna skladovnica

Takšno senčenje je v nekaterih primerih nujno potrebno (ravno omenjeni primer polprosojnosti je tak), običajno pa se mu je najbolje izogniti. Čim več dela je dobro opraviti znotraj čipa, in se s tem izogniti nepotrebnemu branju pik nazaj v GPU, ko so enkrat že bile izrisane. To nam omogočajo TMU enote (Texture Mapping Unit), ki poleg brskanja za teksli v teksturah znajo tudi računati. TMU tako lahko teksturo množi recimo z barvo luči na ogliščih trikotnika. Lahko tudi povežemo več TMU enot v vrsto in s tem dosežemo, da lahko čip izvaja "pixel shaderje", ki dostopajo do dveh različnih tekstur. To je ideja, ki je gonila razvoj vse to DirectX 9, oziroma prvih pravih pixel shaderjev (ne, pixel shaderji 1.1 v DX8 so malce preveč enostavni). Sedaj imamo na razpolago nekakšno več teksturno skladovnico (multitexture cascade), ki je sestavljena iz ene ali več stopenj. Vsaka stopnja dostopa do ene teksture in ima eno TMU enoto.

Struktura TMU, poleg same teksturirne enote imamo še splošno ALU enoto (trije parametri seveda le pri ustreznih operacijah)

Grafični čipi so tako imeli različne kombinacije TMU enot, ki so zmogle različne računske operacije. Voodoo Graphics je imel eno ROP enoto in eno TMU enoto, Voodoo 2 je temu dodal še eno TMU enoto, ki je bila vezana na obstoječi TMU. Riva TNT je imela dve ROP enoti in dve TMU enoti, kar predstavlja problem, saj tak čip načeloma ni sposoben na objekt lepiti dveh tekstur hkrati. Rešitev se imenuje "loopback" in kot že ime pove, v bistvu pripeljemo retultat TMU enote nazaj na njen vhod (in ker imamo precej strog cevovod lahko to naredimo samo enkrat). TMU pa v naslednjem ciklu obdela drugo teksturo. Namesto enega cikla na Voodoo 2, Riva TNT potrebuje dva cikla, vendar hkrati dela na dveh pikah. Kmalu se je inžinirjem tudi posvetilo, da bi lahko rezultat iz prve TMU enote uporabili za popravek teksturirnih koordinat pri vzorčenju drugege TMU enote. To Matroxovim G400 karticam prvim omogoči EMBM (Environment Mapped Bump Mapping). NVIDIA z GeForce 256 vrne udarec in poleg EMBM ponudi še t.i. Dot-Product Bump Mapping (dodajo skalarni produkt med operacije TMU enot), vendar s tem niso bili prvi, saj jih je že prehitel PowerVR Kyro. Matrox pa v navalu besa izda Parhelio, ki ima za vsako od šritih ROP enot še 4 TMU enote. Rezultat? Dolg cevovod, ki se obnaša enako hitro (počasno), pa če igra uporablja eno samo teskturo ali pa 4 teksture kombinirane z EMBM. Sedaj se v igro pošteno vmeša še ATI in z Radeon 8500 naznani, da se bližajo spremembe...

Skladovnica tekstur s kakršno so prve pospešene igre dosegale grafične učinke

Tipično razmišljanje pri tem gre običajno nekako tako: "vzemi prvo teksturo in z njo naredi nekaj, nato vzemi drugo teksturo in z vsem skupaj naredi nekaj,..." Skratka zares tipična skladovnica (tekstur). Tipičen primer uporabe je postopek imenovan light mapping, ki smo ga srečevali praktično v vseh igrah. Glavno opažanje je, da je pač osvetlitev zelo pomemben dejavnik za dosego realizma. Sicer že vse od prvih 3D pospeševalnikov lahko izračunavamo osvetlitev na ogliščih trikotnikov (seveda na CPU), vendar so bili trikotniki takrat še zelo veliki in bi tako za vsako sliko (recimo okrog 480000 pik) opravili recimo le nekaj 10 izračunov osvetlitve. Kaj ko bi lahko za vsako izrisano piko v igri izračunali unikatno osvetlitev? Tega očitno še ne moremo početi na grafični kartici, torej moramo to od nekje uvoziti. Če se omejimo na statične luči (nič ugašanja in premikanja luči) in statično okolje lahko za celotno sceno izračunamo zelo natančne podatke o osvetlitvi. Te podatke se nato shrani v teksture imenovane svetlobne mape (light maps) in zapeče na CD skupaj z igro. Grafična kartica potem za vsako piko prebere prvo teksturo, jo množi s svetlobno mapo in "hip hip, strašni trik", tako je izrisanih 95% vseh pik v starejših igrah (za ostalih 5% se osvetlitev izračuna na ogliščih trikotnikov ali kakšnimi drugimi triki).

Naslednji bum na tem področju je bil bump mapping. Brez prepiranja kaj je boljše EMBM ali dot3, prvi je večja goljufija kot drugi (predvsem pa v bistvu nista primerljiva). Če ste v šolah že slišali kaj o vektorjih potem veste, da ima skalarni produkt (dot product) nekaj opraviti s kosinusi kota med dvema vektorjema. Nemškemu matematiku Johannu Heinrichu Lambertu pa se je že okrog leta 1760 posvetilo, da je pri nesvetlečih telesih količina odbite svetlobe v bistvu kosinus kota med smerjo iz katere prihajajo žarki in normalo površine. Normale trikotnika ni problem izračunati (v bistvu je običajno že podana za vsako oglišče), prav tako ni tako velik problem ugotoviti iz katere smeri padajo žarki na trenutno renderirano piko. Sedaj samo še zagotovimo, da sta oba vektorja dolžine 1, izračunamo skalarni produkt in že vemo kakšna je difuzna osvetlitev pike. Naslednji korak je da dodamo še direktno komponento osvetlitve (specular highlights), kar običajno naredimo tako kot predlaga Blinn-Phongov model. Dodatni podatek, ki ga potrebujemo je položaj opazovalca, torej vektor od očesa do trenutno renderirane pike. Prištejemo zraven še smer iz katere prihajajo žarki in vektor normaliziramo (torej zagotovimo, da bo dolžine 1). Še en skalarni produkt z normalo, malo potenciranja rezultata in dobimo direktno komponento. Sedaj pa v bistvu lahko normale zapakiramo v teksturo. Tako imamo lahko za vsako piko svojo normalo in s tem simuliramo vdolbine v materialu (od tod bumpmapping). Ta postopek je dejansko malce kompliciran in je v celoti in brez dodatnih trikov mogoče pravilno izvesti šele na GPU-jih, ki podpirajo pixel shaderje 2.0. Za starejše kartice pa moramo algoritem poenostaviti, skratka tu ni več zgolj lepljenje večih tekstur na objekt, ampak imamo zraven precej matematike. Zopet znak, da se bližajo spremembe...

Ob tem je verjetno pametno omeniti tudi to, da kljub svoji kompliciranosti takšno računanje osvetlitve za vsako piko običajno ne da tako dobrih rezultatov kot light mapping. Za light mapping lahko uporabimo še bolj komplicirane algoritme (sledenje žarkom ali radiosity), ima pa bump mapping eno veliko prednost: dinamičnost. Luči namreč lahko prižigamo in ugašamo, ter jih premikamo.


Trikotniki in še več trikotnikov

Vsi objekti v igrah so sestavljeni iz trikotnikov, ki so najenostavnejši trodimenzionalni objekti. Tri oglišča trikotnika definirajo tudi ravnino v 3D prostoru, če pri katerem izmed trikotnikov dve ali kar vsa tri oglišča sovpadajo imamo opravka z t.i. degeneriranimi trikotniki, ki jih mora grafična kartica kar se da hitro prepoznati in zavreči (saj so brez površine in k končni sliki ne prinesejo nič). Več trikotnikov kot si jih izdelovalci iger lahko privoščijo za posamezen objekt, bolj natančen in prepričljiv je objekt. Glavna naloga v tej fazi je transformiranje oglišč iz 3D prostora v 2D prostor na zaslonu. S pomočjo teh transformacij lahko objekte rotiramo, premikamo, povečujemo in zmanjšujemo, določajo pa tudi kje se nahaja kamera (opazovalec), ter ostale lastnosti kamere (npr. vidni kot). Vsak objekt ima načeloma svojo transformacijo. Lahko jih ima celo več, če gre za animiran objekt, kot so recimo karakterji v igrah. Torej bi bila gotovo dobra ideja, če bi grafične kartice lahko pospeševale tudi obdelavo trikotnikov...

To se je tudi zgodilo, NVIDIA je v GeForce 256 vgradila posebno enoto namenjeno premlevanju trikotnikov, oziroma bolj natančno oglišč trikotnikov. Zadevo so poimenovali strojno pospeševanje transformacij in senčenja (hardware transformation and lighting), kar v bistvu pove precej o funkcionalnosti. Ta generacija grafičnih kartic (v katero spadajo še originalni Radeon, kasneje preimenovan v Radeon 7500, GeForce 2, GeForce 2 MX in GeForce 4 MX) je bila sposobna pospeševati transformacije oglišč in izračunati osvetlitev iz do 8 različnih svetlobih virov za ta ista oglišča. To pošteno omeji uporabnost, saj je večina iger tisti čas uporabljala light mapping in posledično niso potrebovale kaj dosti izračunov osvetlitve na ogliščih. Naslednja težava je bila, da te enote niso bile kaj dosti programabilne in posledično neuporabne za dot product bump mapping, ki se je začel pojavljati na teh istih GPU-jih. Obstajal pa je še en problem bolj programske narave. Direct3D 7 je imel za te kartice ločen način delovanja t.i. T&L HAL in tako so se pojavile težave s tem kam postaviti oglišča: na kartico (praktično neuporabno za branje s strani CPU), AGP pomnilnik (sicer primeren kos pomnilnika, ki pa je imel velik kup težav z gonilniki in operacijskim sistemom) ali kar običajen RAM (in tukaj lahko o kakšnem strojnem pospeševanju samo sanjamo). Do prihoda DirectX 8.0 je bila večina teh težav že odpravljena, vendar so takrat bile aktualne že druge stvari.

Primer modela, vsako oglišče trikotnika je potrebno preslikati iz 3D prostora v 2D prostor, za kar skrbi T&L enota in kasneje vertex shaderji


Dobrodošli v programabilno dobo, kako želite servirati vaše trikotnike?

Tako počasi pridemo do čisto pravih shaderjev in programabilnih enot znotraj GPU in namesto nastavljanja posameznih parametrov lahko sedaj napišemo programe, ki jih bo GPU izvajal na posameznih stopnjah cevovoda. Vertex shaderji nadomestijo strojno pospeševanje transformacij in senčenja, pixel shaderji zamenjajo več teksturno skladovnico, v DirectX 10 pa se pojavijo še geometry shaderji, ki v bistvu nimajo predhodnika. Še vedno pa obstajajo različne verzije shaderjev, ki se med seboj precej razlikujejo v zmogljivostih. Kaj je cilj vsega tega? Ponuditi večjo fleksibilnost in boljšo izkoriščenost strojne opreme. Spremembe vertex shaderjev so bile običajno precej manjše kot spremembe pixel shaderjev.

Normale in tangente posto potrebujemo pri senčenju. Binormalo lahko izračunamo sami v vertex shaderju ali pa je podana z vsakim ogliščem.

Vertex shaderji so običajno zadolženi za pripravo podatkov pixel shaderjem. Na razpolago imamo 16 vhodnih registrov v katere se preslikajo podatki o ogljiščih. Sem spadajo položaj oglišča v prostoru, normala, tangenta, binormala, uteži za različne transformacije pri animaciji, barva oglišča, položaj oglišča na teksturi... Lahko pa so tudi kaj bolj abstraktnega, recimo kar podatki o transformaciji, če želimo izrisati več istih objektov na različnih položajih v 3D prostoru (t.i. instancing). Vertex shader mora izpljuniti vsaj koordinato oglišča na zaslonu, poleg tega pa je na razpolago še okrog 11 izhodnih registrov (tu je nekaj malega odvisnosti od verzije), v katere lahko po želji shranimo informacije za pixel shader. Tu pridejo na vrsto interpolatorji, ki s pomočjo podatkov na robu trikotnika preračunajo vrednosti izhodnih registrov še za vse pike na zaslonu, ki so znotraj trikotnika. In ker ti interpolatorji vedo tudi kako hitro se določena vrednost spreminja čez sosednje pike (spomnite se, delamo na 2x2 blokih) nam to omogoča uporabo anisotropičnega filtriranja tekstur. Sedaj so na vrsti pixel shaderji, ki so običajno bolj komplicirane narave. Pik je na zaslonu običajno več kot oglišč, obenem pa se pike dostikrat tudi prekrivajo. Od tod tudi dejstvo, da imajo grafične kartice vedno več pixel shader enot, kot vertex shader enot.

Če si sedaj pogledamo kako bi že omenjeni primer light mappinga napisali z shaderji:

// Vertex shader
dcl_position0 v0.xyzw   // V register V0 "naročimo" položaj oglišča 
dcl_texcoord0 v1.xy     // V1 naj vsebuje koordinato teksture 
dcl_texcoord1 v2.xy     // V2 pa še drugo koordinato teksture 
dcl_position0 o0.xyzw   // V izhodni register o0 bomo zapisali 
dcl_texcoord0 o1.xy     // položaj na zaslonu, v o1 in o2 pa 
dcl_texcoord1 o2.xy     // dve teksturirni koordinati 
 
dp4 o0.x, v0, c0        // Transformacija 
dp4 o0.y, v0, c1        // oglišča 
dp4 o0.z, v0, c2        // na 
dp4 o0.w, v0, c3        // zaslon 
 
mov o1.xy, v1.xy
mov o2.xy, v2.xy
 
// Pixel shader 
dcl_texcoord0 v0.xy     // Napovemo uporabo obeh koordinat 
dcl_texcoord1 v1.xy     // za teksturi. 
 
dcl_2d s0               // Napovemo prvo teksturo 
dcl_2d s1               // in še drugo teksturo. 
 
texld r0, v0, s0
texld r1, v1, s1
mul oC0, r0, r1
 

Hura!! Uspelo nam je zlorabiti najsodobnejšo grafično kartico za nekaj, kar zmore že Voodoo 2. Ukaze v shaderjih lahko ločimo nekako v tri skupine: administrativni (dcl_...), ukazi za dostop do tekstur (texld,...), računski ukazi (dp4, dp3, mul, mov,...). Naš pixel shader ima dva ukaza za teksturiranje in samo en računski ukaz, torej razmerje 2:1. Glede na to, da ima Radeon X1900 optimalno razmerje 1:3 je verjetno že malce bolj jasno kaj so te spremembe, ki jih pixel shaderji prinašajo. Teksturiranje je drag šport, požira nam spominsko propustnost, ki je ne moremo tako enostavno povečati. Naslednja težava je vezava TMU enot z ALU računskimi enotami, če bi hoteli vzdrževati 1:1 razmerje iz časov Voodoo 2, bi porabljali veliko tranzistorjev za TMU enote, ki bi večino časa stradale za podatki ali pa jih sploh ne bi potrebovali. Tako se je začel proces ločevanja teksturirnih enot od računskih enot, ki je dosegel višek z Radeon X1800 in GeForce 8800, kjer sta ti dve vrsti enoti povsem ločeni.

Brez pretiranega ubadanja s samo kodo lahko ugotovimo, da bi bil shader za bump mapping, oziroma računanje osvetlitve za vsak piksel, bistveno bolj kompliciran. Še vedno pa bi uporabljal le dve teksturi in je tako bistveno bolj prijazen do sodobnih GPU-jev. Tako je implementirano preračunavanje osvetlitve v Doom 3, Quake 4 in še marsikateri sodobnejši igri. Ima pa kot že omenjeno en problem: ne moremo ga uporabljati na grafikuljah, ki podpirajo zgolj pixel shaderje prve generacije ali pa še to ne. V pixel shaderjih 1.x nimamo ukaza, ki nam bi omogočal deljenje, kar posledično pomeni, da ne moremo normalizirati vektorjev. Kako torej rešiti situacijo? Če kar pozabimo na to, bodo pike znotraj trikotnikov pretemne. Rešitev je trik z majhno cube mapo (6 tekstur na ploskvah kocke), v katero zapišemo vektorje dolžine 1 in neglede na to kako dolg ali kratek vektor podamo za koordinato v to teksturo, vedno bomo dobili normaliziran vektor nazaj, če se le smer ne razlikuje. S tem trikom naredimo še nekaj drugega. Namesto dveh tekstur sedaj potrebujemo 4, prihranimo pa nekaj na številu računskih operacij (in izgubimo nekaj na kvaliteti), kar tudi bolj ustreza grafičnim karticam nivoja GeForce 3.

Če je eden izmed vektorjev pri računanju osvetlitve krajši od 1 nastane napaka: sredina trikotnika bi morala biti najbolj osvetljena, praktično pa je v temi.

Tu pa se začne razsikovanje kaj se obnese na določenih grafičnih karticah in kaj ne. Na osnovi opisanega algoritma se lahko igramo tudi z HDR efekti, vse kar moramo dodati je možnost spreminjanja moči luči (in cel kup post processing efektov, da lahko sliko sploh prikažemo na zaslonu), tako da je ta lahko praktično poljubna in ne več omejena med 0 in 1. Kar pa nam vse skupaj precej zakomplicira. Da lahko sploh uporabljamo večja števila potrebujemo vsaj pixel shaderje 2.0 (Radeon 9700 PRO) in na srečo so bili proizvajalci strojne opreme dovolj pametni, da že prve DirectX 9 grafične kartice lahko tudi izpisujejo pike v večji natančnosti (floating point), žal pa je na teh karticah ob tem precej stvari odpovedalo (če že pozabimo vsesplošne komplikacije z GeForce FX serijo). Odpovedati se moramo mehčanju robov, kar pa še ni najbolj zoperna stvar, odpovedati se moramo tudi vsem "čarovnijam" v ROP enotah! Če hočemo vse skupaj izvesti približno enostavno, potrebujemo GeForce 6, če hočemo še mehčanje robov potrebujemo Radeon X1800, če pa hočemo pretiravati z natančnostjo in FSAA nastavitvami pa je odgovor samo GeForce 8. Vse skupaj zopet kliče po nečem svežem...

HDR efekti potrebujejo kompleksen sistem obdelave po končanem izrisu


DirectX 10 bum bum bang bang

Vsepovsod smo že slišali kakšna revolucija bo DirectX 10 (Direct3D 10, vse ostale komponente DirectX so ostale takšne kot so), po internetu videvamo razne slike, kako naj bi igre izgledale v DirectX 10... Ker se tokrat ukvarjamo s shaderji, naj kar takoj omenim bistveno prednost s stališča programerjev: DirectX 10 ni več premikajoča tarča! V DirectX 9 smo imeli v bistvu tri verzije shaderjev: 2.0, 2.x in 3.0, kar je povzdročilo določeno zmedo. Direct3D 10 bo glede vsega tega precej bolj strog, obstajala bo samo ena verzija shaderjev (paket Shader Model 4.0), obenem bo nov API na voljo samo v operacijskem sistemu Vista. Predvsem pa v D3D 10 ne bo narazpolago nobene emulacije za nazaj! DirectX 9 igram še vedno omogoča uporabo recimo pixel shaderjev 1.1, ki so sicer del DirectX 8, omogoča celo uporabo t.i. fixed function pipeline (običajno več teksturiranje iz začetka članka), ki ga sicer GPU-ji že lep čas emulirajo s shaderji, vendar je še vedno na razpolago v D3D9 knjižnici. DirectX 10 pa vso to zastarelo kramo odreže. Igre bodo morale tudi za najenostavnejše učinke uporabljati shader model 4.0, obenem pa je uporaba jezika HLSL (HighLevel Shading Language) obvezna. Ob zadnjem stavku se bo cel kup igričarjev prijelo za glavo in izustilo nekaj v smislu: "Kaj!? Programerji bodo morali za čisto vse uporabiti kompleksne/počasne/zahtevne 4.0 shaderje!? Joj, spet nas čaka kakšna GeForce FX katastrofa... !$"#%$#& Microsoft!" Seveda nihče NVIDI-ji ali ATI-ju ne more preprečiti, da naredi "GeForce FX manever" z D3D 10 podporo, vendar si splača postaviti vprašanje, ali bi morda tako polomijo v D3D 10 lahko zavohali že sedaj? Pri prehodu iz DX8 na DX9 so pixel shaderji bistveno povečali natančnost izračunov (iz 8 bitnih izračunov preidemo na 24 bitne floating point izračune), GeForce FX je to sicer podpiral, ampak za ogromno ceno pri hitrosti. V tem pogledu je bila vsa funkcionalnost pixel shaderjev 2.0 praktično nova in njenih hib ni mogoče "zavohati" z uporabo zgolj DX8 pixel shaderjev. GPU-ji vedno poznajo samo eno verzijo shaderjev, v katero gonilnik prevede kar koli že pride s strani Direct3D. Če seveda to lahko naredi, če GPU ne podpira vseh funkcij znotraj danega shaderja je emulacija s pomočjo CPU praktično nemogoča. Pri prehodu iz DirectX 9 na DirectX 10 ni tako ostrega prehoda, čeprav je funkcionalnost mnogo mnogo večja. Problemi tako lahko nastanejo le pri stvareh, ki jih še nismo videli. To pa so praktično samo geometry shaderji in celoštevilska aritmetika. Hitrost vsega ostalega se odraža že v današnjih igrah.

DirectX 8.xDirectX 9.0XBox 360DirectX 10
Pixel shader:1.01.11.21.31.42.02.x3.0"3.5"4.0
Max teksturirnih ukazov4123232+64 do 512512 do 327684096 (deljeno z VS)Neomejeno
Max računskih ukazov81664
Max različnih tekstur461632 (deljeno z VS)128 (dostopno v VS in GS)
Začasnih registrov261212-3232644096
Max konstant832224512 (deljeno z VS)16 bank po 4096 (dostopno v VS in GS)
Natančnost za posamezno komponento8 bitvsaj 24 bit (plavajoča vejica), 16 bit minimum32 bit (plavajoča vejica)32 bit (plavajoča vejica)32 bit (plavajoča vejica)
Vejitve/StatičneStatične, dinamične opcijaStatične in dinamičneStatične in dinamičneStatične in dinamične
Celoštevilsko procesiranje///Da
Geometry shader:///4.0
Max izhodnih parametrov///1024
Max ukazov///Neomejeno
Max konstant///16 bank po 4096 (dostopno v PS in VS)
Vertex shader:1.01.12.02.x3.0"3.5"4.0
Max ukazov128256256 do 512512 do 327684096 (deljeno z PS)Neomejeno
Max različnih tekstur//432 (deljeno z PS)128 (dostopno v PS in GS)
Max konstantvsaj 96vsaj 256512 (deljen z PS)16 bank po 4096 (dostopno v PS in GS)
Vejitve/Statične in dinamičneStatične in dinamičneStatične in dinamične
Celoštevilsko procesiranje///Da

Ob specifikacijah DirectX 10 se kar sama ponuja možnost, da shader enote na GPU lahko poganjajo tako vertex shaderje kot pixel shaderje (in seveda geometry shaderje). Že znotraj posamezne slike lahko GPU naleti na situacijo, ko je kakšen del cevovoda skoraj neizkoriščen, že nekaj trikotnikov kasneje pa se situacija povsem obrne. GPU-ji, ki imajo združene (unified) shader enote, so tako bistveno bolj učinkoviti, saj lahko GPU posamezne shader enote dodeljuje različnim nalogam glede na potrebe. Da niti ne omenjamo more, ki bi nastala z vpeljavo geometry shaderjev brez združene arhitekture... Koliko enot naj grafični arhitekti namenijo geometry shaderjem? To je povsem nova komponenta cevovoda, za katero se samo predvideva kako jo bodo programerji uporabili. Naslednja prednost SM 4.0 so skupna sredstva kot so banke s konstantami in teksture. Iz vseh treh stopenj (Vertex shader, Geometry shader in Pixel shader) tako lahko dostopamo do istih podatkov, nič več ločenega nastavljanja za vsako stopnjo posebej. Pogosto se namreč zgodi da potrebujemo iste vrednosti tako v vertex shaderju kot pixel shaderju. Vse skupaj strmi za čimvečjo izkoriščenostjo in rezultat tega je viden že danes z GeForce serije 8. Za kakšno drastične grafične izboljšave pa bo potrebno ponovno odkrivat toplo vodo... Tokrat se bo potrebno ozreti proti Rendermanu in Pixarju, ter ugotoviti kaj teče dovolj hitro. Algoritmi, ki v realnem času računajo indirektno osvetlitev so zaželjeni...

Čudežno popotovanje skozi grafični cevovod

Čudežno popotovanje skozi grafični cevovod

Trenutno očitno živimo v obdobju, ko razni *PU-ji (Processing Unit) rastejo kot gobe po dežju. Nedolgo tega je tržne police ugledal prvi pospeševalnik fizikalnih izračunov (PPU ali Physic Processing Unit) PhysX podjetja Ageia. In ker to očitno še vedno ni dovolj, ...

Preberi cel članek »

DirectX 9.0 - Osvetljevanje

DirectX 9.0 - Osvetljevanje

Tokrat si bomo ogledali eno izmed možnosti osvetljevanja v knjižnici DirectX 9.0. Ker tudi DirectX 9.0 še vedno pozna le osnovne osvetlitvene modele (flat in Gouraud), kljub temu da je strojna oprema že precej časa zmožna tudi česa več, si bomo pomagali s pixel ...

Preberi cel članek »

Novosti DirectXa 9 - 1. del

Novosti DirectXa 9 - 1. del

No pa smo vendarle dočakali novo, dolgo pričakovano, različico knjižnice DirectX, ki jo je zlobni Microsoft, bolj ali manj skrbno skrival pred radovednimi očmi javnosti. V približno enaki tajnosti sta nastala tudi ta dva članka, ki vam bosta, vsaj upam tako, uspela ...

Preberi cel članek »

ATI Radeon 9700 - Nov kralj v grafični deželi

ATI Radeon 9700 - Nov kralj v grafični deželi

Če ne živite ravno v kakšnem zakotnem pragozdu ter lahko berete ta članek, potem ste gotovo že slišali, da je ATi izdal nov grafični čip R300, ki so ga poimenovali Radeon 9700. Kot verjetno že veste, novi Radeon s precejšjno lahkoto pomete z vso konkurenco ...

Preberi cel članek »

DirectX 9.0 - Izboljšave knjižnice

DirectX 9.0 - Izboljšave knjižnice

V prejšnjem delu smo si ogledali novosti in izboljšave, ki so doletele programabilnost grafičnih kartic, torej osenčevalnike točk ter oglišč. Seveda pa novi pixel in vertex shaderji niso edina novost v DirectX 9.0. Novosti je še kar nekaj, vendar je res, da je ...

Preberi cel članek »