Michel Dänzer wrote: > 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?)
Gears is all display lists -- it doesn't touch the vtxfmt code at all. Maybe theres some state pingponging, but I don't see how it could be a big influence... > > 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? If it shows anything, yes. 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
