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

--- Comment #2 from PJBrs pj_beers@hotmail.com --- Created attachment 77938 --> https://bugs.freedesktop.org/attachment.cgi?id=77938&action=edit Bad rendering screen 2

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

PJBrs pj_beers@hotmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #77936|text/plain |image/png mime type| |

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

--- Comment #5 from PJBrs pjbrs@floorenpj.xs4all.nl --- Created attachment 78616 --> https://bugs.freedesktop.org/attachment.cgi?id=78616&action=edit First bad penumbra output with RADEON_DEBUG=fp,vp

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

--- Comment #7 from PJBrs pjbrs@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.

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

--- Comment #9 from PJBrs pjbrs@floorenpj.xs4all.nl --- Created attachment 79152 --> https://bugs.freedesktop.org/attachment.cgi?id=79152&action=edit Screenshot, maxALU=8, smart renderer

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

--- Comment #11 from PJBrs pjbrs@floorenpj.xs4all.nl --- Created attachment 79155 --> https://bugs.freedesktop.org/attachment.cgi?id=79155&action=edit Log RADEON_DEBUG=fp,vp, maxALU=8, smart renderer

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

--- Comment #13 from PJBrs pjbrs@floorenpj.xs4all.nl --- Created attachment 79157 --> https://bugs.freedesktop.org/attachment.cgi?id=79157&action=edit Screenshot, maxALU=20, smart renderer

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

--- Comment #15 from PJBrs pjbrs@floorenpj.xs4all.nl --- Created attachment 79160 --> https://bugs.freedesktop.org/attachment.cgi?id=79160&action=edit Log RADEON_DEBUG=fp,vp, maxALU=20, smart renderer

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

--- Comment #16 from PJBrs pjbrs@floorenpj.xs4all.nl --- To be clear-- with "trying different numbers for max_alu_instructions", I mean changing c->Base.max_alu_insts into a number (e.g., 15) in line 157 of the file src/gallium/drivers/r300/compiler/r300_fragprog_emit.c.

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

--- Comment #18 from Tom Stellard tstellar@gmail.com --- Created attachment 79572 --> https://bugs.freedesktop.org/attachment.cgi?id=79572&action=edit Possible Fix

Does this patch fix the bug? If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied.

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

--- Comment #20 from PJBrs pjbrs@floorenpj.xs4all.nl --- P.s., I did a quick glance at the difference between the first bad log and the log with the patch (sdiff badlog patch-test.log | less). It seems as if shader pc8 now is truncated or something...

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

--- Comment #22 from PJBrs pjbrs@floorenpj.xs4all.nl --- This fixes it!--great, thanks very much! Is this patch already in master? And will it also go in the 9.0 / 9.1 stable branches?

Anyway, thanks very much again for your time, glad I could be of some help too.

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

--- Comment #24 from madbiologist s.j.turner@uqconnect.net --- The fix is now also in Mesa 9.1.