mesa3d-dev

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: mesa_3_4_branch)

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

Jacob Jansen wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/vms/
> Changes by:     joukj@usw-pr-cvs1.      01/02/09 00:25:18
> 
> Modified files:
>       Mesa/demos/:      Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/src/:        Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/src/X/:      Tag: mesa_3_4_branch
>         glxheader.h xfonts.c xfonts.h
>       Mesa/src-glu/:    Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/src-glut/:   Tag: mesa_3_4_branch
>         descrip.mms
>       Mesa/vms/:        Tag: mesa_3_4_branch
>         analyze_map.com xlib_share.opt
> Added files:
>       Mesa/include/GL/: Tag: mesa_3_4_branch
>         vms_x_fix.h
> 
>   Revision      Changes    Path
>   1.1.1.1.6.1   +158 -41   Mesa/demos/descrip.mms
>   1.13.4.1      +1 -1      Mesa/src/descrip.mms
>   1.1.4.1       +5 -1      Mesa/src/X/glxheader.h
>   1.6.4.4       +6 -1      Mesa/src/X/xfonts.c
>   1.1.4.1       +5 -1      Mesa/src/X/xfonts.h
>   1.4.4.1       +137 -21   Mesa/src-glu/descrip.mms
>   1.2.6.1       +139 -121  Mesa/src-glut/descrip.mms
>   1.2.6.1       +4 -1      Mesa/vms/analyze_map.com
>   1.1.6.1       +2 -0      Mesa/vms/xlib_share.opt
> 
> Log message:
>    Modified Files:
>     Tag: mesa_3_4_branch
>         Mesa/demos/descrip.mms Mesa/src/descrip.mms
>         Mesa/src/X/glxheader.h Mesa/src/X/xfonts.c Mesa/src/X/xfonts.h
>         Mesa/src-glu/descrip.mms Mesa/src-glut/descrip.mms
>         Mesa/vms/analyze_map.com Mesa/vms/xlib_share.opt
>    Added Files:
>     Tag: mesa_3_4_branch
>         Mesa/include/GL/vms_x_fix.h
> 
>    backported from version 3.5 some VMS compile issues


It looks like the vms_x_fix.h file is only included by files in
the Mesa/src/X/ directory.  Is vms_x_fix.h ever included by client
programs?  If not, vms_x_fix.h should be moved to Mesa/src/X/.
The headers in Mesa/include/GL are meant to be public headers
which may be included by client programs, not headers internal
to Mesa.

-Brian

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: mesa_3_4_branch)

[David S. M. <da...@re...>]

Brian Paul writes:
 > Log message:
 >   use unoptimized COPY_4UBV code on SPARC to avoid memory alignment problems (bug 430689)

This is surely not a Sparc specific problem.

Any RISC machine is going to take an exception if you access unaligned
bytes as a word.  Only on x86 is this optimization going to work
reliably.

On some RISC machines, such unaligned loads work from the user's
perspective, but these "work" by trapping into the kernel to get
"fixed up".  This could lead to hard to detect performance problems in
Mesa.

I would suggest disabling this optimization on all non-x86 systems.

Later,
David S. Miller
da...@re...

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: mesa_3_4_branch)

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

"David S. Miller" wrote:
> 
> Brian Paul writes:
>  > Log message:
>  >   use unoptimized COPY_4UBV code on SPARC to avoid memory alignment problems (bug 430689)
> 
> This is surely not a Sparc specific problem.
> 
> Any RISC machine is going to take an exception if you access unaligned
> bytes as a word.  Only on x86 is this optimization going to work
> reliably.
> 
> On some RISC machines, such unaligned loads work from the user's
> perspective, but these "work" by trapping into the kernel to get
> "fixed up".  This could lead to hard to detect performance problems in
> Mesa.
> 
> I would suggest disabling this optimization on all non-x86 systems.

Good point.  Other than x86 I only occasionally test Mesa on a
MIPS-based SGI system- though it hasn't been a problem there (might
just be getting lucky).  But I know that alignment is important on
most RISC systems.  I'll change the test.

-Brian

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

[J.P. D. <jpd...@cs...>]

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.

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.

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.

cheers
jp

read/write functions:

/* Write RGBA pixels to an RGBA buffer.  This is the fastest
span-writer. */
static void
write_rgba_span_rgba( const GLcontext *ctx, GLuint n, GLint x, GLint y,
                      CONST GLchan rgba[][4], const GLubyte mask[] )
{
   OSMesaContext osmesa = OSMESA_CONTEXT(ctx);
   GLchan *ptr4 = PIXELADDR4(x, y);
   GLuint i;
   /*ASSERT(CHAN_TYPE == GL_UNSIGNED_BYTE);*/
   if (mask) {
     for (i = 0; i < n; i++, ptr4 += 4) {
         if (mask[i]) {
            PACK_RGBA(ptr4, rgba[i][RCOMP], rgba[i][GCOMP],
                         rgba[i][BCOMP], rgba[i][ACOMP]);
         }
      } 
   }
   else {
      MEMCPY( ptr4, rgba, n * 4 * sizeof(GLchan));
   }
}

/* Read RGBA pixels from an RGBA buffer */
static void
read_rgba_span_rgba( const GLcontext *ctx, GLuint n, GLint x, GLint y,
                     GLchan rgba[][4] )
{
   OSMesaContext osmesa = OSMESA_CONTEXT(ctx);
   GLchan *ptr4 = PIXELADDR4(x, y);
   MEMCPY( rgba, ptr4, n * 4 * sizeof(GLchan) );
}

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

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

[J.P. D. <jpd...@cs...>]

Brian Paul wrote:
> 
> "J.P. Delport" wrote:
>
> > 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.

Sorry, I missed the idea behind the use of the GLint. Still, the case
for CHAN_BITS=16 with no swizzling is also a special case and could be
made faster by using MEMCPY, escpecially when there is no mask.

Also: in the function write_rgb_span the alpha values passed to
PACK_RGBA are 255???

jp

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

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

"J.P. Delport" wrote:
> 
> Brian Paul wrote:
> >
> > "J.P. Delport" wrote:
> >
> > > 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.
> 
> Sorry, I missed the idea behind the use of the GLint. Still, the case
> for CHAN_BITS=16 with no swizzling is also a special case and could be
> made faster by using MEMCPY, escpecially when there is no mask.

Yes, that could be done.  Feel free to submit a patch. :)


> Also: in the function write_rgb_span the alpha values passed to
> PACK_RGBA are 255???

I'm replacing 255 with CHAN_MAX.  Thanks.

-Brian