» »

Nov članek: Čudežno popotovanje skozi grafični cevovod - 2. del

Nov članek: Čudežno popotovanje skozi grafični cevovod - 2. del

Slo-Tech - Naš Senitel je zopet vzel tipkovnico pod prste in nadaljeval začeto.

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...

Vabljeni k branju!

41 komentarjev

Pyr0Beast ::

Lep članek, ni kaj, edino tista 'tabelca' na koncu me moti.

*Huzzah*
Some nanoparticles are more equal than others

Good work: Any notion of sanity and critical thought is off-topic in this place

Kenpachi ::

Super člančič. Na eno tipkarsko bi opozoril -> "razsikovanje" pod sliko trikotnika s črno piko.


Drugače pa.... Sem dejansko sedaj v dilemi... Če bo res jeba z dx10, ker ne bo podpore za nazaj, potem ne vem več, kaj bi... Namreč nameraval sem si kupiti GF7900GTO, ampak ko zdaj gledam v tale članek (no, bolj v zadnji del članka), bolj se mi zdi to ultra butasta naložba. Torej bi bilo bolje počakat na srednji razred G80 (pač srednji zaradi little $$$ in my pocket :| ), kot pa kupit višji razred G71? Any advice would be very appreciated, thank you.
Zaraki Kenpachi.

Tr0n ::

Ce sedaj kupujes graficno, se ti brez pomisleka splaca samo nova generacija. Razne 7xxx so outdated.

Februar-marec bi naj prispele cenejse variante D3D10, tako da ni vec dalec ;)

Zgodovina sprememb…

  • spremenilo: Tr0n ()

Jernej L ::

Prvi dejansko uporabni shaderji z nekaj kontrole so prišli ven z opengl in nvidiini env_combine extension za opengl.

Drugače pa je avtor članka čisto ignoranten do opengl platforme, "directx to, directx ono"... na opengl pa čisto pozabi.

Zheegec ::

Mislim da se trenutno okoli DX10 dosti več dogaja, tako da je kar pravilno, da se vrti vse okoli tega (ja, MS je bed, to vemo).

Drugače je pa super, da je sploh kdo ki napiše takšen strokoven članek - we bow down to you!
"božja zapoved pravi; <Spoštuj očeta in mater>,
ne govori pa o spoštovanju sodstva."
Janez Janša, 29.04.2014

Tr0n ::

Katero gaming podjetje se sploh razvija native OpenGL igre? id Software, pa se ta se pocasi seli na DX.

GaS ::

Super clanek, ze prvega sem z veseljem prebral. Pohvale za trud!

Senitel ::

Delfi: texture_env_combine ni nič kaj posebnega, čisto isto kontrolo imaš v Direct3D z multitexture cascade, s to razliko da v D3D moraš točno vedet kakšen hardware imaš (v OpenGL-u pa veš za kater extension pišeš), ker sicer stvar ne bo delala.
Je pa tako, da je članek pač o grafičnih karticah in se žal ne moreš čist izogniti API-ju. Oziroma lahko poveš kaj G80 zmore ne omeniš pa da se to preslika skor direkt na DX10... Saj imam v mislih tudi en članek o API-jih... :D

miwche ::

senitel

preden oddaš kak tak članek - lektorirat! :)
Daj ga komu da ga preleti, pa je. Lahko tudi meni, za đabe, valda.
pa brez zamere...
~ there are more alpha males than beta testers ~

antonija ::

Zakon clanek! Dej naj kaksen znalec spise se potovanje skozi ostale komponente...
Statistically 3 out of 4 involved usually enjoy gang-bang experience.

Brane2 ::

Bi lahko kdo kaj več povedal o OpenGL, njegovih podobnostih inrazlikah glede na DirectX in prihodnosti ?
On the journey of life, I chose the psycho path.

Senitel ::

Ok, bo tretji del o API-jih... :)

Jernej L ::

Senitel: prosim da ne napišeš nobenega članka ki bi primerjal opengl in dx, ker že na daleč se vidi da o opengl nimaš pojma, in ne moreš spisati poštene primerjave. drugače pa nad opengl vsekakor niso temni oblaki, nasprotno, opengl|es se lahko komot primerja z DX10 in je bil dostopen že nekaj časa pred dx10, in sedaj je khronos group prevzel še navadni opengl / ARB. tako da če ste že odpisali opengl, ste to naredili zelo prezgodaj, opengl je tudi sedaj standard v linuxu, apple mac-ih, playstation-u 3, in še se širi.

