On Mon, Oct 5, 2015 at 3:33 AM, Tapani Pälli <tapani.pa...@intel.com> wrote: > > > On 10/05/2015 10:21 AM, Ilia Mirkin wrote: >> >> On Mon, Oct 5, 2015 at 3:14 AM, Tapani Pälli <tapani.pa...@intel.com> >> wrote: >>> >>> Commit 4639cea2921669527eb43dcb49724c05afb27e8e added packed varyings >>> as part of program resource list. We need to take this to account with >>> all functions dealing with active input attributes. >> >> >> Don't you have this same problem with output attributes as well? Is >> the situation here that the packed varying pass adds its own varyings >> on top of the usual ones, and so things were getting (essentially) >> double-counted? > > > As far as I see the problem is only with active attribute variables, > glGetActiveAttrib used to take in to account all resources with input type > (as it was just calling _mesa_program_resource_find_index). Now it > explicitly checks that varyings are not counted as active attribute > variables. > > For querying outputs via program resource queries I don't see any > regressions on the current tests so I'm not convinced there is such problem. > > For fragment shader outputs there is a problem but I consider it separate > from this. Mesa lowers fragment output array as series of variables like > 'gl_out_FragData0, gl_out_FragData1 ..' while user expects there to be > 'array[0], array[1] ..' and query for array[0] does not match > gl_out_FragData0. This one I was planning to tackle next.
Oh, well fragment shader outputs don't get packed, so that's not an issue. There's no way to query the inter-stage stuff? Then what does this have to do with packing in the first place? Not like vertex attributes can get packed either... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
