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
pgp7RmuUrcEbj.pgp
Description: PGP signature
