Created attachment 30410 [details] Test program The parser for ARB FB shaders uses different values for number constants depending on the locale. It may be using strtod somewhere for parsing numbers which is locale dependent. Please see the attached program which renders a rectangle using a shader with the constant color 0.5, 0.5, 0.5. Under the C locale this appears as a grey rectangle but under a French locale (which uses ',' as the decimal separator) it appears as a black rectangle. This is likely the root cause of this bug in Moblin which is using Mesa 7.6: http://bugzilla.moblin.org/show_bug.cgi?id=6803 Robert Bragg has tested with Mesa git drivers from Oct 12th and they also display the bug.
Created attachment 30414 [details] [review] patch based on Kristian's strtod_l() suggestion Can you test this patch?
Created attachment 30419 [details] [review] Patch to make the lexer use _mesa_strtod (In reply to comment #1) > Can you test this patch? Thanks. I justed it quickly with the xlib driver (I'm assuming it uses the same code path) but it doesn't work. I think the offending strtod is in src/mesa/shader/program_lexer.l. This directly calls strtod instead of the _mesa wrapper. This patch changes the lexer to use the _mesa wrapper which fixes it for me. It seems a shame to fix it just for glibc sources. There is a float parser in ./src/mesa/drivers/dri/common/xmlconfig.c which isn't affected by the locale, I wonder if we could move that somewhere more accesible and use that instead?
I've committed the strtod() -> _mesa_strtod() change to the 7.6 branch. I guess I'd still like to get another opinion on my first patch which uses strtod_l(). Does anyone have any issues with it?
(In reply to comment #3) > I've committed the strtod() -> _mesa_strtod() change to the 7.6 branch. > > I guess I'd still like to get another opinion on my first patch which uses > strtod_l(). Does anyone have any issues with it? It looks exactly like that patch that I was intending to write. It looks good to me.
OK, committed to 7.6 branch 89b31c9619449d5c9b8ebe4e245c2a926e3583e6
It seems the issue is back with the new compiler. Following is the behaviour with nouveau gallium driver: ~ $ LC_ALL=C ./a.out strtod("0.5") = 0.500000 nv50_screen_get_param:162 - Unknown PIPE_CAP 11 before glProgramString glGetError() = 0 after glProgramString glGetError() = 0 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 33 requests (31 known processed) with 0 events remaining. ~ $ LC_ALL=fr_FR.UTF-8 ./a.out strtod("0.5") = 0,000000 nv50_screen_get_param:162 - Unknown PIPE_CAP 11 before glProgramString glGetError() = 0 after glProgramString glGetError() = 0 XIO: fatal IO error 11 (Ressource temporairement non disponible) on X server ":0" after 33 requests (31 known processed) with 0 events remaining. $ glxinfo | grep -i opengl nv50_screen_get_param:162 - Unknown PIPE_CAP 11 OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV96 OpenGL version string: 2.1 Mesa 7.9 OpenGL shading language version string: 1.20 OpenGL extensions:
Created attachment 41062 [details] [review] Use a strtod() wrapper as we did in the old GLSL compiler Can you test this patch?
(In reply to comment #7) > Created an attachment (id=41062) [details] > Use a strtod() wrapper as we did in the old GLSL compiler > > Can you test this patch? Yes, this fixes the problems I encounter (KDE's blur effect works now).
OK, I've committed the patch.
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.