[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from PJBrs <pjbrs at floorenpj.xs4all.nl> ---
Tom Stellard suggested that I do a binary search for incorrectly rendered
shaders. I first compared debug log differences between old and smart
schedulers. The logs show that eight shader programs are compiled differently
by the two schedulers (I assume that a shader program is identified by
"pc=$number" in the log.) For each of these shader programs I've listed the
number of fragment program instructions and the number of hardware program
instruction, for both old
and smart scheduler:

#instructions:  fp old: fp smart:       hwp old:        hwp smart:
Shader program:
pc=8            14      12              8               7
pc=9            25      24              19              19
pc=10           22      22              17              18
pc=11           9       8               4               4
pc=15           6       5               3               2
pc=17           26      26              18              18
pc=18           20      19              11              11
pc=19           7       6               3               3

fp=fragment program
hwp=hardware program

I then did a binary analysis by trying different numbers for
max_alu_instructions. I started with 15. With max_alu=15, there are some
differences in shading between old and smart schedulers. Same with max_alu=8.
With lower max_alu (tested 4, 6 and 7), these differences disappear. I did not
notice any other differences in rendering between old and smart schedulers for
max_alu=<15. However, I did not yet see the bug that I initially noticed when I
reported it, so I tested further with max_alu=20.

With max_alu=20, the smart scheduler displays the lighting bug that I initially
wanted to report. With max_alu=17 and max_alu=18, rendering is the same as with
max_alu=15 for both old and smart schedulars. With max_alu=19, a new difference
in rendering between old and smart schedulers is introduced. A final difference
 is introduced with max_alu=20, which shows the bug that I originally
saw. So, in sum, at least three shader programs are rendered differently by the
old and smart schedulers--the first difference appears with max_alu=8, the
second with max_alu=19 and the third difference with max_alu=20.

The first difference suggests that "pc=8" is rendered incorrectly, since it has
7 instructions in the smart scheduler. Apparently, it does not do anything with
the old scheduler (which results in 8 instructions), but increasing max_alu
does not change those rendering bits rendered incorrectly by the smart
scheduler. The second difference is either caused by shader program "pc=17",
which consist of 18 instructions in both schedulers, or by "pc=10" which
consists of 17 instructions with the old scheduler and 18 instructions with the
smart scheduler. It's hard to say which shader program is rendered incorrectly
(if not both are), because, with the old scheduler, there are rendering
differences between max_alu=17 and max_alu=18. As the smart renderer shows no
differences between max_alu=17 and max_alu=18, these must be caused by "pc=10".
The third incorrectly rendered shader program would be "pc=9", with 19
instructions.

What would a good starting point for searching the bug be? I think comparing
the compilations for pc=19 and pc=8, because those almost certainly are
rendered incorrectly due to changes in the scheduler. I've added screenshots
and logs insofar I thought was necessary. I have more available, but I don't
want to clog this report. I hope that the filenames speak for themselves :-)
Please let me know what else I can do.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130511/e6d50f12/attachment.html>