On 12/08/16 02:14, Timothy Arceri wrote:
> 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()
Perhaps Im being somewhat thick, but I don't see anything on that method
that prevents to call glTransformFeedbackVaryings for a tcs.
But to be clear: I know that the simpler solution would remove the call
of glTransformFeedbackVaryings for that tcs, justifying it because those
varyings will not be recorded. As I mentioned on the other email of that
thread, I recognize that allowing to call glTransformFeedbackVaryings on
a tcs is somewhat silly, taking into account that those varyings are not
going to be recorded. But the test code already recognizes it, and just
uses it to do a negative test. As I already said, nothing prevents to
call glTransformFeedbackVaryings on a tcs, so we should be sure that the
names used are correct, and would be a smaller change on that given test.
BR
Obviously, the simpler way to
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
