<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Constant vertex attributes broken"
href="https://bugs.freedesktop.org/show_bug.cgi?id=55503">55503</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>Constant vertex attributes broken
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Reporter</th>
<td>robert@sixbynine.org
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>git
</td>
</tr>
<tr>
<th>Component</th>
<td>Mesa core
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=67932" name="attach_67932" title="Standalone gles2 test using const attributes">attachment 67932</a> <a href="attachment.cgi?id=67932&action=edit" title="Standalone gles2 test using const attributes">[details]</a></span>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>