Re: [Mesa3d-dev] New Mesa 3.2 Bugs - One serious (I think)

[Stephen J B. <sj...@li...>]

On Sun, 18 Jun 2000, Linux Development Account wrote:

>    While I have been working with OpenGL since its inception I am
> relatively new to Mesa and the Source Forge development system here
> so bear with me.
> 
>    An initial question: If I find what I think is bug do I directly
> try to add in the source forge bug tracker or do we discuss it first here
> to make sure a bug has really been found?
 
It's a hard call - I'd discuss it here first.

> #1 Incorrect Rendering of Subpixel quadstrips - Serious problem ?
> 
> Polygons less than one pixel in size don't display at all. Take a very complex
> polygonal surface then slowly pull back. Given the huge number of
> polygons eventually the size of a polygon will be mathematically smaller
> than one pixel. It appears at this stage that no on screen pixel
> representation is drawn. Thus as you pull back the suface discenigrates
> and vanishes even though the overall surface might cover thousands of
> pixels.
 
This has come up a couple of times before.

Mesa does cull very tiny triangles (which is "A BAD THING" IMHO) - we are
told that it's necessary for Mesa to do this in order to avoid mathematical
instabilities down the line.

The last person to complain about this hacked Mesa to reduce the size limit
to something MUCH smaller than it currently is - with no ill effects.

I guess that hack didn't make it into mainstream Mesa...but I think we DO
need to address this issue as a bug.

> Note this problem does not happen on SGI, Sun, or windows OpenGL 
> implementations so I guess there is some aspect of the OpenGL standard
> that Mesa does not correctly implement.

I don't know if what Mesa does is in violation of the OpenGL spec or not...
I suspect it is a violation - but even if it isn't, it's an evil that needs
to be addressed properly at some stage.

> #2 Front & Back buffer drawing+blending = crash 
> 
> With a double buffered visual if I draw polygons (quad strips in this
> case) normally or use glDrawBuffer( GL_FRONT ) and draw the polygons no problem.
> However, if I use glDrawBuffer(GL_FRONT_AND_BACK) the application crashes.
> Here's some output from gdb.
> 
> Reading symbols from /lib/ld-linux.so.2...done.
> #0  0x400552ac in blend_transparency (ctx=Cannot access memory at address 0x3d
> ) at blend.c:286
> 286	blend.c: No such file or directory.
> (gdb) where
> #0  0x400552ac in blend_transparency (ctx=Cannot access memory at address 0x3d
> ) at blend.c:286
> #1  0x842ed10 in ?? ()
> Cannot access memory at address 0x1
 
That's a new one on me - but then you may well be the first person ever
to try that!   It's a pretty estoeric rendering mode.

> #3 Rendering Performance Issue - Not a bug but an observation.
> 
> Again using a double buffered (+Zbuffer) - If I draw the same quad strip
> scene described in bug #1 normaly in the background and swap it to the
> foregroup this the usual SwapBuffer command I get excellent performance.
> However if I set glDrawBuffer(GL_FRONT) and render the same scene you get
> absolutely horrible performance in comparison. I would say 10-12 times
> slower. I would expect the two situations to have similar performance with only 
> glDrawBuffer(GL_FONT_AND_BACK) to suffering a performance penalty. Anyone
> with more Mesa knowledge care to comment - Is this a problem or just a
> optimization waiting for an implementor?
 
As always, it's the commonly used modes that get the most optimisation - and
glDrawBuffer(GL_FRONT_AND_BACK) is certainly not commonly used.  It's possible
that because each pixel is writing to two widely separated chunks of memory
that you are causeing some nasty cache artifact in the CPU - but I suspect
it's more likely that a lack of a specifically optimised code path is your
problem.

(That assumes you are doing software rendering - if you are doing hardware
rendering then the likely explanation would be that the hardware can't do
simultaneous front and back buffer rendering - so you got a software fallback).

If I were you, I'd alter my code to render each object twice, once into the
back buffer and again into the front.  This would avoid both the bug and the
slowdown - and it'll probably be faster on every platform - not just Mesa.

Of course you should register #2 as a bug, possibly #1 also (although we
all understand it already) - I don't think a lack of optimisation in #3
justifies a *bug* report - but opinions will differ on that one.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1