[Mesa-dev] [PATCH] i965/vs/skl: Use vec4 datatypes for message header

[Kenneth Graunke]

On Wednesday, February 11, 2015 10:35:04 AM Ben Widawsky wrote:
> On Wed, Feb 11, 2015 at 05:08:33AM -0800, Kenneth Graunke wrote:
> > On Tuesday, February 10, 2015 05:22:45 PM Ben Widawsky wrote:
> > > Since we can be in this code with SIMD4x2, the execsize will be 4, and so the
> > > register width must be <= 4. If you use a vec8, the width is 8, and we'll assert
> > > fail.
> > 
> > NAK with this rationale.
> > 
> > brw_fs*.cpp is _only_ for SIMD8 (or SIMD16) mode.
> > 
> > brw_vec4*cpp is for SIMD4x1/SIMD4x2 code.
> > 
> > Code in brw_fs_generator.cpp absolutely cannot run in SIMD4x2 mode.
> > 
> 
> I don't quite understand how the code works, but according to the comments in
> the code (which you reviewed) we take this path on SKL. See
> fs_visitor::lower_uniform_pull_constant_loads and
> fs_generator::generate_uniform_pull_constant_load_gen7
> 
> In either event, the patch fixes the aforementioned assertion - if you have a
> better explanation and/or fix, I would be happy to adjust.

I apologize - I misunderstood.

This shader runs in SIMD8 mode.  But, we're using a SIMD4x2 mode sampler
message (even in SIMD8 mode), because we want to load a vector stored as
xyzw from the buffer into a register, but stored how we store uniforms
(also xyzw).  This has execsize 4, and you hit width/execsize assertions.

4,4,1 is effectively the same as 8,8,1 anyway, so it's the same data.

I would perhaps say:

We're using a SIMD4x2 sampler message, which has execsize 4, and so the
register width must be <= 4.  Use <4,4,1> regioning instead of <8,8,1>
regioning to access the same data but avoid tripping the assert.

Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

Thanks, Ben.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150211/3be168f4/attachment.sig>