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