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