Proprosed break in libGL / DRI driver ABI

[Brian Paul]

Nicolai Haehnle wrote:
> On Tuesday 05 April 2005 22:11, Brian Paul wrote:
> 
>>If you increase MAX_WIDTH/HEIGHT too far, you'll start to see 
>>interpolation errors in triangle rasterization (the software 
>>routines).  The full explanation is long, but basically there needs to 
>>be enough fractional bits in the GLfixed datatype to accomodate 
>>interpolation across the full viewport width/height.
>>
>>In fact, I'm not sure that we've already gone too far by setting 
>>MAX_WIDTH/HEIGHT to 4096 while the GLfixed type only has 11 fractional 
>>bits.  I haven't heard any reports of bad triangles so far though. 
>>But there probably aren't too many people generating 4Kx4K images.
>>
>>Before increasing MAX_WIDTH/HEIGHT, someone should do an analysis of 
>>the interpolation issues to see what side-effects might pop up.
>>
>>Finally, Mesa has a number of scratch arrays that get dimensioned to 
>>[MAX_WIDTH].  Some of those arrays/structs are rather large already.
> 
> 
> Slightly off-topic, but a thought that occured to me in this regard was to 
> tile rendering. Basically, do a logical divide of the framebuffer into 
> rectangles of, say, 64x64 pixels. During rasterization, all primitives are 
> split according to those tiles and rendered separately. This has some 
> advantages:
> 
> a) It could help reduce the interpolation issues you mentioned. It's 
> obviously not a magic bullet, but it can avoid the need for insane 
> precision in inner loops.
> c) Better control of the size of scratch structures, possibly even better 
> caching behaviour.
> b) One could build a multi-threaded rasterizer (where work queues are per 
> framebuffer tile), which is going to become all the more interesting once 
> dualcore CPUs are widespread.

This would be FAR more work than simply addressing the interpolation 
issue.  There's lots of subtle conformance issues with the tiling 
approach you suggest.  Consider something simple like line stipples.

-Brian