Bug 28606

Created attachment 36364 [details]
The output with RADEON_DEBUG=fp

The is with a Radeon 9600 rv350, and fglrx used to do this effect fine on the same card.

Looks like the problematic shader should fit just fine. Deserves a closer look.

The real problem with the r300 compiler is scheduling of TEX blocks, which is done against the r300 hardware (r500 is ok here). I've had a closer look at a shader from etqw which creates about 10 TEX blocks on r300 even though there are NO texture indirections. The instructions just have wrong ordering and that is the only reason the shader doesn't fit in hardware.

(In reply to comment #4)
> The real problem with the r300 compiler is scheduling of TEX blocks, which is
> done against the r300 hardware (r500 is ok here). I've had a closer look at a
> shader from etqw which creates about 10 TEX blocks on r300 even though there
> are NO texture indirections. The instructions just have wrong ordering and that
> is the only reason the shader doesn't fit in hardware.

I think this bug is slightly different from the problem you are seeing with etqw.  The problem here is that the compiler is handed several TEX blocks and can't combine them into a single block.  It sounds like the problem with etqw is the same as https://bugs.freedesktop.org/show_bug.cgi?id=25109 where the compiler receives a large TEX block and can't keep all the instructions together.

A possible fix for this bug is to do some kind of register renaming before the scheduling.  Even though the TEX instructions are independent of each other, the scheduler can't schedule them together because they all write to the same register.  If each destination register for these TEX instructions were renamed to something unique, I think the scheduler would schedule them correctly.

(In reply to comment #5)
> I think this bug is slightly different from the problem you are seeing with
> etqw.  The problem here is that the compiler is handed several TEX blocks and
> can't combine them into a single block.  It sounds like the problem with etqw
> is the same as https://bugs.freedesktop.org/show_bug.cgi?id=25109 where the
> compiler receives a large TEX block and can't keep all the instructions
> together.
> 
> A possible fix for this bug is to do some kind of register renaming before the
> scheduling.  Even though the TEX instructions are independent of each other,
> the scheduler can't schedule them together because they all write to the same
> register.  If each destination register for these TEX instructions were renamed
> to something unique, I think the scheduler would schedule them correctly.

You're right that the bug I was talking about is different from this one, but it's also different from 25109. My respond continues here:
https://bugs.freedesktop.org/show_bug.cgi?id=28624#c2

Created attachment 36773 [details] [review]
Proposed fix

Can you try this patch and post your RADEON_DEBUG=fp output again.

Created attachment 36774 [details]
compiz crash backtrace

It crashes in the driver. Here is the bt.

Created attachment 36839 [details] [review]
Possible Fix.

Can you try again with this patch.

Created attachment 36845 [details]
compiz crash

(In reply to comment #9)
> Created an attachment (id=36839) [details]
> Possible Fix.
> 
> Can you try again with this patch.

This patch works, but it only worked the first time I tried it. Since restarting compiz, it crashes after falling back to software routines for whatever reason. It doesn't matter if the effect is enabled at (compiz) runtime or if it's disabled at runtime then enabled after compiz has fully started. I have attached the bt.

(In reply to comment #9)
> Created an attachment (id=36839) [details]
> Possible Fix.
> 
> Can you try again with this patch.

(In reply to comment #10)
> Created an attachment (id=36845) [details]
> compiz crash
> 
> (In reply to comment #9)
> > Created an attachment (id=36839) [details] [details]
> > Possible Fix.
> > 
> > Can you try again with this patch.
> 
> This patch works, but it only worked the first time I tried it.

Because I failed to use the gallium driver. This bt is from classic mesa and can be ignored.

Created attachment 36891 [details] [review]
Final patch

I cleaned up the old patch a little bit, can you confirm that this one still works.

Fix in mesa git master commit: 8a8e311d8c3c60982d101826a4aa013672730e6c