mesa3d-dev

Re: [Mesa3d-dev] bugs

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> Since some time (around the same time all the software rastering was put
> in separate directories) I observe the following 2 problems which may or may
> not be related:
>    To test I use the program xlockmore (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
> 
>  problems :
>     -in mode moebius a part of the edge is not drawn resulting in a zig-zag
>       line. Mesa3.4 draws it correct

This looks like a glPolygonMode() bug.  The interior edges in the quad
strip shouldn't be rendered.  Keith could probably find this pretty
quickly.


>     -Occasional xlock crashes in the GL modes due to invalid floats and
>      access violation. I have no idea where to look for the error since
>      normal error messages are not given. So probably a memory leak overwrites
>      the program.

Which modes or programs in particular cause this?

-Brian

Re: [Mesa3d-dev] Mesa without GLX

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

Emmanuel Mogenet wrote:
> 
> Is there a way to recompile Mesa so
> that it uses pure X calls and doesn't try
> to use the GLX extension ?

I'm assuming that you're talking about stand-alone Mesa, not the DRI version.

Stand-alone Mesa implements the GLX API but not the GLX X extension
or GLX protocol.  All the gl* and glX* API calls are eventually
translated into ordinary Xlib library calls.


> The reasons for this request are twofold:
> 
>         1. It has been my experience that more
>            often than not, OpenGL problems with Linux
>            are generally bugs in the GLX layer. It can
>            go from incorrect display to machine reboots.

Can you be more clear?  I'm not sure if you're talking about runtime/
rendering errors or install/configuration problems.

 
>         2. I'm not interested in Mesa's performances, but in
>          its render correctness: I use Mesa as a measuring
>          stick to check other HW accelerated OpenGL implementations.
> 
>         3. I have a couple of machines on my LAN with no GLX extension
>          whatsoever, and I often need to launch a Linux-based Mesa-linked
>          app with it's display on that GLX-less remote head. And I can't.

Stand-alone Mesa can do this.  The X server does not need to have the
GLX extension.

Actually, it sounds like you are using the XFree86/DRI libGL which
does require the GLX extension.  If that's what you're using, download
the Mesa 3.4 distro and give it a try.

Just be careful that you use the right libGL.so then.  That's a
really common cause of confusion.

If you're with me so far, here's some more info:  RedHat 7.0 shipped
a special libGL.so that's a hybrid of the XFree86/DRI libGL and stand-
alone Mesa's libGL.so.  It looks to see if the X server has the GLX
extension and uses the XFree86/DRI code if it can.  Otherwise, it falls
back to stand-alone Mesa's Xlib rendering code.

I wasn't involved in constructing this hybrid libGL so I'm hesitant
to get too involved in it.

-Brian

[Mesa3d-dev] Mesa without GLX

[Emmanuel M. <mg...@no...>]

Is there a way to recompile Mesa so
that it uses pure X calls and doesn't try
to use the GLX extension ?

The reasons for this request are twofold:

	1. It has been my experience that more
	   often than not, OpenGL problems with Linux
	   are generally bugs in the GLX layer. It can
         go from incorrect display to machine reboots.

	2. I'm not interested in Mesa's performances, but in
         its render correctness: I use Mesa as a measuring
         stick to check other HW accelerated OpenGL implementations.

	3. I have a couple of machines on my LAN with no GLX extension
         whatsoever, and I often need to launch a Linux-based Mesa-linked
         app with it's display on that GLX-less remote head. And I can't.


Any help, and/or pointers appreciated.

	- Emmanuel

Re: [Mesa3d-dev] s_texture.c

[Daniel V. <vo...@lo...>]

On Thu, Dec 14, 2000 at 01:29:32PM -0700, Brian Paul wrote:
> 
> I just checked in some changes.  Want to give it a try again?

Fixes the segfault but is still blurry.



                            Daniel Vogel, Programmer, Loki Software Inc.

Re: [Mesa3d-dev] s_texture.c

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

Daniel Vogel wrote:
> 
> On Thu, Dec 14, 2000 at 12:49:45PM -0700, Brian Paul wrote:
> >
> > I should rename _P to _q (which is what the 1.2 spec uses now).  q is the
> > highest-numbered mipmap level that can actually be used, after taking in
> > account the image sizes and the value of GL_TEXTURE_MAX_LEVEL.
> >
> > _M is the max usable lambda value.  It should be = _MaxLevel - BaseLevel.
> > If you're looking at equation 3.21 in the 1.2 spec, then _M = q - b.  I
> > should probably rename that variable too (_MaxLambda).
> >
> > The incoming lambda value is added to BaseLevel to select a mipmap level.
> >
> > The idea is that lambda=0 will correspond to the BaseLevel texture
> > and lambda = _M will correspond to the GL_MAX_LEVEL texture.
> 
> Thanks.
> 
> > I'm not sure why you're seeing blurry images.  I haven't tried running
> > UT with 3.5 yet.
> 
> Most noticeable with the floor textures in DM-Stalwart.


I just checked in some changes.  Want to give it a try again?

-Brian

Re: [Mesa3d-dev] s_texture.c

[Daniel V. <vo...@lo...>]

On Thu, Dec 14, 2000 at 12:49:45PM -0700, Brian Paul wrote:
> 
> I should rename _P to _q (which is what the 1.2 spec uses now).  q is the
> highest-numbered mipmap level that can actually be used, after taking in
> account the image sizes and the value of GL_TEXTURE_MAX_LEVEL.
> 
> _M is the max usable lambda value.  It should be = _MaxLevel - BaseLevel.
> If you're looking at equation 3.21 in the 1.2 spec, then _M = q - b.  I
> should probably rename that variable too (_MaxLambda).
> 
> The incoming lambda value is added to BaseLevel to select a mipmap level.
> 
> The idea is that lambda=0 will correspond to the BaseLevel texture
> and lambda = _M will correspond to the GL_MAX_LEVEL texture.

Thanks.

> I'm not sure why you're seeing blurry images.  I haven't tried running
> UT with 3.5 yet.

Most noticeable with the floor textures in DM-Stalwart.



                            Daniel Vogel, Programmer, Loki Software Inc.

Re: [Mesa3d-dev] stupid question on cvs branches

[emanuel s. <em...@ec...>]

Brian Paul wrote:
> 
> emanuel stiebler wrote:
> >
> > Hi,
> > Just because I don't get it right at the moment ;-)
> >
> > The actual branches are (?):
> >
> > mesa_3_4_dev , which is a mesa3.4 with patches ?
> 
> It's actually mesa_3_4_branch.
> 
> > mesa_3_5_dev is the developer "tag"  for the next version ?
> 
> No, the trunk has the latest 3.5 development sources.
> 
> > Which on to use, when I like to use the newest stable version ?
> 
> mesa_3_4_branch has the latest stable code.

OK, Thanks. Now a cvs checkout & update worked.

Anybody working on WIN32 support ?

cheers,
emanuel

Re: [Mesa3d-dev] s_texture.c

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

Daniel Vogel wrote:
> 
> On Thu, Dec 14, 2000 at 10:16:58AM -0700, Brian Paul wrote:
> >
> > Are you settting GL_TEXTURE_BASE_LEVEL?
> 
> No, I only set GL_TEXTURE_MAX_LEVEL and cut off the last two mip levels.
> It also looks like the filters use the wrong base mipmap. Everything
> looks overblurry from an angle and a naive guess would be that it's
> taking everything 2 levels too far down.
> 
> > I think I see an error in the calculation in _P.  I think I should
> > add the base level to it.  However, that would increase _P.
> 
> from mtypes.h:
> 
>    GLint _P;                    /* Highest mipmap level */
>    GLfloat _M;                  /* = MIN(MaxLevel, P) - BaseLevel */
> 
> What do _P and _M actually mean? Is _P the highest mip level based on
> the size of the image (e.g. 5 for 32x32) and _M supposed to be the one
> after "clipping"?

I should rename _P to _q (which is what the 1.2 spec uses now).  q is the
highest-numbered mipmap level that can actually be used, after taking in
account the image sizes and the value of GL_TEXTURE_MAX_LEVEL.

_M is the max usable lambda value.  It should be = _MaxLevel - BaseLevel.
If you're looking at equation 3.21 in the 1.2 spec, then _M = q - b.  I
should probably rename that variable too (_MaxLambda).

The incoming lambda value is added to BaseLevel to select a mipmap level.

The idea is that lambda=0 will correspond to the BaseLevel texture
and lambda = _M will correspond to the GL_MAX_LEVEL texture.

I'm not sure why you're seeing blurry images.  I haven't tried running
UT with 3.5 yet.

-Brian

Re: [Mesa3d-dev] s_texture.c

[Daniel V. <vo...@lo...>]

On Thu, Dec 14, 2000 at 10:16:58AM -0700, Brian Paul wrote:
> 
> Are you settting GL_TEXTURE_BASE_LEVEL?

No, I only set GL_TEXTURE_MAX_LEVEL and cut off the last two mip levels.
It also looks like the filters use the wrong base mipmap. Everything
looks overblurry from an angle and a naive guess would be that it's
taking everything 2 levels too far down.

> I think I see an error in the calculation in _P.  I think I should
> add the base level to it.  However, that would increase _P.

from mtypes.h:

   GLint _P;			/* Highest mipmap level */
   GLfloat _M;			/* = MIN(MaxLevel, P) - BaseLevel */

What do _P and _M actually mean? Is _P the highest mip level based on
the size of the image (e.g. 5 for 32x32) and _M supposed to be the one
after "clipping"?



                            Daniel Vogel, Programmer, Loki Software Inc.

Re: [Mesa3d-dev] stupid question on cvs branches

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

emanuel stiebler wrote:
> 
> Hi,
> Just because I don't get it right at the moment ;-)
> 
> The actual branches are (?):
> 
> mesa_3_4_dev , which is a mesa3.4 with patches ?

It's actually mesa_3_4_branch.


> mesa_3_5_dev is the developer "tag"  for the next version ?

No, the trunk has the latest 3.5 development sources.


> Which on to use, when I like to use the newest stable version ?

mesa_3_4_branch has the latest stable code.

-Brian

[Mesa3d-dev] stupid question on cvs branches

[emanuel s. <em...@ec...>]

Hi,
Just because I don't get it right at the moment ;-)

The actual branches are (?):

mesa_3_4_dev , which is a mesa3.4 with patches ?

mesa_3_5_dev is the developer "tag"  for the next version ?

Which on to use, when I like to use the newest stable version ?

cheers & thanks,
emanuel

Re: [Mesa3d-dev] s_texture.c

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

Daniel Vogel wrote:
> 
> hi`
> 
> I tried running UT with the Mesa software renderer and when I turned on
> trilinear filtering it crashed in sample_2d_linear being called with a
> NULL pointer for the image from sample_2d_linear_mipmap_linear. The
> problem seems to be that UT uses GL_TEXTURE_MAX_LEVEL and tObj->_P was 7
> and tObj->_M was 5. From what I can read in mtypes.h shouldn't _M be
> used instead of _P in the following code? Changing the code to use _M at
> least made it work ;) BTW, why is _M a float and not an integer?
> 
> s_texture.c:840 [sample_2d_linear_mipmap_linear]
> 
> if (level >= tObj->_P) {
>    sample_2d_linear( tObj, tObj->Image[tObj->_P], s, t, rgba);
> }
> else {
>    GLchan t0[4], t1[4];  /* texels */
>    const GLfloat f = myFrac(lambda);
>    sample_2d_linear( tObj, tObj->Image[level  ], s, t, t0 );
>    sample_2d_linear( tObj, tObj->Image[level+1], s, t, t1 );
>    rgba[RCOMP] = (GLchan) (GLint) ((1.0F-f) * t0[RCOMP] + f * t1[RCOMP]);
>    rgba[GCOMP] = (GLchan) (GLint) ((1.0F-f) * t0[GCOMP] + f * t1[GCOMP]);
>    rgba[BCOMP] = (GLchan) (GLint) ((1.0F-f) * t0[BCOMP] + f * t1[BCOMP]);
>    rgba[ACOMP] = (GLchan) (GLint) ((1.0F-f) * t0[ACOMP] + f * t1[ACOMP]);
> }


Are you settting GL_TEXTURE_BASE_LEVEL?

I think I see an error in the calculation in _P.  I think I should
add the base level to it.  However, that would increase _P.

I'll have to review the spec and write a test program.  I do think
there is a bug here.  Thanks for flagging it.

-Brian

[Mesa3d-dev] s_texture.c

[Daniel V. <vo...@lo...>]

hi`

I tried running UT with the Mesa software renderer and when I turned on
trilinear filtering it crashed in sample_2d_linear being called with a
NULL pointer for the image from sample_2d_linear_mipmap_linear. The
problem seems to be that UT uses GL_TEXTURE_MAX_LEVEL and tObj->_P was 7
and tObj->_M was 5. From what I can read in mtypes.h shouldn't _M be
used instead of _P in the following code? Changing the code to use _M at
least made it work ;) BTW, why is _M a float and not an integer?


