[Mesa-dev] [Bug 55503] New: Constant vertex attributes broken

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 55503
          Assignee: mesa-dev at lists.freedesktop.org
           Summary: Constant vertex attributes broken
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: robert at sixbynine.org
          Hardware: Other
            Status: NEW
           Version: git
         Component: Mesa core
           Product: Mesa

Created attachment 67932
  --> https://bugs.freedesktop.org/attachment.cgi?id=67932&action=edit
Standalone gles2 test using const attributes

We recently added support in Cogl for using constant attributes which we want
to use as part of a UI runtime + editor we are currently working on but I'm
finding that they don't work with Mesa, even when using
LIBGL_ALWAYS_SOFTWARE=1.

I was able to reproduce the issue in a standalone gles2 test case which I've
attached and hopefully that will help clarify the problem.

I spent a bit of time trying to debug the issue myself yesterday, and although
I can't say I quite got my head around how the attribute state moves around I
did  managed to cobble together a patch that works for me. The thing I found
that looked amiss was in recalculate_input_bindings in the VP_ARB case:

      if (vertexAttrib[VERT_ATTRIB_GENERIC0].Enabled)
         inputs[0] = &vertexAttrib[VERT_ATTRIB_GENERIC0];
      else if (vertexAttrib[VERT_ATTRIB_POS].Enabled)
         inputs[0] = &vertexAttrib[VERT_ATTRIB_POS];
      else {
         inputs[0] = &vbo->currval[VBO_ATTRIB_POS];
         const_inputs |= VERT_BIT_POS;
      }

      <snip/>

      for (i = 1; i < VERT_ATTRIB_GENERIC_MAX; i++) {
         if (vertexAttrib[VERT_ATTRIB_GENERIC(i)].Enabled)
            inputs[VERT_ATTRIB_GENERIC(i)] =
&vertexAttrib[VERT_ATTRIB_GENERIC(i)];
         else {
            inputs[VERT_ATTRIB_GENERIC(i)] =
&vbo->currval[VBO_ATTRIB_GENERIC0+i];
            const_inputs |= VERT_BIT_GENERIC(i);
         }
      }

Given that the test is a gles2 test I wouldn't expect that we should be special
casing inputs[0] and in this case it is also legitimate for
vertexAttrib[VERT_ATTRIB_GENERIC0] to be disabled which I guess shouldn't lead
us to refer to the legacy _POS attribute which is what it looks like is
happening. Also the loop that comes later to iterate the generic attributes
then starts at index 1 assuming that we've already dealt with 0 as a special
case which doesn't seem right for gles2.

I hacked the code like this to do what I guessed made more sense for gles2:

--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -473,11 +473,18 @@ recalculate_input_bindings(struct gl_context *ctx)
        * Otherwise, legacy attributes available in the legacy slots,
        * generic attributes in the generic slots and materials are not
        * available as per-vertex attributes.
+       *
+       * If we aren't running with the legacy GL profile, with deprecated
+       * features, (GLES2 or GL_CORE) then generic[0] has its own current
value
+       * instead of being an alias for the legacy position array.
        */
       if (vertexAttrib[VERT_ATTRIB_GENERIC0].Enabled)
         inputs[0] = &vertexAttrib[VERT_ATTRIB_GENERIC0];
-      else if (vertexAttrib[VERT_ATTRIB_POS].Enabled)
-        inputs[0] = &vertexAttrib[VERT_ATTRIB_POS];
+      else if (ctx->API != API_OPENGL) {
+        inputs[0] = &vbo->currval[VBO_ATTRIB_GENERIC0];
+         const_inputs |= VERT_BIT_GENERIC(0);
+      } else if (vertexAttrib[VERT_ATTRIB_POS].Enabled)
+         inputs[0] = &vertexAttrib[VERT_ATTRIB_POS];
       else {
         inputs[0] = &vbo->currval[VBO_ATTRIB_POS];
          const_inputs |= VERT_BIT_POS;

and that seems to fix the test app for me. I had also tried skipping out the
whole inputs[0] special case if API==API_OPENGL, and basing the following for
loops at i = 0 but for some reason that doesn't work so I guess other things
are assuming that inputs[0] is a bit special.

If you look at the attached test there are a few #ifdefs I left in there to
affect the test. In create_shaders() there is an #if 0 to simply swap the order
of the two constant attributes in the glsl and for me this results in the
output color changing. There is an #ifdef to use glBindAttribLocation which
makes the test work for me. Finally there are #ifdefs to switch to using
glVertexAttribPointer instead of glVertexAttrib[24]f that also make the test
work.

When working, the test should output a constant pinky-purple (0xff00ffff)
across the whole window, whereas I see red or blue depending on the order of
the attribute declarations in the glsl.

The color output by the fragment shader takes the red and green and alpha
components from the "test" attribute and the blue component comes from the .s
component of the "tex_coord" attribute. Although it looks awkward, I just did
that to make sure the v_tex_coord varying and tex_coord attribute wouldn't
somehow be optimized out due to not being referenced.

I'll also attach my initial Mesa patch that appears to work for me.

-- 
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/20121001/4d4fa0d2/attachment-0001.html>