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