[Mesa-dev] [PATCH 2/8] nir/copy_prop: Respect the source's number of components

[Eric Anholt]

Jason Ekstrand <jason at jlekstrand.net> writes:

> Because we suddenly have to know how many components each source has,
> this makes the pass a bit more complicated.  Fortunately, copy
> propagation is the only pass that cares about the number of components
> are read by any given source so it's fairly contained.

This commit message makes sense when you've read it following the cover
letter, but not on its own.  Maybe:

"In the near future we are going to require that the num_components in a
src dereference match the num_components of the SSA value being
dereferenced.  To do that, we need copy_prop to not remove our MOVs from
a larger SSA value into an instruction that uses fewer channels."

> Shader-db results on Sky Lake:
>
>    total instructions in shared programs: 13318947 -> 13320265 (0.01%)
>    instructions in affected programs: 260633 -> 261951 (0.51%)
>    helped: 324
>    HURT: 1027
>
> Looking through the hurt programs, about a dozen are hurt by 3
> instructions and the rest are all hurt by 2 instructions.  From a
> spot-check of the shaders, the story is always the same:  They get a
> vec4 from somewhere (frequently an input) and use the first two or three
> components as a texture coordinate.  Because of the vector component
> mismatch, we have a mov or, more likely, a vecN sitting between the
> texture instruction and the input.  This means that the back-end inserts
> a bunch of MOVs and split_virtual_grfs() goes to town.  Because the
> texture coordinate is also used by some other calculation, register
> coalesce can't combine them back together and we end up with an extra 2
> MOV instructions in our shader.

This does sound fixable in the backend, but the impact is also tiny.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170308/53201b24/attachment.sig>