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