[Mesa-dev] Question about tesselation shader out varyings and transform feedback

[Timothy Arceri]

On Thu, 2016-08-11 at 17:10 +0200, Alejandro Piñeiro wrote:
> On 05/08/16 12:20, Alejandro Piñeiro wrote:
> > 
> > On 05/08/16 01:53, Timothy Arceri wrote:
> > > 
> > > On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > these days I have been trying to fix a test that uses transform
> > > > feedback
> > > > on the out varying of a tessellation shader. The relevant part
> > > > on
> > > > that
> > > > shader is like this:
> > > > 
> > > >    layout (vertices=4) out;
> > > > 
> > > >    out block { vec4 value; } user_out[];
> > > > 
> > > > The test tries to use block.value as the varying name when
> > > > calling
> > > > glTransformFeedbackVaryings, in order to get the data of the 4
> > > > vertices.
> > > > The test fails because on link time, it doesn't find  that
> > > > varying
> > > > name.
> > > > 
> > > > On mesa, when linked, mesa tfeedback_candidate_generator (at
> > > > src/compiler/glsl/link_varyings) adds to the hashmap of
> > > > possible
> > > > varyings for transform feedback the following names:
> > > > block[0].value,
> > > > block[1].value, block[2].value, block[3].value. If I change the
> > > > test
> > > > to
> > > > use those 4 varyings names, instead of try to get the array
> > > > directly,
> > > > the test passes.
> > > > 
> > > > So now is the moment to justify who is wrong per-spec, if mesa
> > > > or the
> > > > test. At this moment Im biased to conclude that the test is
> > > > wrong.
> > > > But
> > > > after reading transform feedback specs (ext, feedback2,
> > > > feedback3,
> > > > gl44)
> > > > and tessellation shader, I was not able to find anything.
> > > > 
> > > > Could someone (I bet that the best person is Timothy Arceri)
> > > > guide me
> > > > a
> > > > little to know in which part of the spec should I look for?
> > > For block arrays block[0].value,> block[1].value, block[2].value,
> > > block[3].value are the correct strings for matching transform
> > > feedback
> > > varyings. I forget which spec states this but its in there
> > > somewhere I
> > > recall looking for it and finding it.
> > Ok, thanks for confirming. BTW, while looking for info for this
> > email
> > (see below) I found this paragraph at ARB_separate_shader_objects,
> > that
> > I think that is what I was searching:
> > 
> >     Tessellation control shader per-vertex output variables and
> > blocks and
> >     tessellation control, tessellation evaluation, and geometry
> > shader
> >     per-vertex input variables and blocks are required to be
> > declared as
> >     arrays, with each element representing input or output values
> > for a single
> >     vertex of a multi-vertex primitive.  For the purposes of
> > interface
> >     matching, such variables and blocks are treated as though they
> > were not
> >     declared as arrays.
> > 
> > 
> > Specifically the last sentence. What do you think?
> 
> I think that I found a better part of the spec. From GL spec 4.4,
> section "7.3.1 Program interfaces":
> 
> "For interfaces involving variables, interface blocks, or
> subroutines,
> the entries of active resource lists are
> generated as follows:"
> <skip some bullet points>
> "• For an active interface block declared as an array of instances,
> separate en-
> tries will be generated for each active instance. The name of the
> instance
> is formed by concatenating the block name, the "[" character, an
> integer
> identifying the instance number, and the "]" character."
> 
> Although I think that it is clear, Timothy, do you mind to confirm if
> that paragraph justifies properly that the test was wrong, and needs
> to
> use block[1].value, block[2].value, etc?

No, as I said before I think you likely need to remove the outermost
array from tcs outputs. See: get_varying_type()

> 
> Thanks in advance.
> 
> BR
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev