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

--- Comment #1 from Marek Olšák maraeo@gmail.com 2011-01-09 15:07:37 PST --- Doesn't the performance boost come from the fact that a large part of the screen is not rendered?

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

--- Comment #3 from Marek Olšák maraeo@gmail.com 2011-01-24 21:00:14 PST --- Does this patch fix anything?

https://bugs.freedesktop.org/attachment.cgi?id=42432

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

--- Comment #5 from Sven Arvidsson sa@whiz.se 2011-01-25 06:34:55 PST --- Created an attachment (id=42459) --> (https://bugs.freedesktop.org/attachment.cgi?id=42459) screenshot from doom3

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

Sven Arvidsson sa@whiz.se changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #42459|0 |1 is obsolete| |

--- Comment #7 from Sven Arvidsson sa@whiz.se 2011-01-25 08:06:53 PST --- Created an attachment (id=42469) --> (https://bugs.freedesktop.org/attachment.cgi?id=42469) doom3 with second version of patch

(In reply to comment #6)

I've made a new patch. Could you give it a try?

https://bugs.freedesktop.org/attachment.cgi?id=42464

This seems slightly worse. Not much difference in glxgears, but in Doom3 the corruption is a lot more persistent.

Not sure if it's relevant, but in glxgears, the amount of corruption depends on what angle you're viewing the gears from.

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

--- Comment #9 from Sven Arvidsson sa@whiz.se 2011-01-25 14:29:28 PST --- Created an attachment (id=42495) --> (https://bugs.freedesktop.org/attachment.cgi?id=42495) dmesg output

(In reply to comment #8)

It appears that one third of the zbuffer is not cleared on your machine. In src/gallium/drivers/r300/r300_emit.c, can you add this line:

numdw = ALIGN_DIVUP(numdw * 3, 2);

at line 1171 and do some testing?

Could you also please attach your dmesg?

Adding the line didn't make any difference.

In fact, I did some poking around (without any real understanding) and the value of numdw doesn't seem to make any difference. Replacing OUT_CS(numdw); with OUT_CS(0); gives the same result here. But maybe that's expected?

dmesg is attached.

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

--- Comment #11 from Sven Arvidsson sa@whiz.se 2011-01-25 15:37:15 PST --- (In reply to comment #10)

It doesn't add up. Changing numdw must make a visible difference, it determines how many pixels are cleared (multiplied by something).

I don't think 0 is even allowed. Try 1 and see how large part of the screen is rendered correctly. It should be 64x64 or something like that, I don't know for sure. Knowing that size would come in handy. The rest of the screen should be corrupted.

With 1 the whole screen is corrupt and mostly black - but you can still see part of the gears flickering though it's hard to catch in a screenshot.

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

--- Comment #13 from Sven Arvidsson sa@whiz.se 2011-01-26 07:59:30 PST --- Created an attachment (id=42527) --> (https://bugs.freedesktop.org/attachment.cgi?id=42527) shadowtex screenshot

Okay, so if I have done this correctly, the small white area in the left corner is 48x16, if you mean the larger black and white rendering it seems to be 256x257.

I'm attaching a screenshot of shadowtex.

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

--- Comment #15 from Marek Olšák maraeo@gmail.com 2011-01-28 03:08:44 PST --- If the latest commits don't help, please add the following line at the end of r300_chipset.c and test again:

caps->hiz_ram = 0;

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

Marek Olšák maraeo@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|Lower part of the screen |[r300g] HyperZ: Wrong size |corrupt with HyperZ enabled |in the HiZ clear packet | |causes the zbuffer not to | |be fully cleared

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

Sven Arvidsson sa@whiz.se changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #41815|0 |1 is obsolete| | Attachment #42458|0 |1 is obsolete| | Attachment #42469|0 |1 is obsolete| |

--- Comment #18 from Sven Arvidsson sa@whiz.se 2011-03-01 04:05:00 PST --- Created an attachment (id=43961) --> (https://bugs.freedesktop.org/attachment.cgi?id=43961) Screenshot of ETQW

(In reply to comment #17)

Please check out the latest Mesa master branch. There are some new fixes, which should fix even this bug.

Things are considerably better now. The corruption in gears and doom3 seems to be completely gone. (And the speedup in doom is around 40%!)

There's still something funky in ETQW, on the left and right sides. A screenshot is attached.

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

--- Comment #20 from Marek Olšák maraeo@gmail.com 2011-03-03 12:52:56 PST --- I can't fix this by myself, because I don't have your GPU. If you want to play with it, here's how:

In mesa/src/gallium/drivers/r300, there is file r300_texture_desc.c. On lines 356 and 357, there are two arrays containing info how HiZ buffers should be aligned:

static unsigned hiz_align_x[4] = {8, 32, 48, 32}; static unsigned hiz_align_y[4] = {8, 8, 8, 32};

The 3rd element in those arrays contains a number for your GPU (because your GPU has 3 pipes). Currently the alignment is 48x8. Feel free to try a different size, like 32x32, 64x64, 48x32, whatever comes to your mind.

If nothing helps, it means the alignment is right and the problem is somewhere else.

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

--- Comment #22 from Sven Arvidsson sa@whiz.se 2011-03-06 14:12:34 PST --- (In reply to comment #21)

Anyway playing with hiz_align_(x|y) values doesn't change anything for me.

I've been doing the same, with no change in behaviour. So I guess the problem is somewhere else? :/

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

Marek Olšák maraeo@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|[RADEON:KMS:R300G] HyperZ: |[RADEON:KMS:R300G] HiZ: |Wrong size in the HiZ clear |Weird behavior with 3 pipes |packet causes the zbuffer | |not to be fully cleared |

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

--- Comment #24 from Marek Olšák maraeo@gmail.com 2011-03-10 19:40:15 PST --- (In reply to comment #23)

Created an attachment (id=44333)

View: https://bugs.freedesktop.org/attachment.cgi?id=44333 Review: https://bugs.freedesktop.org/review?bug=32945&attachment=44333

Possible fix

The attached patch fixes the issue with shadowtex for me. Sven, can you try it and also see if doom3 is still OK with it ?

With 3 pipes values are NPOT, so align() is not suitable in some places I think.

Pushed, thanks a lot!

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

Marek Olšák maraeo@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED

--- Comment #26 from Marek Olšák maraeo@gmail.com 2011-03-11 11:33:40 PST --- (In reply to comment #25)

Cool! This does indeed fix things!

Alright, closing.