[Mesa-dev] intel: FS compile failed: no register to spill

[Kenneth Graunke]

On 10/10/2012 09:02 AM, Johannes Stezenbach wrote:
> Hi,
>
> I'm experimenting with texture interpolation and seeing this error:
>
>    Mesa 8.0.4 implementation error: Failed to compile fragment shader: FS compile failed: no register to spill
>
>    Please report at bugs.freedesktop.org
>
> It seems the issue is already known, I found
> https://bugs.freedesktop.org/show_bug.cgi?id=48375

Actually, your issue is a bit different: that bug is about spilling in 
the vertex shader, while yours is in the fragment shader.

So I don't think it is known - thanks for the report!

> and
> http://code.google.com/p/chromium-os/issues/detail?id=28524
>
> I'm using Debian unstable amd64 on Sandy Bridge Core i5-2400S.
>
> It seems the fix for the chromium-os issue is in Mesa 9.0 but not in 8.0.4,
> thus I fetched the Debian source package and recompiled with the fix
> applied, but it did not help in my case.
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=8890c759513597903997f519c69e9db30790b6f4
>
> Because issue 48375 talked about loops and functions I tried
> to manually inline all functions, but to no avail.  In a second
> attempt I tried to unroll the loop manually which works.
>
> Attached is a (stripped-down) Python-OpenGL script and fragment shader
> which demonstrates the issue.  The shader code is taken from
> http://www.codeproject.com/Articles/236394/Bi-Cubic-and-Bi-Linear-Interpolation-with-GLSL
> (shader coding style ugliness is from the original source)
> The script doesn't do anything useful, in the ideal case it
> would just print "now" and "end" without throwing an error.
>
> BTW, the compile error is thrown at glutSwapBuffers() not at
> glCompileShaderARB() time.  Is there a way to force the error
> to show up earlier?

It ought to show up at glLinkShader() time if you're using Mesa 9.0. 
For earlier versions, I believe you can "export shader_precompile=true" 
before running your program to get it thrown earlier.

> Is that the current state of affairs that using loops in GLSL is
> basically broken on Intel?  Any hope to get it fixed?
>
> Thanks
> Johannes

I've seen a lot of shaders with loops that work just fine, so I think 
yours is just a bit tougher on the compiler than we've seen before. 
We'll take a look soon.