Proprosed break in libGL / DRI driver ABI

Adam Jackson ajax at nwnk.net
Tue Apr 5 17:31:55 PDT 2005


On Tuesday 05 April 2005 16:11, Brian Paul wrote:
> Roland Mainz wrote:
> > Another item would be to look into what's required to support visuals
> > beyond 24bit RGB (like 30bit TrueColor visuals) ... someone on IRC
> > (AFAIK ajax (if I don't mix-up the nicks again :)) said that this may
> > require an ABI change, too...
>
> I doubt an ABI change would be needed for that.

Are you sure about this?

I thought we treated channels as bytes everywhere, unless GLchan was defined 
to something bigger, and even then only for OSMesa.  Even if it's not an ABI 
change, I suspect that growing GLchan beyond 8 bits while still preserving 
performance is non-trivial.

> > When I look at xc/extras/Mesa/src/mesa/main/config.h I see more items on
> > my wishlist: Would it be possible to increase |MAX_WIDTH| and
> > |MAX_HEIGHT| (and the matching texture limits of the software
> > rasterizer) to 8192 to support larger displays (DMX, Xinerama and Xprint
> > come in mind) ?
>
> 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.

Yet.  Big images are becoming a reality.  DMX+glxproxy brings this real close 
to home.

> Before increasing MAX_WIDTH/HEIGHT, someone should do an analysis of
> the interpolation issues to see what side-effects might pop up.

Definitely.

> Finally, Mesa has a number of scratch arrays that get dimensioned to
> [MAX_WIDTH].  Some of those arrays/structs are rather large already.

I looked into allocating these dynamically, but there were one or two sticky 
points (mostly related to making scope act the same) so I dropped it.  It 
could be done though.

- 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/20050405/5bd35280/attachment.pgp


More information about the xorg-arch mailing list