Zgodovina sprememb…

  • spremenil: Jernej L ()

antonija ::

@Delfi: Jah, ce je tko pa dej prosim ti napisat kak clanek o tej temi...
Statistically 3 out of 4 involved usually enjoy gang-bang experience.

Senitel ::

Delfi: Se ti mal hecaš? Govoriš, da nimam pojma o OpenGL in greš primerjat OpenGL ES z DirectX 10? :\

Jernej L ::

Senitel: seveda, zakaj pa ne? v obeh primerih gre za okrnjeno različico izvorne knjižice (opengl -> opengl|es, dx9 -> dx10) z povdarkom na shaderjih in performansu..

Senitel ::

Ah... :\ OpenGL ES je namenjen embedded sistemom (OpenGL for Embedded Systems) in v osnovi obstajata dve različici: OpenGL ES 1.x, ki je nekoliko okleščena varianta OpenGL 1.5 in OpenGL ES 2.x, ki je nekoliko okleščena varianta OpenGL 2.0. Pri čemer ja, OpenGL ES 2.x ne podpira stvari za nazaj, kar je isto kar se je zgodilo v Direct3D 10.
Seveda pa je to, da je OpenGL ES 2.x prej odrezal podporo za nazaj kot Direct3D 10 tako pomembno dejstvo, da zasenči vsa ostala dejstva kot je recimo to, da OpenGL ES in Direct3D sploh nista primerljiva! Prvi je za embedded sisteme, drugi za PC.
Direct3D 10 se po funkcionalnosti primerja samo z OpenGL 2.1 + NV extension-i (ki niso standardni). OpenGL ekvivalenca Direct3D 10 bo z OpenGL Lean and Mean.

Come on... :\

BTW: Še vedno čakam na razlago kaj za boga naj bi bili "object shaderji". :\

Izi ::

obeh primerih gre za okrnjeno različico izvorne knjižice (opengl -> opengl|es, dx9 -> dx10)

To pa ne ne drži
OpenGL ES je res okrnjena različica, ki jo razvijajo vzporedno z Open GL in je pač namenjena za telefončke, konzole in podobno.
DX9 pa ni nikakršna okrnjena različica DX10, ampak je predhodnik DX10.

Če torej primerjaš DX9 in DX10 potem primerjaj OpenGL 2.0 in Open GL 2.1

Super_Budalo ::

Pozdravljeni

Članek mi je zelo všeč, sploh prvi del.:)) Drugi del je že težko dojet:D, sploh ker vidm da so ljudje videli samo +-, ki jih prinaša DX10 in nekako ni več napisan, kako nasplošno se izračunava stvar.

Bi se pa pridružil prošnji, če bi lahko napisal članek o OpenGl-u, ki mislim, da je bil dolgo časa pred Direkt-x in mislim da je bil tudi vrok za nastanek DX-a :D. MS more bit povsod:D

Verjetno ni treba povdarjati, da so bli pionirji 3d izrisovnja prov Carmak in druščina (id) in kolikor jaz vem so imeli veliko zraven pri openGL.

Pa še nekaj ali ni OpenGL nakak zelo naklonjen odprtokodni družbi.

Ne me obsojat če mam zgrešenop predstavo sam popravte me:D

Jernej L ::

izi, nehaj mešati stvari.. sploh nisem to rekel, ti si vse na glavo obrnil!

Senitel:
http://www.opengl.org/documentation/cur...

object shaderje sem nekje zasledil da naj bi bili napovedani ali za ogl 2.1 ali pa lean and mean verzijo, in naj bi iz shaderja kontroliraline samo vertekse in piksle, ampak cele objekte bi se dalo narest in določati dejansko novo geometrijo, tudi proceduralne objekte itd..

noraguta ::

...Direct3D 10 se po funkcionalnosti primerja samo z OpenGL 2.1 + NV extension-i


btw kolk tega je pa podprto ( OpenGL 2.1 + NV extension-i) v ne win OSih , čist iz ferbca.
Pust' ot pobyedy k pobyedye vyedyot!

drola ::

