Any chance of a bisect?  That would help narrow down the problem.

Yes. I'll make a few compiles and try to narrow down the cause as much as possible. I'll get back to you.

Was just about to report this. It seem to be a miss compilation of the GLSL shader. Just dropping color output from one of the source textures resolves the issue.

The shader takes three textures put them in a vector and does a matrix multiplication to convert yuv to rgb. (simplified as below)

  vec4 yuv, rgb;
  yuv.rgba = vec4( texture2D(m_sampY, m_cordY).r
                 , texture2D(m_sampU, m_cordU).g
                 , texture2D(m_sampV, m_cordV).a
                 , 1.0 );

  rgb   = m_yuvmat * yuv;
  rgb.a = gl_Color.a;
  gl_FragColor = rgb;


Only one of the elements in the rgba ends up wrong after matrix multiplication. Writing the sampled data from the texture directly to output does not yield the error.

I'll attached the shader.

Created attachment 55089 [details]
YUV to RGB shader

Forgot to say that only define set for that shader is XBMC_YV12, the others are not.

I found the problematic commit, after a long search:

It is called: i965: Avoid generating MOVs for most ir_assignment handling.
And is here: http://cgit.freedesktop.org/mesa/mesa/commit/?id=dc7f449d1ac53a66e6efb56ccf2a5953418a26ca

With a revert patch for current master, everything is fine again:
http://pastebin.com/cLpMCXwg

Please check if there is another solution than ti revert it!

Thank you! Regards, Alan

Created attachment 55689 [details] [review]
Possible fix for the optimization

Does the attached patch (against Mesa master) solve the issue for you?  It's kind of a stab in the dark, but worth a try...

Hi Kenneth !

Unfortunately this patch did not help.

Alright, thanks.

Shameless bump. Issue still remain. It's a bit annoying to not being able to use GLSL shaders in xbmc on intel hardware now that they have started become quite usable otherwise.

Can i get you guys some other logs to figure out why it get's misscompiled?

Actually, I was finally able to reproduce this.  For some reason, XBMC appears to crash the Fedora 16 X server, but my Archlinux system works.  Now that I can see the issue first-hand, I should be able to track it down.  Sorry for the delay.

Obvious two-line fix posted to the mailing list:
http://lists.freedesktop.org/archives/mesa-dev/2012-February/018969.html

With the patch, my cartoons are no longer toxic green. :)

I should be able to get this into Mesa 8.0.1, which is due out shortly.

Awesome to hear!

Thank you for the fix Kenneth,

Cheers !

Turns out that was a bit overzealous.

The bug is fixed in master via the following commits:

commit 4b274068204c7f0bacaa4639f24feb433353b861
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Feb 14 12:43:22 2012 -0800

    i965/fs: Take # of components into account in try_rewrite_rhs_to_dst.
    
    Commit dc7f449d1ac53a66e6efb56ccf2a5953418a26ca introduced a new method
    for avoiding MOVs: try to rewrite the destination of the instruction
    that produced the RHS so it writes into the LHS.
    
    Unfortunately, this is not safe for swizzled texturing operations, as
    they return a set of four contiguous registers.  Consider the following:
    
    (assign (x)
            (var_ref vec_ctor_x)
            (swiz x (tex vec4 (var_ref m_sampY) (var_ref m_cordY) 0 1 ())))
    
    In this case, the source and destination registers are equal, since
    reg_offset is 0 for both.  Yet, this is only a partial move: the texture
    operation generates four registers, and the LHS only covers one.
    
    Fixes color distortion in XBMC when using GLSL shaders.
    
    NOTE: This is a candidate for the 8.0 branch (with the previous commit).
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44333
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

commit 8ab02b511882857a09fceed0e93bf4a0b25c17b2
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Feb 14 12:43:21 2012 -0800

    i965/fs: Add a new fs_inst::regs_written function.
    
    Certain instructions write more than one register.  Texturing, for
    example, returns 4 registers.  (We set rlen to 4 even for TXS and float
    shadow sampling.)  Some math functions return 2.  Most return 1.
    
    The next commit introduces a use of this function.
    
    NOTE: This is a candidate for the 8.0 branch (dependency of a fix).
    
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

I've also cherry-picked these to the 8.0 branch, so they'll show up in Mesa 8.0.1 which should be coming out in a day or two.

Thanks for the bug report and the great help!  The bisect and shader analysis were both very helpful.