» »

Nov članek izpod Senitelovih prstov

Nov članek izpod Senitelovih prstov

Slo-Tech - Senitel zna, to vemo vsi, ki vsaj malo spremljamo forum ter njegove utemeljene odgovore na vse, kar se tiče grafičnih tehnologij. Na Infosu me je obiskal ter začel govoriti, da 32 bitov barvne globine kmalu ne bo več zadosti. Čudno sem ga pogledal, a vse mi je bilo jasno po petnajstih minutah intenzivnega razlaganja tipa "sedaj pa še enkrat, počasneje". Na to temo je bil ukazan spisati tudi članek - ukaz je tudi izpolnil. Uživajte!

20 komentarjev

||_^_|| ::

kapo dol...

Boeing ::

bravo senitel... taki članki bi morali postati na slo-techu stalnica !

Highlag ::

Vse lepo in prav samo.

Kaj za hudiča? A v igricah res rabiš barve tako natančno izračunane?[:\]

[SpydeR] ::

Vse pohvale Sentinelu za tale članek!!!

Vucko ::

enkraten članek!
zelo poučno.. keep up the good work

BigFoot ::

spet si spisu en super članek senitel :D

Brane2 ::

Ne da bi hotu pljuvat po delu drugih, sam tuki (vsaj meni) ni vse jasno.

Stvar utemeljuje povečanje barvne globine s potrebami po natančnosti v internih izračunih mašine.

Pri tem domneva, da program jemlje vzorce slike iz videobufferja, kar sploh ni nujno res.

Zakaj bi nekdo delal s bitno širino končnega piksla ?
Pač delaš s širino, ki jo rabiš in nato rezultat odrežeš na zeljeno sirino, ko ga vpisujes v sliko...

Ce bi recimo presaltu z 32bp na 128 bp pri 1600x1200, bi slika, ki ti je prej vzela cca 8Mb, zdej vzela kar 32 MB.
Pa to ni tisto glavno, glavno je to, da bi ble VSE rastrske operacije zdej 4x pocasnejse...

Tud ni mi jasno, kaj bi melo uporabnikovo oko od dodatnih bitov. Ni ga D/A pretvornika na tem svetu, ki bi dal od sebe postenih 16 bitov pri recimo 300 Mvzorcih /s in tudi ne monitorja, ki bi to znal prikazat...



ToniT ::

Spet bo treba kupovati nove grafične kartice>:D.

Lunik ::

:)

moj vudu še 32bpp ne prebavi

:)

_Mortal_ ::

Čez neki časa bo pl gor 256 rama na grafični>:D

CaqKa ::

mocno se strinjam z Brane2 njegovim zadnjim odstavkom.... problem je v tem da oko tega ne opazi.... ko bo 32bpp premalo, to sigurno nebo zaradi tega ker bi moje očkice to opazle... zgolj marketinška poteza, zaradi katere bodo nekateri spet leteli v trgovine po nove grafične....

CaqKa ::

seveda sem pri tem govoril o barvah ki pridejo na zaslon.... za tisto kar si pa ti napisal pa bo verjetno res kot si napisal... vseeno je vse skupaj malo cudno...
lp
caqka

Sergio ::

ja, sej kaj pa je narobe s 64 (ali celo 128) bitnim RAČUNANJEM ter 32-bitnim prikazovanjem? volk sit, slika lepša.

Brane2 ::

Sem šu še enkrat brat tisti clanek in tam je govora o stvareh, kot so zapisane v sliki, torej videobufferju in ne o internih stvareh v grafičnem čiperaju.

Poleg tega so navedeni primeri 5 bitnega računanja, ki se po moje nikjer ne uporablja.
Senitel očitno v primeru uporablja 16 bp s po 5 timi biti na barvo. O.K. mogoče bi kdo v grafičnem čiperaju res uporabu 5-bitne prenosne poti, sam to je mal tko-za lase privlečeno.

O.K. pri 5-tih bitih si lahko natančen na 1/32ko in tam se ti pač napake naberejo...

To bi pasalo bolj v problematiko hardvera izpred 10-12 let.

Mater, še prve kartice z videoprocesorjem, mislim da je bil to Motorolin 68343, ki so dale od sebe "sapo jemajočih in neverjetnih 1Mpix/s" so mele vsaj 8-bitno matematko!




Senitel ::

