[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

--- Comment #58 from Richard Thier <u9vata at gmail.com> ---
I still have some dmesg logs around from my other debugging session and in
every one of those I get 3 pipes despite different kernel versions from 4.4 to
latest 5.x

Also looking at git blame I can see that relevant code paths were last touched
10 years ago with a big drm related commit. So nothing has changed in the code
it seems. Ok... I didn't check if the register number in the header is changed
or not, just hoped not, but the code itself is doing the same 10 year old
things here. Even the FIXME saying if this is good or not (when calling
r420_pipes_init in rs400_init) is that old.

[drm] initializing kernel modesetting (RS400 0x1002:0x5A62 0x1043:0x1392)

^^You seem to be also 5A62 here. In the code of r420_pipes_init, there are some
hardcoded cases for some other similar values that force a single-pipe instead
of reading from the register but you do not fall into those. The last two
numbers are different in your case, but that does not count for that code path
that decides the pipe number - except if the small variance in the last two
means that your card gives back proper values in the register from which you
can read the pipe num.

Btw running with r300_init call instead of the r420 pipe initializaion is going
good so far: performance is the same, the glitches are the same (I know about
some already), everything works that worked before...

One possible solution might be to just use r300_init for r400, but I have no
idea if that breaks some r400 cards. I only have my RC410 but no other... An
other appoach is to add one more special cases for the r420_pipes_init that
specifically checks for 5A62 and forces a single pipeline despite what is read
from the register.

Also there was one time where things were working for me before changes but I
do not know what the pipe value was back then. So yes, there is SOME chance
that this register can also return 1 in my case too, but it seems most of the
time (99% at least if not 100%) it returns 3.

I will prepare both patches and then let others decide which direction to take.
I think taking the r300_init direction is maybe better because of hopeful
backwards compatibility in general.

-- 
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/20190616/f989ae5f/attachment.html>