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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@lists.freedesktop.org
Reporter u9vata@gmail.com
QA Contact dri-devel@lists.freedesktop.org

Created attachment 144505 [details]
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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux