On Wed, 28 May 2003, Ian Romanick wrote:
Leif Delgass wrote:
The Rage 128 driver doesn't currently support a hardware stencil, but I've
been working on getting that going as well. So far, I've found that using
the same bits for stencil wrap modes as R100/R200 does work, but there are
problems with readback. The r128 driver calls ioctls in the drm that blit
to and from an AGP span buffer to implement Read/DrawPixels for the depth
buffer. This seems to be in order to avoid having to convert
coords/offsets to account for depth buffer tiling. At any rate, the
problem I see in readback seems to indicate some sort of caching problem. I modified stencilwrap in the same way you did to continue and report
errors. I see off-by-one errors that vary (in a seemingly random way) in
number and value from one run to the next. That is, I get a few "old" values and then things seem to "catch up." I'd like to do some more testing and see if I can reproduce the same behavior with the depth component values.
That's interesting. I think the problems I was seeing with stencil on i830 were just read-back errors as well.
I've tried a few of the SGI sample tests you mentioned that use the stencil buffer on r128 with my preliminary stencil patch and they are working. There is still a bug with quake3 and r128 (with or without a stencil buffer) where damage textures and sometimes other objects show through walls and such that looks like some sort of depth bug. I'm not sure if this is related to read-back though.
Good work. It will be nice to have stencil enabled in that driver.
BTW, I fixed the fire demo bug on r128 (and mach64). It wasn't related to texmem at all, but rather it was a Mesa 4.1/5.x merge problem. The Color.AlphaRef alpha test reference value was changed from GLubyte to GLfloat in Mesa 4.1, and all the drivers except r128 were updated to convert from a float to a ubyte when programming their respective alpha test registers.
At any rate, I'd like to commit the attached patch, but it would be good to get some more data points from R100 users. Testing has convinced me that the stencil wrap register settings are the same for all the ATI cards we have drivers for that support a hardware stencil, but I don't have docs for R100 or Rage 128.
I think there was some bug in the 7200 that was fixed in the 7500. I have attached my version of stencilwrap.c, my output from stencilwrap.c, and my patch to the driver. I should be able to try this out on an M6 and possibly a 7000 a little later today. We may be able to enable this, but only on certain "versions" of the R100 chip. :(
Your stencilwrap output from the 7200 is truly bizarre. :O I wonder what setting the INVERT bit does? So far, it looks like you have:
DECR_WRAP -> does INVERT DECR -> does DECR_WRAP INCR_WRAP -> does DECR_WRAP INCR -> OK INVERT -> ?
And does the same thing happen with fail and zfail? It would be good to have a test that tries all of the stencil func/op combinations in addition to the stencil wrap extension.
I haven't tried any of the other combinations yet. I'll have to modify stencilwrap. I wonder if there's a good glean test for this...
Since our patches are virually identical, it does appear to be a hardware bug on that particular card. Looks like we may need to pass a PCI id or some sort of hardware family designation from the X server to the Mesa driver. In any case, we'll need to get test reports on as many r100 variants as possible. If we need workarounds/fallbacks for specific card revisions, it would be nice to know if they all break in the same way.
The plot thickens. The M6 card I have fails every single test. It basically just always reads back some constant value. If I leave the window alone it reads back the clear value. If I resize the window it gets a random constant value (i.e., every GL_INCR test reads back 32). I would suspect that these are just read-back errors, but the window never gets clears or drawn to. It just contains whatever was there before it opened...until I resize it.
Naturally, the SGI stencil demos work just fine. :(
http://www.sgi.com/software/opengl/examples/glut/advanced/
According to 'lspci -vv -n', my Radeon is a 1002:5144, subsystem 1002:008a. It's one of the original Radeon 32MB DDR cards...from way before the funky numbering system. :)
The 7500 I'm testing on says: 1002:5157, subsystem 1002:013a (RV200 QW).
This card is a 1002:4c59, 1002:010a. It doesn't show up in drivers/pci/pci.ids. I assume that's because it's a stand-alone test card.
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
