On Mon, 2002-07-08 at 07:31, Elladan wrote: > On Sun, Jul 07, 2002 at 09:18:44PM -0600, Brian Paul wrote: > > Elladan wrote: > > >On Fri, Jul 05, 2002 at 08:15:26AM +0100, Keith Whitwell wrote: > > > > > >>Elladan wrote: > > >> > > >>>Yes. I'm seeing the same thing on my Radeon 7500. See screenshots > > >>>here: > > >>> > > >>>http://www.eskimo.com/~elladan/tux > > >>> > > >>>(Or in the bug report I filed on the dri project page...) > > >>> > > >>>I'm also seeing generally horrible problems with tuxracer whenever it > > >>>uses multiple textures on the same polygon, as far as I can tell. > > >>> > > >>>There seemed to be a few other bugs in the database on multitexture > > >>>problems, too... > > >> > > >>It's to do with multipass rendering, I think, rather than the texture > > >>code specifically. > > >> > > >>The same problem gives you the 'shimmery' ice patches. The mesa gloss > > >>demo shows similar artifacts. > > > > > Where would this problem most likely reside in the code? Any guesses? > > > Eg., file/function areas? I can go playing around in there if someone > > > have some vague idea what the problem might be... > > > > > > -J > > > > 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.
Yep, it still works now with RADEON_NO_TCL but not with RADEON_NO_VTXFMT. (BTW glxgears seems to be faster with RADEON_NO_VTXFMT here. I know glxgears doesn't really mean anything, but it's probably because there are no PPC assembler optimizations yet? Maybe we shouldn't use vtxfmt in that case?) Another problem I have with tuxracer is that it's very slow. Used to be much faster, unfortunately I don't remember if that was with the Mesa 3.4 based driver or with the pre-TCL Mesa 4.0 based one. Neither of the two environment variables mentioned here helps. Might the output with RADEON_DEBUG=fall be enlightening to anyone? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- 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
