<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - corrupted GLSL built-in function results when using Uniform Buffer contents as arguments" href="https://bugs.freedesktop.org/show_bug.cgi?id=57121#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - corrupted GLSL built-in function results when using Uniform Buffer contents as arguments" href="https://bugs.freedesktop.org/show_bug.cgi?id=57121">bug 57121</a> from <a class="email" href="mailto:tomek-k@wp.eu" title="Tomasz Kaźmierczak <tomek-k@wp.eu>"> Tomasz Kaźmierczak</a> <pre>Hi, I'll try to create a small test program for that if I find some time, but for now I'm sending an apitrace file. The meshes get loaded in frame 137 and the bug is visible then (they get transformed to their propper positions in the next frame - It's just my app's behaviour, something I still haven't fixed). I didn't mention that, just to not complicate things, but I actually use the pow() function twice - for specular reflections and for gamma correction (the gamma value also comes from a UBO and using it as an argument for pow() magnifies the problem). It is not required to use pow() function in order to reproduce the bug - you can also use normalize() on a vector that comes from a UBO (eg. on a diffuse color), and probably other built-in functions would behave similarly (haven't checked that). However, I only checked that on uniforms that provide color information, and I guess the problem is best visible then. Some comments about the trace: - the trace comes from a program which is a Qt GUI application that uses QGLWidget - don't know whether this has any influence on the bug (eg. the GL context creation or something) - When you replay the trace, you can notice that some pixels on the meshes flicker; this, of course, doesn't happen when the u_SpecularHardness and u_InverseGamma come from the default uniform block - I've looked at the state of the uniforms inside apitrace, and their values are weird: u_DiffuseColor and u_SpecularColor are equal to u_LightPosition (this uniform comes from glUniform() function, not from a UBO), the other material uniforms all have value of 50, which is equal to u_LightPosition.x; similar is with u_CameraPosition and the matrices they all display the same values (all near 0); generally, only the light-related uniforms have propper values (all the light uniforms come from the default uniform block). With such values not many things would be rendered properly, so the apitrace shows wrong UBO uniform values.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>