amount of bits used inside rasterizer fixed point path of traversal

nirradi

Newcomer
Could anyone comment even roughly on the amount of bits used inside rasterizer fixed point path of traversal and interpolation of attributes? i am finiding it difficult to
A) move the input into this process from floating point vertex attributes which have high dynamic ranges and
B) decide how many bits i should keep while traversing a sometimes large triangle
 
Nowadays the norm is keeping full 32-bit floating-point precision throughout the entire pipeline. Only in very specific cases it's possible to use integer or fixed-point formats without loss of precision.

Is there any specific reason why you're limited to fixed-point rasterization?
 
Nick, thanks for the reply – really appreciate it.
Let me get this straight though - a scan conversion algorithm like centerline, not to mention a recursive tiled walk, is implemented in full single precision float and fully pipelined? With all ~24 (4-float) attributes interpolated perspective-correctly it sounds unfeasible in HW.
Moreover, analyzing precision of a floating point implementation (at least one based on IEEE 754) of an iterative walking algorithm over a large triangle is, to say the least, very difficult. And experiments suggest single precision doesn’t seem to cut it for the more demanding resolutions. Using more than 32bit floats sounds insane. How do people in mobile or lower end PC get this done? I don’t see even high end PC/console affording such logic.
 
Moreover, analyzing precision of a floating point implementation (at least one based on IEEE 754) of an iterative walking algorithm over a large triangle is, to say the least, very difficult. And experiments suggest single precision doesn’t seem to cut it for the more demanding resolutions. Using more than 32bit floats sounds insane. How do people in mobile or lower end PC get this done? I don’t see even high end PC/console affording such logic.

Instead of the interpolants you can walk the barycentric coordinates of the triangle then at each fragment directly compute the interpolants from them. Precision is improved since each barycentric coordinate will be in the range (0,1) for all covered pixels. It's more math ops but nothing that dedicated hardware couldn't handle.
 
That makes more sense. What about walking the baricoords - seems like fix point would do fine, so Nick meant that parameter inteprolation is fully floatish while traversal is fixed?
 
Back
Top