s_texture.c:840 [sample_2d_linear_mipmap_linear]

if (level >= tObj->_P) {
   sample_2d_linear( tObj, tObj->Image[tObj->_P], s, t, rgba);
}
else {
   GLchan t0[4], t1[4];  /* texels */
   const GLfloat f = myFrac(lambda);
   sample_2d_linear( tObj, tObj->Image[level  ], s, t, t0 );
   sample_2d_linear( tObj, tObj->Image[level+1], s, t, t1 );
   rgba[RCOMP] = (GLchan) (GLint) ((1.0F-f) * t0[RCOMP] + f * t1[RCOMP]);
   rgba[GCOMP] = (GLchan) (GLint) ((1.0F-f) * t0[GCOMP] + f * t1[GCOMP]);
   rgba[BCOMP] = (GLchan) (GLint) ((1.0F-f) * t0[BCOMP] + f * t1[BCOMP]);
   rgba[ACOMP] = (GLchan) (GLint) ((1.0F-f) * t0[ACOMP] + f * t1[ACOMP]);
}

 

                            Daniel Vogel, Programmer, Loki Software Inc.

Re: [Mesa3d-dev] Re: bugs

[<jo...@hr...>]

br...@va... wrote on 12-DEC-2000 18:18:30.50
To:	"Jacob (=Jouk) Jansen" <jo...@hr...>
CC:	
Subj:	Re: [Mesa3d-dev] Re: bugs

