DirectX 9.0 zou 128 bit floating point kleuren eisen

Dat er een duidelijke trend gaande is die stelt dat 32 bit kleur niet meer voldoende is mag inmiddels bekend zijn. Carmack riep het twee jaar geleden al, en Microsoft volgt nu. Eén van de eisen om een videokaart 'volledig DirectX 9.0 compliant' te mogen noemen zal namelijk zijn dat er meer dan 32 bit kleur ondersteund dient te worden. Volgens The Inquirer laat men daar echt geen gras over groeien, want 40 of 64 bit wordt volgens hen niet geaccepteerd. Niet minder dan 128 bit floating point kleur zou goed genoeg zijn voor de nieuwste generatie videokaarten. Met meer dan 4 miljard - in plaats van 256 - combinaties per kanaal zouden spellen er een stuk beter uit moeten zien. ATi zou dit implementeren in de R300 (Radeon 10000?), en men vermoedt dat nVidia hetzelfde gaat doen in haar NV30 chip:

According to our sources, the 128-bit implementation will make multitexturing applications look better and you will be able to have 32-bits per colour. This is amazing since it enables you to have 16.7 milion combnations per colour. In current 32-bit color you just have 8 pixels per colour, giving just 256 variations of colors.

[...] 128-bit floating point colour will bring more cinematic reality in effects used in games and everything will look lovely, we're told.

Met dank aan Spollie voor de tip.

Reacties (101)

[Beaves]

128-bit floating point colour will bring more cinematic reality in effects used in games and everything will look lovely, we're told.

Ik denk dat de kracht van de GPU nog altijd de hoofdreden is voor het "lovely" uitzien van een game, want je kan wel 128-bit kleuren hebben, als de rest van de GPU bagger is ziet het er nog steeds niet uit.

Natuurlijk zullen de kleuren realistischer zijn, alleen zul je het verschil in een game niet zo snel merken aangezien die meestal erg snel gaan, je hebt geen tijd om uitgebreid te gaan zitten kijken.

De uitbreiding zal vooral handig zijn voor de mensen die bijvoorbeeld afbeeldingen manipuleren, de overgangen zullen veel vloeiender zijn dan dat nu het geval is.

Al met al een mooie ontwikkeling, nu moeten de verschillende game fabrikanten het wel gaan gebruiken, want de huidige videokaarten volgen elkaar zo snel op dat het bijna onmogelijk is als gamefabrikant om de nieuwe technieken te gaan gebruiken.

[mvt]

Natuurlijk moet de GPU sterker worden om dit allemaal op een redelijke fps te tonen. Maar waar je de laatste tijd steeds meer kracht ziet zie je dat die steeds meer gebruikt wordt voor eyecandy, juist door de krachtreserves die er in de huidige (en de nieuwe) generatie GPU's zit kan de toegevoegde effecten omhoog voor mooier beeld.
Dat zie je al door de hele ontwikkelig van computers, zodra de computer (nieuwste/zwaarste modellen) met gemak alles draaien komt er een slag complexiteit bij waardoor de computers in principe beter worden, niet omdat ze sneller zijn, maar omdat ze op dezelfde snelheid complexere dingen kunnen doen. (parallel vroeger : sprites op bepaalde framerate, nu: 3d op diezelfde framerate)

[Anoniem: 26337]

ik vraag me af of je werkelijk het verschil kunt zien tussen 32bit en 128bit kleur op je scherm,

lijkt me heel onwaarschijnlijk.

[Anoniem: 48318]

Dat verschil zie je niet.
Maar het verschil tussen een 8-laags texture doorgerekend met 32-bit en doorgerekend met 128 bit zie je zeker wel.
Vergelijk de voodoo 3. Dat was een 16-bit kaart die intern met 24bit rekende. 16-bits kleuren zagen er op de voodoo 3 veel beter uit dan op de tnt2 of de G400.

[afterburn]

Exquise me, de G400 rekent intern altijd op 32bit, wat ook de reden is dat de performance hit van 16b naar 32b op een G400 nihil was/is.

[Anoniem: 1145]

Excuise me, intern op 32bit rekenen wordt al ERG lang gedaan. Dat deden de rendition verite kaarten bijvoorbeeld al, en de 3dfx voodoog graphics misschien ook, dat weet ik niet zeker. Dat is ook waarom van 16bit naar 32bit gaan alleen meer geheugenbandbreedte kost voor alle videokaarten. Als er oneindig bandbreedte zou zijn zouden alle kaarten volledig zonder performance hit 32bit kunnen draaien.

Het probleem ontstaat wanneer er iets naar het geheugen weggeschreven moet worden en dat wordt in 16bit gedaan.

[Anoniem: 48318]

Klopt, heb je helemaal gelijk in, was ik alweer vergeten (is ook al lang geleden, de glorydagen van de G400 Max)

[0rbit]

Op je scherm dus niet. Blijkbaar weet je niet waar het over gaat.

Het gaat erom dat als je met bijv. textures berekeningen gaat uitvoeren dat je bij elke berekening afronding krijgt. Deze afronding ga je zien als deze te groot wordt (te veel berekeningen). In hoe meer stapjes je het kleurenbereik indeelt hoe kleiner het zichbare effect van deze afrondingen op de kleuren.

[Anoniem: 55567]

Op je scherm dus niet.

Waar kijk jij dan naar?

[Cybje]

Je krijgt geen 128 bit kleur op je scherm, maar 32 bit kleur. Alleen intern wordt er gerekend met 128 bit, om, zoals mr_atheist al zei, bij afrondingen alsnog hoge kwaliteit te behouden.

[The-Source]

Het verschil in 32bit en 128bit kleuren ga je wel degelijk terug zijn.
In situatie waar veel rook/ vuur/ mist is merk je dat het nu veel beter er uit gaat zien.
Niet elke bit zal voor een kleur gebruikt gaan worden maar er zullen er ook een stel door de alpha blending in beslag worden genomen.

[Rene59]

Wat wordt er überhaupt op je beeldscherm gegeven? Is een beeldbuis ook een bepaald aantal bits? Hoe moet je dit lezen?
Een monitor kan toch ook niet oneindig veel kleuren weergeven? Of wel?
Wie legt het ff uit.

[BadRespawn]

ook met 128 intern wordt 32 bit op het scherm weergeven (het nut van 128 wordt inandere posts hier uitgelegd).

Een traditionele (niet-LCD) monitor is analoog en kan dus in princiepe oneindig veel kleuren weergeven; voldoende nuances zodat geen 'kleur-stappen' zichtbaar zijn.
Wat werkelijk wordt weergegeven op de monitor hangt helemaal af van de kaart waarmee die aangestuurd wordt.

[Anoniem: 37034]

Voor zwart-wit wordt 10bits als "voldoende" gezien. Met 32 bits kan je dus (ruim) 10 bits per kleur nemen, en dat zou "voldoende" moeten zijn.

Dat wil nog niet zeggen dat 128 bits per pixel onzin is. Je kunt veel meer doen met overgebleven bitjes in een pixel. Door bijvoorbeeld een waarde voor de diepte bij iedere pixel te bewaren kan je allerlei objecten gewoon tekenen, en een hardware-compare kan dan bepalen of ie voor of achter de reeds getekende dingen zit.

Het zou best kunnen dat je ineens 2x zo veel bitjes nodig hebt om dat te kunenn als je ook doorzichtige objecten wilt kunnen tekenen.

24 bits: objectkleur
24 bits: kleur van de "doorschijning".
16 bits: diepte waarde.
16 bits: diepte van doorschijning.
8 bits: doorschijnings percentage.

Dan zit je ondertussen op 88 bits. Verzin maar wat voor de resterende 40...

[SG]

Ze willen dat toepassen om de afrondings fouten bij multypass terug te dringen want elke berekening genereerd een afrondings fout en bij 5 texture passes 5 afrondingen waarmee wordt doorgerekend. dus de pixels hebben een 5 voudige afwijking
Met 128bit zijn de afrondingen voor 32 verwaarloosbaar en hou je een enkele afronding van 128bit naar 32bit over zodat afwijking miniem is.

Doorrekenen met meerdere afrondingen is funest voor de afwijking die wordt dan groter daarom het eindresultaat eenmalig afronden

vooral nieuwe games zullen vaker Multypass texturing met 4 of meer textures en dat gaat het een grotere rol mee spelen.

[Nefiorim]

Ja daar zit ik dan straks met m'n R8500 (ja ik weet dat DX 9 games nog lang op zich zullen laten wachten, maar toch).
Nou weten we ook meteen waar die grote winstmarges op videokaarten (in ieder geval bij nVidia) heen zijn gegaan. Kan namelijk niet geloven dat ze dit zomaar 1 2 3 hebben ontwikkeld (aannemende dat de technologie d'r al is), moet me een berg werk hebben gekost.
Dus wat voor games en andere D3D presentaties moet ik me hierbij voor gaan stellen? 128-bit benadert het "echte" leven toch een redelijk end dacht ik zo of nie?

edit:
En nu is t wachten op de eerste games met zoveel geweld wat er zo realistisch uit ziet om DIE hele discussie weer aan te wakkeren

[edit2]Wat nou flamebait, t is toch bekend dat nVidia grove winstmarges hanteerd?[/edit2]

[MaDMaRTiGaN648]

DirectX 9.0 vereist een videokaart met een DirectX 9.0 driver. Voor een DirectX 9.0 driver heb je echter geen DirectX 9.0 hardware nodig... Dus wil je toch DirectX 9.0 doen, dan zullen een aantal taken softwarematig opgelost moeten worden (en heb je dus alsnog een redelijk zware CPU nodig )

<typo corrected...>

[SG]

Daar klopt niks van.

De eerste G3 waren gereleased met drivers zonder DX8.0 supoport die waren later gekomen.
Aangezien de Game software geprogrammeerd is op 'n bepaalde Com interface van 'n DirectX versie moet de driver minimaal die versie ondersteunen die de game gebruikt om te kunnen lopen. dus ten tijde van release eerste G3 waren er alleen tot DX7 games, eisen dus de DX7 Com interfaces dus DX7 of hoger dushebben voldoende aan 'n DX7 driver voor 'n kaart of dat nou DX5 6 8 9 hardware is.
De DX hardware bepaald of en wat de HEL van DX kan emuleren bepaald of features gebruikt kunnen worden.

Normaal worden G-kaarten sowieso met drivers verkocht die de MAximale DXversie in hardware onderstenen geleverd later komen er dan DX drivers voor de nieuwere DX versies.

Dan nog de DX 8.x en DX9 kan natuurlijk in DX (HEL)of driver of Game(Dronez) engine geemuleerd worden maar wordt bewust niet gedaan omdat de taak die GPU met hun T&L van de CPU overgenomen hebben zo zware is dat de performance hit gigantisch zou zijn dus emuleren wordt dus niet gedaan omdat het niet rendabel is, daarom ondersteund de Hel DX8.x /9 features niet omdat te zwaar is voor de CPU , enkele drivers van 'n bepaald merk heeft dat wel gedaan omdat die geen t&L i hardare hebben wat nog redelijk mogelijk is met eerste generatie T&L en ook 'n enkele game engine maar de performance hit is dan groot.

En bij nieuwe games met nog zwaardere geometry zal de hit nog groter zijn.

[Anoniem: 38811]

Volgens mij worden er hier een aantal dingen door elkaar gehaald.
1. Er zullen niet meer bits naar de monitor gestuurd worden, de meeste monitoren zijn analoog of 24bits dus meer sturen heeft geen zin.
2. Een hogere rekennauwkeurigheid heeft wel zin en dit is ook waar de 128bits van microsoft op doelt. 128 bits geeft 28 cijfers en is dus nauwkeuriger dan en minder afrondingsgevoelig dan een 32 bits berekening. Deze 28 cijfers kunnen dus heel goed gebruikt worden om special effects uit te rekenen. Het eind resultaat zal niet die hoeveelheid bits bevaten maar gewoon monitor output zijn.
3. De term float geeft aan dat een getal geen geheel getal (interger) is. Het aantal bits geeft de nauwkeurigheid van een getal. Double is een historische term die weergeeft dat er 2 keer zoveel bits gebruikt worden, maar is dus nog steeds gewoon een float.
4. 128 rekennauwkeurigheid wordt gebruikt om een 24/32bits kleurendiepte uitterekenen.

[Jace / TBL]

128 rekennauwkeurigheid wordt gebruikt om een 24/32bits kleurendiepte uitterekenen.

Nee, 128 bit wordt gebruikt om 4 channels (R,G,B en A) van elk 32 bit op te slaan.

Er gaat inderdaad geen kleureninformatie met 32 bit per channel naar de monitor, die 32bit precisie (per channel) geldt alleen voor tussentijdse berekeningen, dwz het combineren van texture layers. Wat er naar je monitor gaat is (doorgaans) analoog.

[Anoniem: 36518]

dit is dus niet eens heel moeilijk te verwezelijken

software render zou dit al zeker kunnen

het zorgt zeker voor een goed beeld als je al die textures gaat mixen dan nog blenden (voor transparansy) en nog licht erbij dan zou 32bit berekening met maar 256 wel eens teveel afronden worden

met 16.4 miljoen mogelijk heden word dit veel preciser

en zeker mooien denk ik zo

(in c++ programma's die ik wel eens maak zijn 4 byte floating points ook niet precies genoeg om mooie vloeiende lijnen overgangen te krijgen van bepaalde berekeningen

ik gebruik dan al grotere variabelen

dus zal 128bit is 16 byte kleuren per pixel erg goed werken voor de kwaliteit en minder verlies door afrondingen

(waardoor games vaak nog als games uitzien (je kunt zelfs met de beste games vaak nog zien dat het een game is en geen echt)

ik denk dat dit een goed idee is maar natuurlijk ook meer geheugen nodig heeft

maar als bv de nieuwe kaarten allemaal directx9 compatible zijn ondersteunen ze dit
en ze hebben allemaal wat meer geheugen

(misschien nog meer nodig met sommige games is 32 mb niet genoeg op full detail en best texture compressin enzo)

dus 64 mb nu genoeg moet je met 128bit dus 4 x zo veel hebben wat dus 256 mb en als ik zo kijk zijn er 256 mb matrox parhelia's en kan omen en ati ook met 256 mb
dus dat is al gauw op de markt hoop ik

dat betekent makkelijker games er echt te laten uitzien

[Anoniem: 36518]

hmm parhelia niet dus maar omen denk ik wel (later uit dan nieuwe ati die het ook heeft)

ik vind dat geen slechte ontwikkeling

hoewel ik eerst dacht je kunt niet meer zien maar ja in berekeningen kun je niet genoeg getallen achter de comma hebben voor kwaliteit (hoewel genoeg is maar relatief aan wat je goed vind)

[Anoniem: 17892]

Het gaat er niet om of je alle kleuren kunt zien. Het gaat erom dat als je gerenderde frames met 128bit doorrekent, je veel realistischere beelden krijgt (in een frame heb je niet alleen te maken met een texture, maar met belichting, geblende textures, multitexturing enz.) Als je die verschillende lagen gaat doorrekenen om er 1 laag van te maken die je uiteindelijk op je scherm krijgt kun je veel nauwkeuriger en realistischere resultaten bereiken met 128bits precisie...

[zaadstra]

4 miljard per kanaal dus 12 miljard totaal ... zijn dat niet veel meer gradaties dan het menselijk oog kan onderscheiden?

[Anoniem: 48318]

4 miljard per kanaal, dus 64 triljard (64 * 10^12) in totaal (de kleuren worden gemengd, niet naast elkaar getoond, je moet dus vermenigvuldigen, niet optellen.)

[White Feather]

Nee, 4 miljard per kanaaal betekent voor 3 kanalen dus 4 miljard tot de macht 3 = 2^96= 79228162514264337593543950336 kleuren.


Dit is natuurlijk ietwat overdreven. Bovendien gaat dit gigantisch ten koste van je performance. Je geheugenperformance moet nu 4 x zo hoog worden. En je geheugen moet dus ook 4 keer zo groot worden, want alles behalve je z-buffering wordt 4 x zo groot!!

[ritsjoena]

ik vraag me af of je werkelijk het verschil kunt zien tussen 32bit en 128bit kleur op je scherm

Het gaat hiet om rekenwerk en het zijn dan ook floating points. Het zou me niet verbazen als het filter naar je scherm maar 32 bits is.

Als je complexe berekeningen uitvoert met integers heb je nogal last van afrondfouten voor al die afrondingen die je elke keer weer maakt.

10/3*3 = 3*3 =9 ipv 10/3*3 = 3.333333*3 = 9.999999 =10

En dat vele malen in je berekening.

[Jefrey Lijffijt]

het is nog veel erger, je kunt in een computer geeneens 0.1 of 0.6 als double of floating-point waarde opslaan omdat het een reeks 2 machten is
echter met 16 bit is de afronding nogal grof, met 128 bit zou die te verwaarlozen zijn

(uitleg: 0.1 is dus opgebouwd uit 1/(2^2)+1/(2^3)+1/(2^4)+1/(2^5)+1/(2^6)+1/(2^7)+1/(2^8)+1/(2^9) enzovoorts)

edit:

[quote]

In current 32-bit color you just have 8 pixels per colour, giving just 256 variations of colors.

[/quote]
ahem 8 pixels per colour.. 8 bits per colour zullen ze bedoelen

[Anoniem: 55563]

Uhm, 1/(2^2) is al 0,25. Dat is al hoger dan 0,1 dus jou voorbeeld klopt niet helemaal.

[Japs]

Je hebt helemaal gelijk, ik had het "floating point" even over het hoofd gezien.

Overigens word voor het opstaan van een standaard "double" waarde 64 bits gebruikt, dat laat dan nog 64 bits over voor overige dingen zoals de alpha.

Ter info je kan met een standaard double floating point variabele de volgende waarden beschrijven:

– 1.79769313486232E308 to  – 4.94065645841247E-324 for negative values, 4.94065645841247E-324 to 1.79769313486232E308 for positive values, and 0.

[Anoniem: 26337]

ah, bedankt voor de uitleg.

ik begrijp nu dat John Carmack gelijk heeft. DX9 zou idd 128bit floating point kleuren moet hebben.

[draadjelos585]

sorry maar de schoolmeester in mij komt ongewenst even bovendrijven....

Meneer Van Dale Wacht Op Antwoord....

10/3*3=10/9=1 rest 1 ;-)

Afgezien van deze muggezifterij mijnerzijds: goed voorbeeld ;-)

[Rataplan]

En hierrrr is de corrector

De prioriteit van vermenigvuldigen en delen is gelijk, het ezelsbruggetje is "fout" want het suggereert een volgorde die er niet is.

10/3*3 is wel degelijk 3,3333... * 3, en niet 10/9.

Om een beter voorbeeld te geven:

10/2*5 is 25 en niet 1. Tik maar eens in in een rekenmachientje, of Excel.

[ritsjoena]

Om de correctorren een plezier te doen zal ik mijn voorbeeld herschrijven, zoals deze in praktijk plaats zou vinden:

int a,b;
a = trunc(10/3) =3;
b = trunc(a*3) = 9
en dus niet 10.
Je rekenmachientje (en die van excel) neemt de rest, ie rest/3 wel mee want hij werkt zelf met floats. Als je alleen met integers werkt, wordt deze niet meegenomen.

[Anoniem: 55563]

En dan nog de puntjes op de i:

In de wiskunde wordt heel graag met haakjes gewerkt als dergelijke bewerkingen op 1 regel staan, dus:

(10/3)*3 is niet gelijk aan 10/(3*3)

Juist omdat vermenigvuldigen en delen dezelfde prioriteit hebben, zijn haakjes gewenst om duidelijk te maken wat je nou eigenlijk bedoelt. Er simpel vanuit gaan dat je van links naar rechts leest en dat daardoor de volgorde van bewerkingen vanzelf duidelijk wordt, vind ik een slechte afspraak.

[Robert Pape]

Lang leve postfix-notatie... geen haakjes.. en toch de juiste volgorde..

En zoals al eerder gezegd: best mogelijk dat 128 bit verbeteringen met zich meebrengt, door minder afrondfouten...

[Anoniem: 37605]

[offtoppic]
mierenneukerij:
en double van 9.999999 gecast naar een int is 9
[/offtoppic]

edit:

sorry ben Noob poster en had niet gezien dat het al gezegt was.

[gjkamstra]

Kan een monitor eigenlijk wel meer dan 32 bit kleuren weergeven?

[Francois]

CRT wel: anoloog, onbeperkt aantal kleuren mogelijk

LCD niet: vast maximum per (type) panel. Meeste nu 16 of 24 bits

DVI-D zal het trouwens ook moeilijk krijgen met 128bpp....

[Madrox]

Je monitor kan alles tussen wit en zwart weergeven. Zwart en wit dus ook

Hoeveel dat is hangt af van je video-kaart. Die rendert alles en de RAMDAC ! zet de digitale bitjes om in een analoog signaal. Da's voor CRT monitoren althans. DVI stuurt de bitjes direct naar de LCD-electronica.

Al zal er niet gauw 128bits signaal naar je monitor gaan. Weet je hoeveel bandbreedte cq. Video-memory je daar voor nodig hebt ?

Als ze nu al 128 mb /256 Mb gebruiken voor 32bit, heb je al gauw 512 MB / 1 Gig nodig. Zullen de prijzen weer lekker omhoog gaan

[Scipionyx]

Zeg alsjeblieft dat de Parhelia hier baat bij heeft..

[Anoniem: 25643]

Parhelia is 30Bit. Duidelijk niet 128Bit dus.

edit:
30 Kleurbit.
http://www.tweakers.net/nieuws/21916

[MaDMaRTiGaN648]

Waarom denk je dat die nieuwe GPU van Matrox Parhelia-512 heet? Omdat het een 512 bit GPU is!

Dat er 10 bit RGB frame buffers, 10 bit DACs en 10 bit TV encoders gebruikt worden is een ander verhaal...

Maar wat bedoelde Carmack nu eigenlijk met zijn uitspraak?

De Matrox Parhelia-512 GPU beschikt wel degelijk over 128 bit 'Vertex Shader Engines' en een 'Floating Point Setup Engine'. Op de site van Matrox is zelfs te lezen dat het om een "Quad DirectX® 9 Vertex Shader Array" gaat!

Mijn vermoeden is dan ook dat om het alleen om het reken gedeelte gaat en niet om de DAC's etc.

[pblom]

40 toch?

/edit
Als in: De Parhelia is 40bit, toch?

[bolleh]

parhelia is nog gewoon 32 bit, maar niet meer 8-8-8-8(r-g-b-alpha) maar 10-10-10-2

overigens vind ik 128bit ZEEER overdreven. met 48 bit(12-12-12-12)heb je 4096 mogelijkheden per kleur, dat levert al een enorm beter beeld op en bij 64 bit(16-16-16-16) heb je al 65.536 mogelijkheden per kleur.
ik zou liever zien dat ze op intern op 48/64 bit overschakeld omdat het toch weinig uitmaakt, 128bit is overkill.

[PuzzleSolver]

Het gaat om de nauwkeurigheid die overblijft nadat er mee gerekend is en die is afhankelijk van het aantal berekeningen er met de waarde uitgevoerd worden.Aangezien het aantal berekening met de kleuren (ook door de komst van pixel shaders) steeds verder oploopt wordt deze naukeurigheid steeds bellangrijker wan een pixel die 5 keer naar beneden is afgerond naast een die 5 keer naar boven is afgerond valt wel zeker op in 32 bit kleur