[Mesa-dev] [Bug 57121] New: corrupted GLSL built-in function results when using Uniform Buffer contents as arguments

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57121

          Priority: medium
            Bug ID: 57121
          Assignee: mesa-dev at lists.freedesktop.org
           Summary: corrupted GLSL built-in function results when using
                    Uniform Buffer contents as arguments
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: tomek-k at wp.eu
          Hardware: All
            Status: NEW
           Version: 9.0
         Component: Other
           Product: Mesa

In a shader code when I use, for example, the pow() function with uniforms as
arguments, everything is ok if the uniform resides in the default uniform block
(value passed from the client code using the glUniform() function). However, if
the uniform is a part of a named uniform block (comes from a uniform buffer
object, UBO), the result of the pow() function is corrupted.

Please see the screenshots attached to the report. In my code I use the pow()
function for calclulating specular reflection intensity:
float reflectionIntensity = u_SpecularIntensity * pow(reflectionAngle,
u_SpecularHardness);
(the u_SpecularIntensity is a parameter of the material, just as the
u_SpecularHardness; reflectionAngle a local variable)

When both u_SpecularIntensity and u_SpecularHardness are defined inside a named
uniform block and their contents come from a UBO, the data corruption can be
observed - the result is shown on uniform_from_UBO.png (the undesired effect).
But when the u_SpecularHardness is just a "normal" uniform variable and it's
value is set using a glUniform() function, everything is ok (see the
normal_uniform.png file).

It doesn't matter whether the other uniform variable (u_SpecularIntensity)
comes from UBO or not - it never causes any rendering issues. This means that
the problem is only when a UBO uniform variable is used as an argument of a
built-in function (adding, subtracting and multiplying UBO variables seems to
work fine).

In order to check whether this is only an issue of pow(), I've also checked
normalize(). The easiest way was to normalize a diffuse color (a vec4). The
results were similar as in case of pow() (and again, when normalizing a diffuse
color that is passed to the shader using the glUniform() function, everything
is ok).

I've also found out that when I add some value to the u_SpecularHardness, store
the result in a local variable and use that local variable in pow(), then the
corruption is gone (simply assigning the u_SpecularHardness to a local variable
is not enough - it seems like the compiler optimizes-out the variable in such
case and refers directly to the uniform buffer).


Where it happens?

I've noticed this on a system with Intel HD Graphics 3000 (Sandy Bridge) GPU.
I'm not sure whether this is specific to Mesa in general or to the graphics
driver (lsmod says that the driver in use is the i915), therefore I've selected
"Other" as the Mesa component.

On a system with an AMD GPU and the proprietary fglrx driver the bug doesn't
exist, so I'm sure that it's not a problem with my OpenGL client code. I've
also ruled out the possibility that it could be caused by impropper alignment
of data inside the buffer (this happens even if both the uniform buffer and the
uniform block contain only one floating point variable, and I use the std140
layout for all of my uniform blocks).

In my GLSL code I use the following two directives at the beginning of all
files:
#version 130
#extension GL_ARB_uniform_buffer_object : require

It happens in both vertex and fragment shaders.

Some Mesa information:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL version string: 3.0 Mesa 9.0
OpenGL shading language version string: 1.30

As mentioned above, the driver in use is i915.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20121114/63614af7/attachment-0001.html>