mesa3d-dev

Re: [Mesa3d-dev] sources.lst files

[<de...@ko...>]

Allen Akin writes:
>On Sun, Feb 18, 2001 at 10:45:19PM -0800, de...@ko... wrote:
>| 
>| Don't think that passing the conformance tests  is proof you're doing
>| everything correctly.  We've got scads of visual display problems with Mesa in
>| our application...
>
>Nothing helps stamp out bugs (and prevent their return) better than
>adding to the test suites that the driver developers use.  If the
>problems you're seeing can be condensed down to simple test cases, we
>can add them to the glean suite to make sure they're checked in the
>future.  (Or you're welcome to add them yourself if you want to
>register as a glean developer -- start at http://glean.sourceforge.net/)

I've reported every bug in the past that I've been able to isolate to a simple
test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple, 
we use a large number of features, and the application itself is a very large, complex
application that takes several hours to compile and just getting the compile to work is
a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
not yet distributing the source in a general manner.   

But anyway.  This particular bug is nasty.  I've done full state dumps of the OpenGL
state, looked at the display list debugging output, and nothing appears to be wrong.
As far as we can tell, it's in the rasterization phase.  This particlar bug
exhibits as part of the molecule (this is a molecular modelling application,
see http://www.cgl.ucsf.edu/chimera) not appearing properly when it is first loaded
and displayed as a wireframe.  BUt, if a sphere representation is requested, and
then the wireframe representation is activated, the display begins to work properly.
Many of the bonds appear properly at first, but many don't-- if you up the MESA_GAMMA to 5
or so, you can see the "invisible" bonds faintly.    Worse yet, the bonds which are "invisible"
changes from run to run.  If I had to guess, I'd guess that the rasterization engine is
reading indeterminate values for the color of the bonds, and that somehow that memory is
getting properly filled in later when we generate the sphere representation.

What's really interesting is that if you compile the app against Mesa 3.4 (I think nothing
older than 3.3 works- it requires the changes to gl.h to use typedefs instead of enums for
C++ reasons) then use the Mesa 3.0 libGL, the problem goes away!  So, it must be a problem
that was introduced after 3.0 (but I know  a lot changed).
Using the nvidia driver and XFree86 4.0.2 doesn't have the problem.  

Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
arrays, polygon offset, stencil, along with tons of texture options including 3D textures
when available.  

Dave

Re: [Mesa3d-dev] sources.lst files

[<de...@ko...>]

>> 
>> I've reported every bug in the past that I've been able to isolate to a simple
>> test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple,
>> we use a large number of features, and the application itself is a very large, complex
>> application that takes several hours to compile and just getting the compile to work is
>> a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
>> not yet distributing the source in a general manner.
>
>Would sending me a binary be practical?

Sure, in fact, with the next release or so, any user will be able to download the binary
from the website without a password (right now it's password protected and you
have to make a formal request).

Right now I'm struggling with getting the Linux port to work again now that the main
programmer changed some source and it's causing g++ to report an internal compiler error
(urk).

>
>Could you send me a screenshot of the problem?  That might give me a hint.

Sure: see page http://www.cgl.ucsf.edu/home/dek/mesa_bug

>> Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
>> alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
>> arrays, polygon offset, stencil, along with tons of texture options including 3D textures
>> when available.
>
>Can you enable/disable these different OpenGL features in order to narrow
>down or characterize the circumstances under which the problem appears?

We'll see.  It's tricky because those modes are activated and deactivated numerous
times during a frame render, and not all of them are applied when the bonds are drawn.
Certainly,lighting, fog, clip planes, alpha blending, material properties, depth testing, scissor, and color logic
op are applied during bond rendering.

Re: [Mesa3d-dev] sources.lst files

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

de...@ko... wrote:
> 
> >>
> >> I've reported every bug in the past that I've been able to isolate to a simple
> >> test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple,
> >> we use a large number of features, and the application itself is a very large, complex
> >> application that takes several hours to compile and just getting the compile to work is
> >> a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
> >> not yet distributing the source in a general manner.
> >
> >Would sending me a binary be practical?
> 
> Sure, in fact, with the next release or so, any user will be able to download the binary
> from the website without a password (right now it's password protected and you
> have to make a formal request).

OK.  Let me know when it's available, give me the steps to reproduce the
problem and I'll look at it.


> Right now I'm struggling with getting the Linux port to work again now that the main
> programmer changed some source and it's causing g++ to report an internal compiler error
> (urk).
> 
> >
> >Could you send me a screenshot of the problem?  That might give me a hint.
> 
> Sure: see page http://www.cgl.ucsf.edu/home/dek/mesa_bug

Thanks.


> >> Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
> >> alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
> >> arrays, polygon offset, stencil, along with tons of texture options including 3D textures
> >> when available.
> >
> >Can you enable/disable these different OpenGL features in order to narrow
> >down or characterize the circumstances under which the problem appears?
> 
> We'll see.  It's tricky because those modes are activated and deactivated numerous
> times during a frame render, and not all of them are applied when the bonds are drawn.
> Certainly,lighting, fog, clip planes, alpha blending, material properties, depth testing,
> scissor, and color logic op are applied during bond rendering.

Are the bonds drawn as polygons or lines?  It's a bit hard to tell.  If you can
say what OpenGL features are used when rendering the bonds that would help too.

Thanks.

-Brian

Re: [Mesa3d-dev] sources.lst files

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

de...@ko... wrote:
> 
> Allen Akin writes:
> >On Sun, Feb 18, 2001 at 10:45:19PM -0800, de...@ko... wrote:
> >|
> >| Don't think that passing the conformance tests  is proof you're doing
> >| everything correctly.  We've got scads of visual display problems with Mesa in
> >| our application...
> >
> >Nothing helps stamp out bugs (and prevent their return) better than
> >adding to the test suites that the driver developers use.  If the
> >problems you're seeing can be condensed down to simple test cases, we
> >can add them to the glean suite to make sure they're checked in the
> >future.  (Or you're welcome to add them yourself if you want to
> >register as a glean developer -- start at http://glean.sourceforge.net/)
> 
> I've reported every bug in the past that I've been able to isolate to a simple
> test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple,
> we use a large number of features, and the application itself is a very large, complex
> application that takes several hours to compile and just getting the compile to work is
> a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
> not yet distributing the source in a general manner.

Would sending me a binary be practical?


> But anyway.  This particular bug is nasty.  I've done full state dumps of the OpenGL
> state, looked at the display list debugging output, and nothing appears to be wrong.
> As far as we can tell, it's in the rasterization phase.  This particlar bug
> exhibits as part of the molecule (this is a molecular modelling application,
> see http://www.cgl.ucsf.edu/chimera) not appearing properly when it is first loaded
> and displayed as a wireframe.  BUt, if a sphere representation is requested, and
> then the wireframe representation is activated, the display begins to work properly.
> Many of the bonds appear properly at first, but many don't-- if you up the MESA_GAMMA to 5
> or so, you can see the "invisible" bonds faintly.    Worse yet, the bonds which are "invisible"
> changes from run to run.  If I had to guess, I'd guess that the rasterization engine is
> reading indeterminate values for the color of the bonds, and that somehow that memory is
> getting properly filled in later when we generate the sphere representation.

Could you send me a screenshot of the problem?  That might give me a hint.


> What's really interesting is that if you compile the app against Mesa 3.4 (I think nothing
> older than 3.3 works- it requires the changes to gl.h to use typedefs instead of enums for
> C++ reasons) then use the Mesa 3.0 libGL, the problem goes away!  So, it must be a problem
> that was introduced after 3.0 (but I know  a lot changed).
> Using the nvidia driver and XFree86 4.0.2 doesn't have the problem.

A *lot* of code has changed since 3.0 so it's hard to say what's causing
the problem.


> Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
> alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
> arrays, polygon offset, stencil, along with tons of texture options including 3D textures
> when available.

Can you enable/disable these different OpenGL features in order to narrow
down or characterize the circumstances under which the problem appears?

-Brian