Več kot na Win (sploh na Visti, ki naj bi imela le še emuliran OGl).
https://drola.si

Jernej L ::

drola: to ne drži, res da ima vista opengl > d3d translator gonilnik, a ta je samo fallback za uboge gonilnike (intel?), če nimaš gonilnikov gorih za d3d ti tudi to ne bo delovalo. so pa vsi proizvajalci grafičnih gonilnikov obljubili 100% hardwersko pospešene gonilnike za visto vključno z najbolj pomembnima nvidio in ati-jem.

Senitel ::

Super_Budalo: Open v OpenGL pomeni predvsem odprtost API-ja za firme kot sta ATI in NVIDIA. Da lahko brez da kogar koli vprašata dodadata svoje razširitve v knjižnico. Za razliko od D3D, kjer mora vse it čez MS.

noraguta: Tudi na Linuxu so seveda podprti vsi ti extensioni. Samo v trenutnih driverjih se mi pa zdi da te nove (SM 4.0) zadeve še niso vklopljene (tudi na WinXP).
CUDA (ampak to je čisto ločeno od DX in OGL) je recimo bila praktično razvita na Linuxu.

Delfi: In kaj mi "current version" pove, kar že ne bi vedel? In kaj ima veze z OpenGL ES? Object shaderjev kot si jih opisal pa ne bo. Tako OpenGL in D3D imata povsem praktične omejitve glede na to kaj NV in ATI delata s hardware-om.

SavoKovac ::

Pomnim, kako sem na Ati Xpert@98 igral quake 2 v 1024c768 pri caa. 25 fps. (beta OGL driverji) :D
Al pa gledam kako novo igro na PS2 (Toca4, NFS Carbon) in majo prav lepe odseve in osvetljevanje.

Poanta: DX10 je hiter kot strela, samo so zgleda programerji plačani od vrstice.

Igrice bi morale tekoče delovat pri 25+ fps na radeonih 9600 pro in GeForcih 5700 pri 1280x1024. Tudi Gothic3. Pa ne delajo.
Sumim, da za PC-je igre novih gneracij pišejo ljudje, ki sta jim besedi "pure simple logic" in "3xfaster best guess" tuji.

Urajmal ::

Zelo dober članek. Pohvalno! Zaj pa me zanima ali bi znale zdajšnje kartice generacije 7 (directx 9) od nvidie delovati kaj hitreje na dx10? Samo za špekulacijo.

LP

SavoKovac ::

Če za izračun določene pike na zaslonu potrebuješ določene matematične operacije, potem obstaja za končni izračun neka določena spodnja časovna meja, ki jo lahko prečkaš samo tako, da poenostaviš izračun.

Dx10 kartice bodo hitre kot strela zato, ker bodo verjetno trdo ožičili še kakšno operacijo oz. optimizirali hitrost za izračune tistih postopkov, ki so najpogostejši (kot npr. za ukaz MAD pri geforcih 7xxx - sem nekje prebral). :D

Če bi pogruntali, da lahko kaj dela hitreje pod Dx10, potem bi lahko optimizarali dx9.0 driverje in pospešek bi bil enak.

Natančneje, če bi geforce 7xxx pod visto in pri enakem HW delali hitreje, bi bila nezmožnost hitrejšega delovanja pod XP posledica boljšega krmiljenja ostalih sistemskih pritiklin, kot so memory managment itd. Samo se potem reče, da hitreje deluje cela grafična aplikacija in ne grafična kartica.

SasoS ::

ali bi znale zdajšnje kartice generacije 7 (directx 9) od nvidie delovati kaj hitreje na dx10?

DirectX9 kartice ne podpirajo DX10. Zdajšnji geforci 7 in ati x1xxx bodo pod visto nucali DX9 EX, hardware ni sposoben laufati DX10. Hitrost bo ista ali manjša kot na XP.

potem obstaja za končni izračun neka določena spodnja časovna meja, ki jo lahko prečkaš samo tako, da poenostaviš izračun

To je res, vendar ta končna meja še zdaleč ni dosežena. Grafične operacije so izrazito paralelne, ko računaš pixel njegova vrednost načeloma ni odvisna od sosednjih pixlov. Dx10 hardware doda precej surove moči zato se lahko hkrati računa več pixlov. Dejansko bo spodnja časovna meja dosežena ko bo kartica zračunala vse pixle hkrati v enem ciklu (za kar bi rabil par miljonov recimo pixel shader enot)...

