[Mesa-dev] [PATCH 4/4] mesa: The glArrayElement api is independent of the current program.

[Mathias Fröhlich]

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