I see the same issue with r600

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20
OpenGL extensions:

but sw works as expected.

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x209)
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20

suggesting the problem is in a more core component, possibly dri2-specific.

I'm seeing this on i965/Sandy Bridge as well, so maybe it's something in Core Mesa?  Either that or we all have similar bugs :)

Created attachment 60641 [details]
hd6770+mesa-git

Opera+hd6770+mesa-git looks fine, i see no problem.

(In reply to comment #3)
> Created attachment 60641 [details]
> hd6770+mesa-git
> 
> Opera+hd6770+mesa-git looks fine, i see no problem.

It doesn't look like like you're using MapsGL[1] from the screen capture.

Please try to replicate using http://maps.google.com/?vector=1

[1] http://maps.google.com/support/bin/answer.py?hl=en&answer=1630790

On the i965 driver, I tracked it down to the commit where I started advertising vertex shader texture units.  I also noticed that the rendering is broken using classic swrast (LIBGL_ALWAYS_SOFTWARE=1), but if I hacked swrast to advertise 0 VS texture image units, then it worked.

Obviously MapsGL is changing its rendering technique when VS texturing is present (or not), but I suspect that there's something broken in core Mesa related to VS texturing.

I confirm that MapsGL is known to use textures in vertex shaders when possible.

Created attachment 60740 [details] [review]
patch

Does this patch help?

*** Bug 49237 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> Does this patch help?

It helps me.

Patch fixes label rendering with MapsGL, but breaks GL output with mplayer (mplayer -vo gl ..)

Can confirm mplayer breakage -- a simple white-on-black ESRB rating screen is rendered purple-on-green.

Fragment program in question is:

!!ARBfp1.0
OPTION ARB_precision_hint_fastest;
TEMP coord, coord2, cdelta, parmx, parmy, a, b, yuv;
TEX yuv.r, fragment.texcoord[0], texture[0], 2D;
TEX yuv.g, fragment.texcoord[1], texture[1], 2D;
TEX yuv.b, fragment.texcoord[2], texture[2], 2D;
PARAM ycoef = {1.164000e+00, 1.164000e+00, 1.164000e+00};
PARAM ucoef = {0.000000e+00, -3.910000e-01, 2.018000e+00};
PARAM vcoef = {1.596000e+00, -8.130000e-01, 0.000000e+00};
PARAM offsets = {-8.741648e-01, 5.313256e-01, -1.085992e+00};
TEMP res;
MAD res.rgb, yuv.rrrr, ycoef, offsets;
MAD res.rgb, yuv.gggg, ucoef, res;
MAD res.rgb, yuv.bbbb, vcoef, res;
MOV result.color.rgb, res;
END

Created attachment 60756 [details] [review]
[PATCH] glsl: initialize samplers mapping with 0

Yes, initial patch wasn't completely correct. I've sent another version to the mesa-dev list already, but forgot to attach it to this bug for testing.

How do I test the patch?

Please dumb down the instructions as much as possible ;-)

Confirming on Sandy Bridge HD3000 (i965).

Working in Mesa master, with Ian's version of the patches.