Lepo, da vam je članek všeč!


Brane2: Eko sem mel napisan lep odgovor, pa je vse skupi šlo nekam... Zdej se mi ne da vsega pisat še enkrat ampak bo samo na kratko:


1. Preciznost je stvar, ki se jo določa na kanal in ne za komplet pixel. In v članku je lepo račun za en sam samcast kanal.


Eko še okvirne specifikacije za DirectX 9.0.


In mnenje Johna Carmacka o tej zadevi. Samo insert:


4/29/00


-------


We need more bits per color component in our 3D accelerators.




I have been pushing for a couple more bits of range for several years now,


but I now extend that to wanting full 16 bit floating point colors throughout


the graphics pipeline. A sign bit, ten bits of mantissa, and five bits of


exponent (possibly trading a bit or two between the mantissa and exponent).


Even that isn't all you could want, but it is the rational step.




It is turning out that I need a destination alpha channel for a lot of the


new rendering algorithms, so intermediate solutions like 10/12/10 RGB


formats aren't a good idea. Higher internal precision with dithering to 32


bit pixels would have some benefit, but dithered intermediate results can


easily start piling up the errors when passed over many times, as we have


seen with 5/6/5 rendering.




Eight bits of precision isn't enough even for full range static image


display. Images with a wide range usually come out fine, but restricted


range images can easily show banding on a 24-bit display. Digital television


specifies 10 bits of precision, and many printing operations are performed


with 12 bits of precision.



Pa ne mi rečt, da Carmack ne obvlada...

Brane2 ::

Carmack je (baje) faca.
Samo:

-tip govori o najvec 10 bitih po kanalu.
Sanja celo nekaj o 12-tih, kar kao imajo skenerji
(grejo pa danes tud več, moj EPSON ma 14, tanov model pa 16), pozablja pa, da hitrost zajema podatkov v skenerju ni 1/100 tistega, kar pride ven iz kartice.

Torej, 10 bitni DACi so ze nekaj casa zunaj in zdej je za videt, kdo bo naredu preskok na 12-bitne v normalnem cenovnem razredu pri recimo 300 Ms/s.

Vsekakor pa tip ne govori o 64 ali 128 Bitnem pikslu in recimo 32 ali 40 bitnem kanalu.

32bitni video DAC ? To moram se videt.Nato ga še skadim tropu slonov in lahko rečem, da sem v življenju izkusu več ali manj vse.:D

Aja, kar se sirine tice, jaz sem dojel, da si v primeru navedu 16bitni pixel s tremi 5 bitnimi kanali. A sem falou ?

Aja, se ena cvetka v clanku je bla ta, da se interno vsa izracunavanja dogajajo v desetiskem formatu ?!?

Ce sem se zmotu, se opravicujem, sam mislem, da si tle falu ortodoksno.

Vsa interna izračunavanja se v masinah dogajajo binarno (za kar je kup razlogov) in to, da so vsa stevila v obsegu 0..1 ne pomeni dosti.
Tko zgleda vsaka cifra v FPU enoti tvojga Pentiuma, ce ji odrezes eksponent.

Se to, Carmack navaja kot glavni razlog za vec bitov po kanalu "banding". Pravi torej, da je 8 premalo, da je sedanji standard 10 in da novi standardi za HDTV narekujejo 12.
O.K. Ampak to je se vedno dalec od 128 bitov oziroma 32 ali celo 42 po kanalu.

Tam pride v igro tisti plavi prelivcek v tvojem clanku. Ce delas torej prelive in nimas na voljo zadosti barv, da bi imel vsak piksel preliva svojo barvo, se ti lahko zgodijo lise v prelivu.

Pa kaj ? To se dogaja samo zato, ker folk in njihov hardver nima časa za dithering.

Zdej naj bi ves folk presaltu na totalno nov, bistveno dražji in neizmerljivo malo boljši harver zaradi Carmackovih videorutin ? LOL







Brane2 ::

Ups, zajeb. BOLD mi je zašteku.
Nism mislu vpit :D

Senitel ::

Ej pa kok ti površno bereš??? Sej to ni res... Iz linka na Carmacka:


The situation becomes much worse when you consider the losses after multiple


operations. As a trivial case, consider having multiple lights on a wall,


with their contribution to a pixel determined by a texture lookup. A single


light will fall off towards 0 some distance away, and if it covers a large


