Re: [Mesa3d-dev] read/write_rgba_span_rgba for OSMesa CHAN_BITS=16

[Brian P. <br...@va...>]

"J.P. Delport" wrote:
> 
> Hello,
> 
> I've found that these faster MEMCPY functions were not selected for 16
> (or 32-bit for that matter) bit/channel OSMesa.
> 
> I enabled them by taking out the check for CHAN_BITS==8 in osmesa.c in
> the function osmesa_update_state under where it says /* 4 bytes / pixel
> in frame buffer */ ... This could be renamed 4 GLchan / pixel or
> someting.

Done.


> I also did some GLchan fixes in read/write_rgba_span_rgba in osmesa.c
> 
> The functions appear to work correctly for 16 bit/channel (and should
> for 32 bit). They follow at the bottom. I don't know if the ASSERT in
> the write function can be removed completely.

This is incorrect.  The write_rgba_span_rgba() function will only work
correctly for 8-bit channels.  The reason is we're using a GLuint to
store 4 8-bit channels at once as a dword.  By storing 4 bytes at once
(without any swizzling) we can get slightly better performance.  But
if we're storing > 4 bytes or need swizzling, we need to use the slower
write_rgba_span() function.


> I was also playing around with compiling the osmesa lib with
> CHAN_BITS=32 and it broke quite a lot of functions mainly at bit shifts.
> How can I compile the lib with some functions modified (the ones that
> are going to be called by my 32bit/chan program for checking) and some
> others unchanged? Can I safely #if functions out that would not compile
> with CHAN_BITS=32, but that are not going to be called? I'm interested
> in getting 32bit/chan smoothed triangles rendered.

CHAN_BITS=32 doesn't work yet.  It'll require a lot of changes that
I haven't implemented yet.  Specifically, the triangle and line
rasterization templates use fixed-point arithmetic for color interpolation.
That'll all need to be changed for 32-bit floating point colors.

-Brian