Zgodovina sprememb…

  • spremenilo: SasoS ()

SavoKovac ::

Mah, to z samosvojostjo DX10 je podomno kot s P4 in rambusom. OGL še ni rekel zadnje.
Sicer pa, če so pri nVidii (verjetno sledi še Ati) sposobni narediti napravo, ki pošteka Dx10 in Dx9, bi bilo toliko enostavneje naklamfati kup knjižic, ki nove postopke obravnavajo kot "new exstensions".
Še huje je, da SM3.0 sploh ni zaživel. Jah, pišejo daljše shaderje. Da pa bi razvili nove, dinamične postopke pa bi potrebovali čas, izkušnje, motivacijo, dobre HSLS prevajalnike in malce ponižnosti pred folkom, ki je kupil x16xx in Gf6xxx ter Gf76xx. Nubi pa to rešujejo tako, da priporočajo SLI, Crossfire, Gf7950GX oz. kakšno Dx10 kartico.

BluPhenix ::

Mešanje programiranja za konzole in PC navadno ni najboljša ideja. Pač je malo drugače. V konzoli imaš točno tak in tak hardver, poznaš njegove omejitve in bližnjice. Če rabiš kakšno radikalno rešitev jo še vedno lahko spišeš precej nizkonivojsko.

Pri PCju je malo drugače, ker mora delovati na vseh komponentah, vseh proizvajalcev. Torej ne moreš vedno pisati nekih nizkonivojskih rešitev, ker verjetno nebi delale pravilno na drugačnem hardverju oz. hardverju drugega proizvajalca.
Podpisa ni več, ker so me poskušali asimilirati.

Senitel ::

Dolžina shaderja je glaven dejavnik, ki omejuje višje hitrosti. To se popravlja z vsako novo grafo, ki pride na trg. Nima pa glih nevem kakšnega smisla nabijat recimo dinamičnih vejitev v SM3.0, če itak rabiš DX10 hardware, da to zgledno dela. Tudi nima smisla uporabljat tekstur v vertex shaderjih, če spet potrebuješ DX10 hardware, da zadeva normalno dela.
DX10 je sam po sebi predvsem dosti bolj čist API... Tud OpenGL bo počasi odvrgel vso dosedanjo navlako.

SavoKovac ::

Glede smiselnosti dinamičnih vejitev pri sm 3.0...
Če napišeš shader, ki ima določen kriterij pri aplikabilnosti - recimo, da se vklopi pri povprečno 30% "fragmentih", potem je vejitev čudovita rešitev. (70% discard rate)
Najpogosteje pa pišejo razmeroma dolg shader, ki pa večino delčkov spreminja malenkostno.

Nadaljuje se pri potrošnikih. Pri tistih, ki mislijo, da imajo "gaming card", prevladujejo kartice srednjega razreda. Nato tistih 10% gamerjev, ki imajo težko kartico, večinoma utišajo večinske povprečneže (dokaj uspešno, moram priznati). Za igrico pa plačajo enako.

Pa kupovat samo hi-end kartice, poreče nekdo in izvrže 100k za gf.5950, 100k za 6800ultra in 80k za 7900GTX.
Saj bi to počeli vsi (rade volje), sam so tu zavarovanja, zimske gume, položnice, kurjava, možnost, da bodo kakšno igro spisali tako kot treba (HL2, CoD2...).

Zgodovina sprememb…

Senitel ::

Ja, če napišeš pošteno dolg shader, za katerega imaš nek pogoj, ki ga vklopi le v 30% pixlov potem se ti to mogoče celo splača. Ampak koliko je takšnih shaderjev, pa da se vejitve ne da čisto zaobit (texkill)?
Druga fora pa je, da te v bistvu sploh ne skrbi koliko krat se daljša pot vklopi... Samo da čimveč sosednjih pixlov ubere isto pot. Razmišljat moraš vsaj o quadih, če ti en pixel v quadu ubere drugo pot kot ostali trije, potem bo cel quad stal, dokler se ne izvedeta obe poti. V realnosti je še huje. Na G7x je to območje veliko nekje okrog 1000 pixlov! Kar pomeni 999 pixlov šiba recimo po kratki poti, le 1 pa po dolgi in bo vseh 999 pixlov čakalo, da se bo izvedla najprej dolga pot, potem pa še kratka pot (ali obratno)! Plus da plačaš še if, else, endif ukaze.
R520 ima to bistveno boljše: 16 pixlov oziroma dva quada. R580 pa že spet slabše: 48 pixlov. G8x pa udari v sredino z 32 pixli. :8)

