Bug 49088 - MapsGL labels doen't render properly on nouveau, r600, i965
Summary: MapsGL labels doen't render properly on nouveau, r600, i965
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 8.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
: 49237 (view as bug list)
Depends on:
Reported: 2012-04-23 13:19 UTC by Alex Mayorga Adame
Modified: 2012-06-06 23:06 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

hd6770+mesa-git (482.05 KB, image/jpeg)
2012-04-26 16:30 UTC, Iaroslav Andrusyak
patch (1.25 KB, patch)
2012-04-28 07:18 UTC, Vadim Girlin
Details | Splinter Review
[PATCH] glsl: initialize samplers mapping with 0 (2.41 KB, patch)
2012-04-28 23:52 UTC, Vadim Girlin
Details | Splinter Review

Description Alex Mayorga Adame 2012-04-23 13:19:27 UTC
Something messed up MapsGL at http://maps.google.com/?vector=1 with this configuration:

alex-mayorga@VPCCW1FFXL:~$ uname -a
Linux VPCCW1FFXL 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20120423 Firefox/14.0a1 ID:20120423034053

Adapter Description nouveau -- Gallium 0.4 on NVA5
Vendor ID nouveau
Device ID Gallium 0.4 on NVA5
Driver Version 2.1 Mesa 8.0.2
WebGL Renderer nouveau -- Gallium 0.4 on NVA5 -- 2.1 Mesa 8.0.2
GPU Accelerated Windows 0
AzureBackend skia

This is how the map looks http://imm.io/n1PJ street names are not visible. Same garbled labels appear on Chromium.

At first I thought it was a bug on Firefox and reported it as https://bugzilla.mozilla.org/show_bug.cgi?id=745481

Also reported it to the distribution (Ubuntu) as https://bugs.launchpad.net/ubuntu/+bug/981883

Both bug reports suggested this was a problem "upstream" and suggested I filed the issue here so I'm doing that.
Comment 1 Karl Tomlinson 2012-04-26 14:41:12 UTC
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.
Comment 2 Kenneth Graunke 2012-04-26 15:04:24 UTC
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 :)
Comment 3 Iaroslav Andrusyak 2012-04-26 16:30:31 UTC
Created attachment 60641 [details]

Opera+hd6770+mesa-git looks fine, i see no problem.
Comment 4 Alex Mayorga Adame 2012-04-27 18:00:47 UTC
(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
Comment 5 Kenneth Graunke 2012-04-27 21:47:31 UTC
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.
Comment 6 Benoit Jacob 2012-04-28 06:26:58 UTC
I confirm that MapsGL is known to use textures in vertex shaders when possible.
Comment 7 Vadim Girlin 2012-04-28 07:18:30 UTC
Created attachment 60740 [details] [review]

Does this patch help?
Comment 8 Nicholas Miell 2012-04-28 10:29:05 UTC
*** Bug 49237 has been marked as a duplicate of this bug. ***
Comment 9 Nicholas Miell 2012-04-28 10:30:19 UTC
(In reply to comment #7)
> Does this patch help?

It helps me.
Comment 10 Rafael Monica 2012-04-28 16:32:03 UTC
Patch fixes label rendering with MapsGL, but breaks GL output with mplayer (mplayer -vo gl ..)
Comment 11 Nicholas Miell 2012-04-28 18:10:05 UTC
Can confirm mplayer breakage -- a simple white-on-black ESRB rating screen is rendered purple-on-green.

Fragment program in question is:

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;
Comment 12 Vadim Girlin 2012-04-28 23:52:46 UTC
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.
Comment 13 Alex Mayorga Adame 2012-05-27 08:32:35 UTC
How do I test the patch?

Please dumb down the instructions as much as possible ;-)
Comment 14 Eric Appleman 2012-06-01 20:28:23 UTC
Confirming on Sandy Bridge HD3000 (i965).
Comment 15 Kenneth Graunke 2012-06-06 23:06:12 UTC
Working in Mesa master, with Ian's version of the patches.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.