Created attachment 144505 [details]
first screenshot (still not completely ruined zbuffer)
Hello everyone!
I went on and tried RADEON_HYPERZ=3D1 with my r300 card and I see bad glitc=
hes -
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 t=
he
screen it starts to break down and I can see tiles where things seem to hav=
e a
really bad z-value.
What is also interesting is that [b]I feel the z-clear is the operation tha=
t is
happening wrong[/b]! I am pretty sure in this because at the first few fram=
es
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 whee=
ls
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 fr=
om
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 a=
ll)
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 trig=
gers
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 happenin=
g.
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 liter=
ally
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 t=
his
with a screenshot, but it is not that easy to resize that way. See the seco=
nd
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-g=
pu-documentation/
Of course the r300 register docs should be good I hope, but I started readi=
ng
through the r500_acceleration docs as it seems many-many of it applies to a=
ll
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 simil=
ar.
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 disappea=
r.
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.