>"Jacob (=Jouk) Jansen" wrote:
>> 
>> kl...@ma... wrote on 11-DEC-2000 12:10:03.80
>> >> -in mode moebius a part of the edge is not drawn resulting in a zig-zag
>> >   line. Mesa3.4 draws it correct
>> >
>> >Maybe it is because of a change I made sometime ago: Do you use GL_NEAREST for texturing both for min and max texturing-mode? Is this zig-zag line only one pixel-big, i.e. if you change the size of the window, does this zig-zag-pattern scale, too, or n
>ot?
>> >
>> >If both things are the case, then the bugs will disappear soon.
>> Probably this is the case.
>>  The zig-zag is of course part of the correct picture but the curve connecting
>>  the points of the zig-zag is missing in part.
>> 
>Have you tried Mesa since yesterday's check-ins?  I disabled the two
>optimized textured triangle functions that were generated inaccurate
>texture coords.

Even in the CVS version of th morning (MET) I saw the problems.

                     Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Re: bugs

[<jo...@hr...>]

kl...@ma... wrote on 12-DEC-2000 17:16:04.98
>Thanks for your pictures. I looked at them, but I'm not sure anymore if this error has to do with my changes. 
>
>I would be very happy if you could try to download the file
>
>http://www.math.leidenuniv.nl/~klaus/s_triangle.c
>
>and copy it to the directory Mesa/src/swrast/s_triangle.c, recompile everything and see if it works now correctly. I dropped all the changes I once made and if the error is gone then it is my fault.
Did this but it does not help

         Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Re: bugs

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

