Created attachment 12345 [details]
Source code. UNIX Makefile and also a Windows executable

The Windows executable works fine under Wine, and exactly like the UNIX executable.

At a quick glance, I can't see anything wrong with it, and it seems to match swrast. Could you provide some screenshots?

(In reply to comment #2)
> Could you provide some screenshots?

Not straight away because the machine doesn't have the Radeon 9200 in it any more. However, I seem to recall that another machine with a Radeon 7000 did exactly the same thing, so I'll try and get some screenshots from that in a few days time.

Did you try running the executable with your Radeon 9250?

(In reply to comment #3)
> > Could you provide some screenshots?
> 
> Not straight away because the machine doesn't have the Radeon 9200 in it any
> more. However, I seem to recall that another machine with a Radeon 7000 did
> exactly the same thing, so I'll try and get some screenshots from that in a few
> days time.
Ok.

> Did you try running the executable with your Radeon 9250?
Well with a radeon 9000.

Created attachment 12394 [details]
Git Mesa, 2007-11-07

Actually made with a Radeon 7000, not a 9200.

Created attachment 12395 [details]
Git Mesa, 2007-11-07

Same Mesa build, using a Radeon 7000.

Created attachment 12396 [details]
Git Mesa, 2007-11-07

Also with the same Radeon 7000.

Other interesting points:

- the same thing happens with LIBGL_ALWAYS_INDIRECT=1
- the pixels forming the text mysteriously turn themselves on and off as I move the application's window around the screen, and not just as I rotate the cubes.
- I am using Fedora 7 with Mesa git.

text drawing uses glBitmap, which is not accelerated and thus uses swrast. So it's expected to not work with hyperz. Don't enable that and it will work...

(In reply to comment #9)
> text drawing uses glBitmap, which is not accelerated and thus uses swrast. So
> it's expected to not work with hyperz. Don't enable that and it will work...

OK, I'll check this when I next get access to the PC with the Radeon 7000. And so the reason that the R300 works is because it doesn't implement HyperZ?

Does this mean that HyperZ support for the R200/R100 is incomplete? I generally use HyperZ because it dramatically increases the FPS.

(In reply to comment #10)
> OK, I'll check this when I next get access to the PC with the Radeon 7000. And
> so the reason that the R300 works is because it doesn't implement HyperZ?
Not sure exactly what R300 implements - early Z for sure which doesn't interfere with direct reading/writing of the buffer.

> Does this mean that HyperZ support for the R200/R100 is incomplete?
Yes, which is why it's disabled...
Apart from the problem of two windows very close together (so they have overlapping z tiles (16 pixels or so, don't know off-hand)) which could lead to some errors at their borders, any direct read/write of z buffer is completely broken. I had some ideas how to fix this, but it's not that easy.
For z buffer writes, definitely the most easy thing to do would be to turn every pixel write into a point render (so all hyperz issues get handled automatically by the gpu).
Reading is a mess, first you'd need to calculate the z tile address, then look the z tags up in the gpu to see if the z tile is compressed or cleared. If it's cleared, the value is the last used clear value, otherwise the tile must be read back as usual from the z buffer. If it's uncompressed, fine, no problem, but otherwise you have to software-decompress the tile to figure out the z value, which means you have to reverse-engeneer the compression algorithm...
It is possible reading compressed tiles could be simpler, by forcing the chip to load the tile and decompress it, and accessing the decompressed tile data directly from the on-chip z buffer cache. I've got no idea though if that's even possible and if so, how to do it... There might be other solutions (like doing some render which forces the chip to update the tile you're interested in, reading it using hyperz and forcing it to store unchanged but uncompressed back), dunno.

Created attachment 12436 [details]
Screenshot using Radeon 7000 with HyperZ disabled

This is using the same version of Mesa as the previous screen shots. Disabling HyperZ doesn't seem to have had any effect.

Created attachment 12437 [details]
Screenshot using Radeon 7000 with both HyperZ and 3D acceleation disabled

The strange thing about this screenshot is that it isn't even accurate! For example, the Gimp 2.2 failed to capture the second line of text at the top, and some of the 4th cube is missing. But the overall impression of how it looked is correct.

Here is my .drirc file; HyperZ and 3D acceleration are both disabled.

<driconf>
    <device screen="0" driver="radeon">
        <application name="Default">
            <option name="force_s3tc_enable" value="false" />
            <option name="no_rast" value="true" />
            <option name="fthrottle_mode" value="2" />
            <option name="tcl_mode" value="3" />
            <option name="texture_depth" value="1" />
            <option name="def_max_anisotropy" value="1.0" />
            <option name="no_neg_lod_bias" value="false" />
            <option name="round_mode" value="0" />
            <option name="dither_mode" value="0" />
            <option name="hyperz" value="false" />
            <option name="texture_units" value="3" />
            <option name="color_reduction" value="1" />
            <option name="vblank_mode" value="1" />
            <option name="allow_large_textures" value="2" />
        </application>
    </device>
</driconf>

Looks like reading/writing z buffer doesn't work at all for you even without hyperz. Surface setup is probably wrong. You could try enabling that code for rv100 too (see RADEONChangeSurfaces in the ddx - there are two blocks which are disabled for those chips). We thought that rv100 (and related) chips didn't have z tiling always enabled, only when using hyperz (where we didn't care about that setting since readback doesn't work anyway), but maybe your card does (if you could enable/disable it, I'd have no idea how). That was a bit of a mystery to me, maybe Stephane knows more about it since I never tested that on such a chip.

Yeah, the depth buffer on rv100 is not tiled until you enable hyperz. This is something that was never fixed in mesa's pixel span routines, these assume that the depth buffer is always tiled.

(In reply to comment #16)
> Yeah, the depth buffer on rv100 is not tiled until you enable hyperz. This is
> something that was never fixed in mesa's pixel span routines, these assume that
> the depth buffer is always tiled.
Oops. I thought that was fixed ages ago. But looks like it's not...
In fact this looks pretty strange, in the dri driver depthHasSurface is set according to ddx version (which is ok) and according to RADEON_CHIPSET_TCL - this isn't the same for all radeon families (at least ddx doesn't set it up like that, maybe fallout from merging r100/r200/r300 radeon_screen.c), so would break r200/r300 igps.
But even for r100, this sounds wrong as it only decides if we're using software z-buffer de-tiling or not - for chips which really don't use z tiling we should just pretend we have a surface set up for tiling anyway since we can just read it directly without address translation...
Chris, does it work correctly if you remove the additional test for RADEON_CHIPSET_TCL in that screen->depthHasSurface assignment in radeon_screen.c?

(In reply to comment #17)
> Chris, does it work correctly if you remove the additional test for
> RADEON_CHIPSET_TCL in that screen->depthHasSurface assignment in
> radeon_screen.c?

You mean this one?:

   /* Check if ddx has set up a surface reg to cover depth buffer */
   screen->depthHasSurface = ((sPriv->ddx_version.major > 4) &&
      (screen->chip_flags & RADEON_CHIPSET_TCL));

I'll try this as soon as I get access to the machine.

(In reply to comment #17)
> Chris, does it work correctly if you remove the additional test for
> RADEON_CHIPSET_TCL in that screen->depthHasSurface assignment in
> radeon_screen.c?

No, there's no difference, either when disabling HyperZ or 3D acceleration, when I comment those lines out.

(In reply to comment #18)
 
>    /* Check if ddx has set up a surface reg to cover depth buffer */
>    screen->depthHasSurface = ((sPriv->ddx_version.major > 4) &&
>       (screen->chip_flags & RADEON_CHIPSET_TCL));

OK, I misunderstood you and just deleted this entire line instead of just the (screen->chip_flags & RADEON_CHIPSET_TCL) condition. The latest git version of Mesa (17-Nov-2007) works better than the previous version, but it's still not quite right.

Created attachment 12610 [details]
Git Mesa, 2007-11-17, Radeon 7000 with HyperZ disabled

A distinct improvement, but there are still missng pieces of the text.

Created attachment 12611 [details]
Git Mesa, 2007-11-17, Radeon 7000 with HyperZ and 3D acceleration disabled

Created attachment 12634 [details]
simple zreaddraw hack

interesting though I can't see much improvement it's just different. Could you run (with hw accel but without hyperz) a zreaddraw patched with this patch and attach the screenshot?

Created attachment 12635 [details] [review]
ddx patch to really disable depth surface setup

Oh, and could you run it after applying this ddx patch? Those if conditions there look slightly, umm, suboptimal...

Created attachment 12675 [details]
Patched zreaddraw, No HyperZ, before patching radeon driver

Created attachment 12676 [details]
Patched zreaddraw, No HyperZ, after patching radeon driver

I'm guessing that this is correct.

*** Bug 10709 has been marked as a duplicate of this bug. ***

(In reply to comment #26)
> Created an attachment (id=12676) [details]
> Patched zreaddraw, No HyperZ, after patching radeon driver
> 
> I'm guessing that this is correct.
Hmm almost, it should have drawn both the blue cube and the grey depth image (due to glWindowPos2i call). Anyway, fixed now.
Feel free to open an enhancement bug for reading/writing depth with hyperz, but don't expect anyone to fix it...

Created attachment 12710 [details]
Git Mesa, 2007-11-24, Radeon 7000 with HyperZ disabled

And with the patched XOrg radeon driver too.