[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

            Bug ID: 110897
           Summary: HyperZ is broken for r300 (bad z for some micro and
                    macrotiles?)
           Product: Mesa
           Version: git
          Hardware: Other
                OS: other
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r300
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: u9vata at gmail.com
        QA Contact: dri-devel at lists.freedesktop.org

Created attachment 144505
  --> https://bugs.freedesktop.org/attachment.cgi?id=144505&action=edit
first screenshot (still not completely ruined zbuffer)

Hello everyone!

I went on and tried RADEON_HYPERZ=1 with my r300 card and I see bad glitches -
while in the same time elevated performance. See attached screenshot(s).

This affect every application, even the simplest ones like glxgears.

The top of the screen is rendering properly always, but around the 25% of the
screen it starts to break down and I can see tiles where things seem to have a
really bad z-value.

What is also interesting is that [b]I feel the z-clear is the operation that is
happening wrong[/b]! I am pretty sure in this because at the first few frames
of glxgears I can nearly see all the gears and as the gears turn, I see less
and less of them - it kind of feels that whenever some pixel got rendered, its
place cannot be used anymore - or likely cannot be used! If I turn the wheels
some times around the Y axis the bottom 2/3 of the screen just becomes
completely dark after a while.

If I exit glxgears - or any app in question of testing -  and restart it from
the terminal however, I see that everything is immediately wrong! So [b]the
problem persists between multiple runs of the same program with same sized
window[/b] and this also hints that the z buffer is never properly (or at all)
cleared!

BUT [b]resizing the window immediately fixes the current frame[/b] with
seemingly proper Z-values and if I keep resizing I can see a constant
flickering - but a much more clear image. I think the resize operation triggers
some resize in the buffers that cleans them properly, but in the very first
second it already gets wrong again pretty much and this is what is happening.

Also while resizing the window I saw that [b]there is no straight horizontal
cut above which things are good and below which things are bad, but I literally
see only the number of (macro?)tiles count from the top-left corner![/b] So
basically I can see the side of one of the macrotiles. I tried to picture this
with a screenshot, but it is not that easy to resize that way. See the second
sceenshot that does not have anything on the bottom, but you see the cut and
the  left side of the tile where first things got wrong.

Also the order of how the tiles go wrong is not always linear, but the first
ones always work - from top-left going just like pixels.

I am trying to use documentation that I have found here:
http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/

Of course the r300 register docs should be good I hope, but I started reading
through the r500_acceleration docs as it seems many-many of it applies to all
r300 cards. Am I right that these are the best sources so far?

To be honest I think the fast z-clear maybe is the problem and is badly
configured to only clear the top few tiles on the screen or something similar.
The tiles are approximately 32x32 or 16x16, but surely not just 1-2 pixels as
they are pretty much visible to the naked eye (see second attachment
screenshot).

I have just barely started my analysis, so I still have a lot of directions to
take and the docs (if they are good) are really helpful at least! I did not
know about them so far!!!

Currently playing around the code to see if I can help the problem disappear.

This is likely never worked. I do not know of any version where this worked on
my machine, but I cannot completely rule it out of course.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190611/60559895/attachment-0001.html>