>>> >>This sounds like Z-buffer fighting. If you draw the same triangle twice >>with exactly the same vertices you'd expect that the same Z values would >>be generated for each fragment. But the OpenGL spec doesn't require that >>to be true, depending on particular state changes between passes. (See >>the OpenGL spec appendices). >> >>If the first triangle is drawn in hardware but the second is drawn with >>software (or vice versa) you almost never get exactly the same >>rasterization results. I've also seen cards which will do both passes >>in hardware but still produce different Z values. >> >>glPolygonOffset() is the usual solution to this problem and its up to >>the application programmer to know when to use it. >> >>Strictly speaking, the gloss demo should use glPolygonOffset() for >>the second rendering pass. But it doesn't because I was lazy when I >>wrote the demo. >> >>So, if my hypothesis is correct, this is an application problem. >> > > Ok, I'll investigate the application to see if it's the problem. > > I seem to recall that TuxRacer more or less worked with the 4.2 Radeon > 7500 drivers, but doesn't seem to work with the TCL drivers. This might > indicate that, eg., one pass is being done with TCL and one with CPU > transform (and they don't agree)...
I've seen one case (the red & white parachutes in tuxkart) which are rendered transparent by the non-tcl driver and opaque by the tcl driver. If a similar mixup is happening in multipass rendering then it could account for the artifacts. Presumably there are some states where color should be rgba, but we're just sending the rgb components to hardware. How does the problem look if you say 'export RADEON_NO_VTXFMT=t'? Keith ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
