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