SavoKovac ::

Sem spet nekje bral, da si pri Atijevih sm3.0 čipovjih piksel shaderji zmorejo deliti workload v primerih, ko so kapacitete proste.
Potem so tukaj lokalizirani posebni efekti, ne-obdelovanje ozadja (nebo...), zelo temnih predelov...

Sam sem tudi vsekakor pristaš politike avtorjev in založnikov, ki izdajajo popravke za malce starejše igre (Far Cry) itd.

Morda pri nVidii vedo, da je njihova early sm3.0 arhitektura glede tega inferiorna in hitro kopljejo naprej. Avtorji iger pa jim ne sledijo najbolje (odpustimo jim, revežem :D ).

Če se še enkrat sklicujem na konzole - konzole (ala PS2) so lep primer kaj vse se da postoriti, ko programerji poštekajo arhitekturo in izkoriščajo njene bonuse.

Senitel ::

Deliti kakšen workload, ko so katere kapacitete proste?

SavoKovac ::

If there is a stall in the pipeline, the thread currently being processed is swapped out into the General Purpose Register Arrays and a new thread is dispatched to the pixel shader core so minimal time is wasted. With this sort of setup, ATI claims that the pixel shaders are utilized 90% of the time.

Povezava.

Senitel ::

Eh... Everyone does that, zato so grafične tolk hitre. Je pa res da ATI z R5x0 počne to malce bolje kot G7x.

Brane2 ::

Meni bi intenzivno zanimalo, kako so te stvari narejene na registerskem nivoju.

Katere instrukcije sprejemajo enote, od kod jih pobirajo, koliko časa traja izvajanje itd.

Če je to skrivnost za nove, pa za kak malo starejši model, mogoče GF4Ti ali kaj podobnega.
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

Senitel ::

Sam nabor ukazov je dosti blizu tistemu, ki je prikazan navzven (shaderji). Večina ukazov se tudi izvede v enem samem ciklu, so pa stvari seveda že na nivoju posameznih enot cevovodne.
Načeloma imaš dost valik cache na čipu, da lahko komplet mikro kodo spraviš vanj. Vendar za razliko od CPU-ja en ukaz dostavljen vsaj na cel quad pixlov hkrati. Dostopi do pomnilnika so seveda bolj RISC like in načeloma kadar koli kaj čaka, se zadevo vrže vn iz izvajanja dokler niso podatki nazaj. Nimaš sklada, imaš pa zato velik bazen splošno namenskih registrov.
Toliko na hitrico. :)

Brane2 ::

Dokler jaz nimam datasheetov v roki, si stvari ne znam predstavljat.

Lahko teto nVidio pregovoriš da me pusti špegat, ko bo naslednjič v kopalnici ? :D
On the journey of life, I chose the psycho path.

SavoKovac ::

Fajn bi blo tut brat o HDR rendering, če za to res rabijo offscreen bufferje in zakaj ne morejo rendrat v super-resoluciji, in tako "forsirat" AA regardless od tega, kaj pravijo driverji.
Potem pa še o tem, kako se da optimizirat shader koda, kako eni tega ne počno in celo sproti nalagajo-prevajajo HLSL kodo med samim izrisovanjem.:P


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Nov članek: Vzpostavitev v celoti šifriranega sistema na Ubuntu Feisty

Oddelek: Novice / Nova vsebina
465704 (4061) poweroff
»

Članek: Video nadzor na slovenskih avtocestah

Oddelek: Novice / Nova vsebina
376401 (4947) radems
»

Nov članek: Šablone v C++

Oddelek: Novice / Nova vsebina
173753 (2863) Gundolf
»

Nov test: Dinastija 5900 proti dinastiji 9800!

Oddelek: Novice / Grafične kartice
312080 (2080) morphling1
»

Nov članek: Slo-Tech LAN -- NEST.2003

Oddelek: Novice / Nova vsebina
393055 (3055) VASkO

Več podobnih tem