area, it will have visible bands as the light adds one unit, two units, etc.


Each additional light from the same relative distance stacks its contribution


on top of the earlier ones, which magnifies the amount of the step between


bands: instead of going 0,1,2, it goes 0,2,4, etc. Pile a few lights up like


this and look towards the dimmer area of the falloff, and you can believe you


are back in 256-color land.



There are other more subtle issues, like the loss of potential result values


from repeated squarings of input values, and clamping issues when you sum up


multiple incident lights before modulating down by a material.





A few common responses to this pitch:




"64 bits per pixel??? Are you crazy???" Remember, it is exactly the same


relative step as we made from 16 bit to 32 bit, which didn't take all


that long.





"Can we just put it in the texture combiners and leave the framebuffer at 32


bits?" No. There are always going to be shade trees that overflow a given


number of texture units, and they are going to be the ones that need the


extra precision.



64 bit pixels. It is The Right Thing to do. Hardware vendors: don't you be


the company that is the last to make the transition.



Neee kje Carmack sploh ne govori o 64bitnih pixlih kje .


In če bi pogledal še un link o DirectX 9.0, kaj pol delajo teli formati noter AGBR8, ABGR10, ABGR16, ABGR16f, ABGR32f???


Še neki iz DX 9.0: Hardware now has enough precision to handle gamma correctly


Correcting gamma from 8-bit textures was pointless on 8-bit hardware.


Mislem no vsaj od Carmacka bi pa lahko preberal...

Senitel ::

32bitni video DAC ?

Ni nujno, važno je, da je back buffer na 64bpp, front buffer pa lahko ostane na 32bpp.
Aja, kar se sirine tice, jaz sem dojel, da si v primeru navedu 16bitni pixel s tremi 5 bitnimi kanali. A sem falou ?

Ja 16bitni pixli z tremi 5bitnimi kanali in 32bitni pixli z štirimi 8 birnimi kanali. Kaj je s tem narobe?
Aja, se ena cvetka v clanku je bla ta, da se interno vsa izracunavanja dogajajo v desetiskem formatu ?!?

Kje sem to reku??? Tisti izračun levo je lepo izračunan, in spodaj tudi piše "lep izračun" in je samo realen rezultat in nič drugega.

Brane2 ::

>>32bitni video DAC ?

>Ni nujno, važno je, da je back buffer na 64bpp, front buffer pa lahko ostane >na 32bpp.


O.K. Ima smisel. Ampak potem organizacija bitov posameznih pikslov v videobufferju, od koder shifter pobira sliko nima veliko z geometrijsko definicijo stvari, mislim poligoni, normalami itd. Tisto se pac racuna v katerikoli natancnosti in sirini in na koncu se rezultat obreze na zahtevano sirino.

>>Aja, kar se sirine tice, jaz sem dojel, da si v primeru navedu 16bitni pixel s >>tremi 5 bitnimi kanali. A sem falou ?

>>Ja 16bitni pixli z tremi 5bitnimi kanali in 32bitni pixli z štirimi 8 birnimi kanali. >>Kaj je s tem narobe?

Nič, samo karikira problem. Danes so 16 bitne ALU in FPU enote že stvar preteklosti, torej ne vidim v čem je taka frka pri prehodu s "starih" na "nove"...
Že res, da jih grafični čiperaj verjetno rabi na kilo, pa vseeno...

>>Aja, se ena cvetka v clanku je bla ta, da se interno vsa izracunavanja >>dogajajo v desetiskem formatu ?!?

>Kje sem to reku??? Tisti izračun levo je lepo izračunan, in spodaj tudi piše "lep >izračun" in je samo realen rezultat in nič drugega.

Evo:


Kot smo spoznali že v zgornjih dveh poglavjih, imamo opravka z dvema vrstama števil. Decimalna števila so zelo pripravna za računanje in grafični čipi dejansko delajo z pravimi decimalnimi števili v območju 0.0 do 1.0 za vsako barvno komponento posebej.


Šele po tvoji reakciji sem dojel, da si mislu na racionalna števila med 0 in 1, ne pa obdelave v desetiskem (decimalnem) številskem sistemu.
BCD (Binary Coded Decimal) ukazi v mašincu se sicer (so se) uporabljajo, vendar v druge namene, ne pa zaradi večje hitrosti.