Good morning, > Are you sure about this? The fixed-func vertex and fragment shaders can > move zero-stride vertex attribs into constants (uniforms). If a shader > changes, it might no longer be necessary to submit zero-stride attribs via > the vertex API, but this would be missed if _NEW_PROGRAM was ignored.
If I get your question right then this is something that happens further down the road. So, the array element api, just looking at the code what it does and what it reads, Just takes a VAO, maps it and walks all the vertex at the index provided with glArrayElement. Then for that given index all enabled vertex attributes just provided the vertex attributes enabled state are put into the immediate mode api. Also the decision of if it should take the VERT_ATTRIB_POS or VERT_ATTRIB_GENERIC0 attribute to trigger the immediate mode vertex is completely taken from the enabled state in the VAO. With enabled state I really mean the application observable OpenGL api that you modify with glEnableVertexAttribArray and query using the GL_VERTEX_ATTRIB_ARRAY_ENABLED enum and that you find in gl_array_attributes::Enabled and condensed in the gl_vertex_array_object::_Enabled bitmask, both within the VAO. Given that no shader related value is evaluated from the code triggered by _ae_invalidate_state I would say I am sure about that. Putting current values into uniforms happens in the draw code path where we mute some may be enabled arrays from the VAO based on the shader mode. That again is only the decision if some of the generics contain material array values from within the vbo module or if these generics are really generics that must not be evaluated from ffvertex_prog.c. Based of these enables, not looking at zero strides, ffvertex_prog.c creates a vertex shader that exactly reads those arrays that are enabled and not generally muted from vertex processing due to gl_vertex_processing_mode. The result of ffvertex_prog.c is a shader that reads some VERT_ATTRIB_* values and put aside double inputs has exactly those VERT_BIT_* bits set in ...inputs_read that are required due to the current OpenGL fixed function state and the currently enabled array. Based on the ...inputs_read and the finally provided arrays from the VAO, the driver backends (well, the consumers like i965, gallium or TNL) only upload/configure those enabled arrays which are consumed by the shader. Putting that together, I can see current vertex attribute values being taken from uniforms if they are not enabled in the ctx->Array._DrawVAO. Back to the array element api to see that program mode is not required from there by an other argument: That VAO that is replayed by glArrayElement may never hit the draw path as from those immediate mode calls that the glArrayElement api generates, mesa assembles a new VAO/VBO in the vbo module that is finally either kept in a display list or used for immediate mode rendering. Depending on which VERT_ATTRIB_* arrays are enabled in this vbo module created VAO, ffvertex_prog may be triggered if we are about to draw something fixed function related. Also from that thought you can see that changes to shader program state do not affect the way the VAO should get replayed from the glArrayElement api. They *do* affect the way the resulting VAO produced by the vbo module is processed, but that is nothing that is handled from _ae_invalidate_state. Hope this helps? best Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
