Yes, it's clear now. Thanks. Marek
On Sun, May 20, 2018 at 3:05 AM, Mathias Fröhlich <mathias.froehl...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
