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:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel