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

[Alejandro Piñeiro]

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?

> However user_out[] looks like it would be coming from a tess control
> shader right? 

Yes, true, it is a tessellation control shader.

> In which case we would want to ignore the outer array,

It will be ignored on execution, but I think that needs to be took into
account when linking (see below for a full explanation).

> however I'm not sure how well Mesa supports transform feedback from
> tcs.

I don't think that transform feedback with tcs is working, or should work.

So, why worry about all this? Going a little on the detail of what it is
happening:

What this test tries is check if the behaviour defined by
separate_shader_objects. So it creates several shaders and programs, and
then tries different combinations when using those programs on a
pipeline, checking the correct behaviour and data at the TF buffer.

So, you can create a program with only a TESS_CONTROL_SHADER, and built
it. And at the same time, as far as I see, there is nothing on desktop
GL preventing you to set the varyings with glTransformFeedbackVaryings
on that program. So when linking it would try to look for those varyings.

But then, on execution, it already acknowledges that a pipeline with a
tc but not a tes (the only hypothetical way to transform feedback
getting the tc output) is wrong, so that combination is a negative
subtest. So on that subcase, it checks for a failure, and skip the
"correct data check".

But I agree that is somewhat strange to allow to set the varying on a
control shader program, when you are not going to get the values of that
varying. But as it is not forbidden, I think that we can't just ignore
it on link time, as it would be needed to check if it is correctly set
(like in this case). Having said so, the test itself mentions that
creating a control shader program with feedback is wrong on ES (didn't
find the ES-spec reference forbidding it), so I guess that at some point
someone realized that this was odd and fixed it for ES.

BR