On Mon, 2002-07-08 at 13:55, Keith Whitwell wrote: > 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...
Well, I forgot to mention that the difference isn't big. I'll try other stuff, unless I can reproduce a significant difference with anything it's not important. > > 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. http://www.penguinppc.org/~daenzer/DRI/tuxracer.fallback -- 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
