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?
Thanks in advance.
BR
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
