[Mesa-dev] V2 ARB_enhanced_layouts packing support for i965 Gen8+

[Timothy Arceri]

On Sat, 2016-06-11 at 23:51 -0700, Kenneth Graunke wrote:
> On Saturday, June 11, 2016 9:03:20 AM PDT Timothy Arceri wrote:
> > 
> > V2:
> > - validation fixes patches 1-2
> > - added support for packing doubles now that explicit location
> >  fixes have landed.
> > - fix various issues with intel debug output with new COMPONENT
> > const index.
> > 
> > This adds component packing support for Gen8+.
> > 
> > Series can be found in my component_packing_backend4 branch:
> > 
> > https://github.com/tarceri/Mesa_arrays_of_arrays.git
> Patches 1-4, 7-9, 11-13, 15-16 are:
> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
> 
> Or in other words, I'm still thinking about arrays and
> num_packed_components.

I've been going looking at alternatives for the best part of today. I
think I have a way to avoid passing num_packed_components into the
type_size() functions, but I don't see an easy way to avoid using
the num_packed_components field altogether.

I don't believe we can eliminate the nir_assign_var_locations()
function either. The function creates sequential driver_locations,
using the existing data.location would not give you this due to
explicit locations.
More importantly the function also counts the total size of the
varyings and uses it to create a large enough register so we can apply
the driver_location offsets to it. This is actually important for
packing since we could have something like.

layout(location = 0) out float a[3];
layout(location = 0, component = 1) out vec3 b[6];
layout(location = 3) out float c[6];
layout(location = 6, component = 1) out vec3 d[5];
....

I guess I could keep trace of a range somewhere, but this would start
to get complicated.

If I can tidy up things to not butcher type_size() could you live
with num_packed_components?


> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev