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

[Marek Olšák]

Yes, it's clear now. Thanks.

Marek

On Sun, May 20, 2018 at 3:05 AM, Mathias Fröhlich <Mathias.Froehlich at gmx.net
> wrote:

> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180520/18d18dcb/attachment-0001.html>