Proprosed break in libGL / DRI driver ABI

Brian Paul brian.paul at tungstengraphics.com
Wed Apr 6 16:21:00 PDT 2005


Roland Mainz wrote:
> Brian Paul wrote:
> [snip]
> 
>>>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.
>>
>>This is separate from Ian's ABI discussion.  It's true that core Mesa
>>has to be recompiled to support 8, 16 or 32-bit color channels.
>>That's something I'd like to change in the future.  It will be a lot
>>of work but it can be done.
>>
>>Currently, there aren't any hardware drivers that support > 8-bit
>>color channels.
> 
> 
> Doesn't Nvidia support >24bit RGB ? In general there is some hardware
> out there (my favorite example are Sun's XVR-1000/-4000 framebuffer
> series) which would require support for 30bit (or deeper) RGB in Mesa
> first...

I was talking about the existing DRI hardware drivers.  I know there's 
other hardware with deeper color channels.



>>If we did want to support deeper channels in a
>>hardware driver we'd have a lot of work to do in any case.  One
>>approach would be to compile core Mesa for 16-bit channels, then
>>shift/drop bits in the driver whenever we write to a color buffer.  Of
>>course, there's more to it than that, but it would be feasible.
> 
> 
> What about the software rasterizer ? Would it be possible to run it in
> 30bit TrueColor right now ?

No.  The only way to use deeper than 8-bit channels right now is with 
OSMesa and recompiling Mesa for 16 or 32-bit channels.

-Brian


More information about the xorg-arch mailing list