I'm personally a strong supporter in the support that AMD (nee ATi) has been giving to the OSS community. They have released specs and helped on the OSS driver where possible.
In this _specific_ case however, I have to agree, AMD has dropped the ball or may if it does not help a little out. If a extremely skilled OSS dev can't get it to work after 7 months, it's time that AMD step up to the plate and help out. This would not be expected of course, they have no 'real' obligation to do so, but it would confirm and show their commitment.
We are not asking here that AMD do all the work in getting Hyper-Z support in the OSS drivers, nor do we ask them to break any IP bs. They would merely be helping the already existing code out.
Having said all that, with the code being pushed only now, I would expect that it is only now that someone is even able to help, so my hopes are high at this moment.
BTW there is a TODO at http://dri.freedesktop.org/wiki/R600ToDo just in case anyone can tackle those tasks.
I don't think they use that marketing name anymore, we just refer to it as ZCULL.
It, well, at least doesn't lock up (NV cards prefer raising an IRQ and telling you what you did wrong via error state registers anyway). But it doesn't do much else either. I can provoke rendering errors (by modifying the depth buffer behind ZCULL's back) so I know it does *something*, but performance doesn't seem to change.
It used to be more critical for performance when you didn't get any early-z without ZCULL, i.e. on pre-GF8, but now you do, so it's harder to measure the impact. I think I haven't tried running with a huge resolution and 8x multisampling yet, but, I couldn't even see any change in performance running the blob and bashing the ZCULL region registers behind its back (on pre-Fermi the ZCULL storage is in a dedicated memory area) either.
Anyway, there's plenty other places to gain more performance from ...