nVidia Chief Scientist about color precision: NV30 hint?

Sounds to me like he's prepping us for higher internal precision in the next Nvidia part, but still 8bits per channel in the frame buffer. Whether that means 64bit internal or not is still in question, but I'd lay money on the nv30 having higher internal precision bits.

 

Afaik the Framebuffer doesnt use an alpha channel because it isnt blended again anything.

So imho. a X2R10G10B10 mode definitly would make sense and improve the image quality (you can make 4times more blending operations without image quality loss), but needs more core logic.

(btw. the dx81 reference rasterizer alread supports A2R10G10B10 as render target format)

 

I think someone need to read our preview

Anyway, all the processors are 32bit so 32bit formats are likely to be done in one pass; other formats are achievable by packing bits and breaking them up over a loop in the program. They initially stated that 10:10:10:2 would be supported at launch, as presumably 8:8:8:8 will be; other formats may be supported as/when required. They are implementing these things on a priority basis.

 

Dave, I know P10 has native support for 10:10:10:2 and 8:8:8:8. I was refering to what you just said, if it can do higher precision using multiple passes or combining two pipelines or something like that...

Regards / ushac

 

With all this talk about bits... how does this all fit with the fact that future PS2.0 are floating point ? Are they talking about integer precision ?

G~

 

Sounds like he's afraid Matrox will take away some of Nvidia's marketshare

 

Since we are on the subject of color precision it seems that someone from hardocp thinks that the R300 will be using,"a 128 bit floating point colour system,"


Usually I wouldn't post such drivel,but then it got me thinking that ATI was mostly invovled with the formation of Directx 9 & the maximum color values are 32 bits per channel,which makes this rumour sort of interesting. 8)

 

Well, it should be easy to set the internal precision of a tiler to 16bits/chan or even higher and the advantage in IQ is definately there. Make me wonder why it hasn't been done yet.

 

Why would this be easy on a tiler? To have 16bits/channel precision you need 16 bit arithmetic units regardless of the architecture. Maybe there is a way to combine smaller units, but it will be half the speed.

 

Higher internal accuracy per vertex should just eat binning memory on a tiler/deferred renderer.

 

I think by easy, he means you don't have to pay the off-chip memory bandwidth cost of a 64/128bit framebuffer on a tiler. You have a 64/128bit per pixel tile-buffer, do all rendering at the higher color precision, then you output 32bit (or whatever) pixels for display. As previously stated the extra precision is not needed for the final color values.

 

Indeed, Psurge..

 

hmm. two things about what mr. kirk said.

• how is one to interpret the 'probably won't require multi-pass' part? that developers won't try anything fancy or that whatever the developer comes up with, the card will be capable to loopback accordingly?
• don't know about mr. kirk's display, but most of those i've seen handle perfecltly well 8 bits, at least in the average-luminance range. do the following very trivial test (can be done even in ms pain) - paint a canvas of homogeneous green, say green=127. now, on the foreground paint a smaller rectangle of green=128, and move that rectangle quickly. on my monitor i can clearly see the moving foreground object. IOW, green:127 is clearly discernible from green:128 when in motion on a regular CRT (the one i'm at right now is a 19" kfc)

 

I agree darkblu, but human perception is much more acute to changes in green, attempt the same test with Red or Blue and the difference will be much less noticable (If at all).

It seems we may have a bunch of different formats for color this fall which will win? 10,12,16 Bit and what about the floating point formats 16 or more bits per channel are they out of the question?

 

I wonder where can I find information on the requirement claimed by many, that PS2.0 requires floating point calculation.
I can't find it in the DX9 doc file.

It looks to me (like to most people in this forum) that nv30 will use 16bit/channel internal, and 8bit/channel external. It will possibly support 16bit/channel textures and maybe the same depth as an offscreen rendertarget, but it'll have 8bit DACs.

I disagree.
There'll be more and more effects (eg. particle effects) that use alpha blending, and that requires high precisity framebuffers. Unless nv30 has tile-based rendering which is not likely.
Even Doom3 will use at least one pass per light.

So, while I don't think we need >8bit DACs, I'm certain we need >8bit framebuffers, because of blending.
And since noone uses destination alpha, 10:10:10:2 mode is an excelent compromise it doesn't sacrifice speed, but it allows more precise calculations.

 

yep, 9bits per channel (in the DAC) may suffice. my point being that the perfect (re human color perception) channel resolution may not be nicely quantifiable in finite number of bits, (i.e. the "perfect" channel bitness could be 8.45(3) bits per channel, for instance) so we need to top it from above, although we'd waste a fraction of a bit per channel. in this regard, i believe the use of 10bits-per-channel framebuffers would produce visibly better (i.e. for the unarmed human eye) results that the 8bits-per-channel even if we completely ignore the multi-pass precision issue. as about what suffices for games and what not, don't forget where it all started and where we're today, and imagine where the notion of computer gaming could be tomorrow.

 

my choice of green for the test was exactly for this reason. the fact that human vision is not as sensitive towards red and blue as it is towards green would not relief a visual simulation system from the requirement to represent said color at its best, no?

resources aside, the higher precision the better when non-TBR multipass is involved. IMHO it'd be nice if the 10-bits-per-channel frambuffer becomes the lowest denominator from this year on.

 

Maybe you should look under PS.2.0 register descriptions in the docs .

Yes, but you don't loose that much precision when you just add something to the back buffer, you loose it when you multiply it. Besides if you are on DX9 beta you should probably know what's coming (but if you are not...).