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