On Wed, 28 May 2003, Ian Romanick wrote: > Leif Delgass wrote: > > On Wed, 30 Apr 2003, Ian Romanick wrote: > > > > > >>After cleaning up some of the left-over issues from the texmem merge, I > >>did a quick check low-hanging fruit functionality that could be added so > >>some of the drivers. In doing so, I notied that neither the r128 driver > >>or the radeon driver support EXT_stencil_wrap. Since this extension is > >>part of the 1.4 core spec, it seems like a fairly important one to add. > >> According to Delph3D, EXT_stencil_wrap is supported by both of these > >>chips. > >> > >>http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_stencil_wrap > >> > >>I did some experimentation with the radeon driver and the stencilwrap > >>test (in the tests directory in Mesa). I made a small modification to > >>is so that it would log errors and continue on. I modified the radeon > >>drivers to use the same values for GL_INCR_WRAP and GL_DECR_WRAP as the > >>R200 driver (all of the other stencil op values are the same). The > >>interesting thing that I noticed is that RADEON_STENCIL_*_DEC behaves > >>like R200_STENCIL_*_DEC_WRAP should. Using R200_STENCIL_*_INC_WRAP on > >>the R100 behaves like RADEON_STENCIL_*_INVERT, but > >>R200_STENCIL_*_DEC_WRAP works correctly. > > > > > > I just did the same patch/test here on Radeon 7500 and the stencilwrap > > test works fine. INC/DEC saturate as expected and INC_WRAP/DEC_WRAP wrap > > correctly. I'm attaching the patch I used. > > I think the *only* difference between your patch and mine is that I used > the GL 1.4 names and you used the EXT names.
Yep. > > 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. 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. 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. > 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). -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- 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
