[offtopic] Re: Proprosed break in libGL / DRI driver ABI

Adam Jackson ajax at nwnk.net
Thu Apr 7 10:29:21 PDT 2005


On Thursday 07 April 2005 12:53, Allen Akin wrote:
> Tiling involves some subtle tradeoffs.  The OpenGL spec requires that
> the pixel fragments generated by rasterization be unaffected if
> primitives are translated by an integral amount in screen coordinates,
> or if scissoring is enabled.  Those two requirements are intended to
> make it possible to tile rendering without generating visible seams at
> the tile boundaries.  But the same requirements would have to be met by
> a higher-level utility if you want to do tiling there, and it may not be
> possible to meet them if the underlying OpenGL renderer doesn't offer
> enough coordinate and color (etc.) precision to the higher-level
> utility.

I would think it possible to decompose the scene along notional view volumes 
in the tiler, translating the coordinates of each vertex relative to the view 
volume.  The tiler wouldn't need excessive precision because it has the 
original coordinates in the final scene's space; and the rasteriser wouldn't 
need excessive precision because it can only ever do (say) 2048 steps along a 
given axis.  There are precision issues in making sure the view volumes align 
correctly, but they're not as extreme.

I don't know if glxproxy does this yet.  It arguably should for performance 
reasons, because the border of each view volume is a clip plane, so when 
you're distributing the rasterisation you can cull huge portions of your 
scene from each brick.

I don't know that the rasteriser is the right place to solve this problem.  
Eventually X will outgrow the 15-bit coordinate limit, and/or Roland will 
want to do 1440dpi on A4 or whatever.  So it's not about asking for 12 bits 
of fragment precision as opposed to 11, it's about asking for infinite 
precision.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-arch/attachments/20050407/ac229888/attachment.pgp


More information about the xorg-arch mailing list