"Jacob (=Jouk) Jansen" wrote:
> 
> kl...@ma... wrote on 11-DEC-2000 12:10:03.80
> >> -in mode moebius a part of the edge is not drawn resulting in a zig-zag
> >   line. Mesa3.4 draws it correct
> >
> >Maybe it is because of a change I made sometime ago: Do you use GL_NEAREST for texturing both for min and max texturing-mode? Is this zig-zag line only one pixel-big, i.e. if you change the size of the window, does this zig-zag-pattern scale, too, or not?
> >
> >If both things are the case, then the bugs will disappear soon.
> Probably this is the case.
>  The zig-zag is of course part of the correct picture but the curve connecting
>  the points of the zig-zag is missing in part.
> 

Jouk,

Have you tried Mesa since yesterday's check-ins?  I disabled the two
optimized textured triangle functions that were generated inaccurate
texture coords.

-Brian

[Mesa3d-dev] Re: [Mesa3d-cvs] 'Mesa/include/GL Makefile.am'

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

[I'm moving this thread to mesa3d-dev]

"Jon M. Taylor" wrote:
> 
> On Mon, 11 Dec 2000, Brian Paul wrote:
> 
> > jt...@us... wrote:
> > >
> > > Update of /cvsroot/mesa3d/Mesa/include/GL
> > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv8112/include/GL
> > >
> > > Modified Files:
> > >         Makefile.am
> > > Log Message:
> > > Added a new configure.in flag, --enable-glut-build.
> > > This defaults to "off", so GLUT is not built by default.
> >
> > Why did you do this?
> 
> 1: There are several alternate version of GLUT present in the CVS
> tree, and there's no way to select which one to build right now.  If the
> "standard" GLUT (Mesa/src-glut) is built and installed (which was done by
> default), it wipes out any previously-installed libglut.so.

I wouldn't worry about the other versions of glut.


> 2: Many people don't need or want GLUT built in the first place, and it is
> used only for the demos.  It seems to be something of a standard in other
> packages built with auto* scripts to not build demos by default, so....
> 
> 3: I suppose that the "correct" solution would involve extending
> src-glut/* to be able to support GGI, BeOS, Win32, DJGPP, etc etc with a
> compile-time switch, but that's up to whoever's maintaining the GLUT
> sources.
> 
>         If you have any suggestions for neatening this up in a better way,
> please let me know.  I guess I could default it to "on" if you want.

So, what's the make <target> for building GLUT and the demos?

How about this:  build libGL and libGLU always.  Use 'make glut' to
build libglut.  Use 'make demos' to build GLUT and the demos.

-Brian

Re: [Mesa3d-dev] Re: bugs

[<jo...@hr...>]

kl...@ma... wrote on 11-DEC-2000 12:10:03.80
>> -in mode moebius a part of the edge is not drawn resulting in a zig-zag
>   line. Mesa3.4 draws it correct
>
>Maybe it is because of a change I made sometime ago: Do you use GL_NEAREST for texturing both for min and max texturing-mode? Is this zig-zag line only one pixel-big, i.e. if you change the size of the window, does this zig-zag-pattern scale, too, or not?
>
>If both things are the case, then the bugs will disappear soon.
Probably this is the case.
 The zig-zag is of course part of the correct picture but the curve connecting
 the points of the zig-zag is missing in part.

             Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] glxext.h

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> The new glx-header files give a lot of problems compiling glut:
>   -Defining GLX_SGIS_multisample results in an undefined
>     GLX_SAMPLES_SGIS
>    in i.e. GLUT_DSTR.C.
>   -defining GLX_SGIX_video_resize or GLX_SYNC_FRAME_SGIX results in undefined
>    functions :
>          glXBindChannelToWindowSGIX
>          glXChannelRectSGIX
>          glXChannelRectSyncSGIX
>          glXQueryChannelDeltasSGIX
>          glXQueryChannelRectSGIX
>   -defining GLX_SGIX_fbconfig results in undefined functions :
>          glXCreateContextWithConfigSGIX
>          glXGetFBConfigAttribSGIX
>          glXGetFBConfigFromVisualSGIX


Two problems:

1. glut_dstr.c shouldn't include glx.h since glutint.h already includes it.
I've fixed glut_dstr.c

2. The glxext.h file is broken.  It #defines GLX_SGIS_multisample but
doesn't define any of the extension's new tokens.  I've made a temporary
fix and will report the problem to SGI.

-Brian

[Mesa3d-dev] Re: bugs

[Klaus N. <kl...@ma...>]

> -in mode moebius a part of the edge is not drawn resulting in a zig-zag
   line. Mesa3.4 draws it correct

Maybe it is because of a change I made sometime ago: Do you use GL_NEAREST for texturing both for min and max texturing-mode? Is this zig-zag line only one pixel-big, i.e. if you change the size of the window, does this zig-zag-pattern scale, too, or not?

If both things are the case, then the bugs will disappear soon.

Brian? If you want I can remove my routine and send you the new file or will you do it?

Klaus

[Mesa3d-dev] bugs

[<jo...@hr...>]

Hi all,

Since some time (around the same time all the software rastering was put
in separate directories) I observe the following 2 problems which may or may
not be related:
   To test I use the program xlockmore (see ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/

 problems :
    -in mode moebius a part of the edge is not drawn resulting in a zig-zag
      line. Mesa3.4 draws it correct
    -Occasional xlock crashes in the GL modes due to invalid floats and
     access violation. I have no idea where to look for the error since
     normal error messages are not given. So probably a memory leak overwrites
     the program.


          Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

[Mesa3d-dev] glxext.h

[<jo...@hr...>]

Hi all,

The new glx-header files give a lot of problems compiling glut:
  -Defining GLX_SGIS_multisample results in an undefined
    GLX_SAMPLES_SGIS
   in i.e. GLUT_DSTR.C.
  -defining GLX_SGIX_video_resize or GLX_SYNC_FRAME_SGIX results in undefined
   functions :
         glXBindChannelToWindowSGIX
         glXChannelRectSGIX
         glXChannelRectSyncSGIX
         glXQueryChannelDeltasSGIX
         glXQueryChannelRectSGIX
  -defining GLX_SGIX_fbconfig results in undefined functions :
         glXCreateContextWithConfigSGIX
         glXGetFBConfigAttribSGIX
         glXGetFBConfigFromVisualSGIX
  
  
                   Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Lighting code in 3.5

[Gareth H. <ga...@va...>]

Keith Whitwell wrote:
> 
> The early culling code turned out to be a dead end in the face of assembly,
> particularly 3dnow and I guess SSE, and cards that did fast culling at the end
> of the pipe.  There ended up being less and less reason for it until you look
> at the DRI drivers and they all turn it off.  I've removed it in 3.5.

Excellent.  I'd still like to do some performance analysis of culling in
render_vb_triangles and friends as we've discussed, but I'm glad to see
this gone.

> The IsMatSpecular test I'm not so adamant about.  It can come back if anyone
> feels strongly, but I felt it might be easier to get a clean assembly
> implementation of lighting without it.

Thinking about it, I don't really care either way.  It certainly reduces
the combinatoral explosion of my per-light assembly code, but it's not
that big a deal.  Non-specular lighting will be slower of course.

I'll forward my code for you and Brian to check out, and you'll be able
to see how I would handle specular vs. non-specular lights.  I'll
reserve my judgement for later on this one.

> Anyway, there's another change to that file rattling through the pipes.
> Here's my latest code which cleans a few things up, and importantly removes
> the requirement that VB->Flags exists (for DrawArrays this was a pain).

Nice work -- I really like the changes you've made here.  It fits in
quite nicely with what I've been working on, so there are no problems
there.  As I said, I'll forward a snapshot (based on the 3.4 code) on
Monday or thereabouts for you to check out.

-- Gareth

Re: [Mesa3d-dev] Lighting code in 3.5

[Keith W. <ke...@va...>]

Gareth Hughes wrote:
> 
> Keith, I haven't looked into this much yet, but I was wondering if you
> could give me a quick rundown of the changes you've made to
> t_shade_tmp.h -- I've noticed the masked versions have gone, as has the
> light->IsMatSpecular[side] test.
> 
> Thanks.  I'd like any work I do on replacements of the 3.4 code (for
> hardware drivers) to be easily transitioned to 3.5 when the time comes.
> 

The early culling code turned out to be a dead end in the face of assembly,
particularly 3dnow and I guess SSE, and cards that did fast culling at the end
of the pipe.  There ended up being less and less reason for it until you look
at the DRI drivers and they all turn it off.  I've removed it in 3.5.

The IsMatSpecular test I'm not so adamant about.  It can come back if anyone
feels strongly, but I felt it might be easier to get a clean assembly
implementation of lighting without it.

Anyway, there's another change to that file rattling through the pipes. 
Here's my latest code which cleans a few things up, and importantly removes
the requirement that VB->Flags exists (for DrawArrays this was a pain).

Keith

[Mesa3d-dev] Lighting code in 3.5

[Gareth H. <ga...@va...>]

Keith, I haven't looked into this much yet, but I was wondering if you
could give me a quick rundown of the changes you've made to
t_shade_tmp.h -- I've noticed the masked versions have gone, as has the
light->IsMatSpecular[side] test.

Thanks.  I'd like any work I do on replacements of the 3.4 code (for
hardware drivers) to be easily transitioned to 3.5 when the time comes.

-- Gareth