Jason Ekstrand <ja...@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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
