Bug 109517

FYI: None of the few other compute shader tests for which I have data are impacted, but they don't spill either.

bisected to series ending in:

a920979d4f30a48a23f8ff375ce05fa8a947dd96
Author:     Jason Ekstrand <jason@jlekstrand.net>
intel/fs: Use split sends for surface writes on gen9+

Surface reads don't need them because they just have the one address
payload.  With surface writes, on the other hand, we can put the address
and the data in the different halves and avoid building the payload all
together.

The decrease in register pressure and added freedom in register
allocation resulting from this change reduces spilling enough to improve
the performance of one customer benchmark by about 2x.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

There was a very small (<1%) drop also in Sacha Willems' Vulkan Raytracing demo.

Ugh...  I'm not really sure what we should do about this one.  Mark's bisect is exactly correct.  I've looked at the shaders, and there seems to be two issues:

 1) There's one SIMD8 shader which schedules massively differently for no apparent reason.

 2) There's a SIMD16 shader which starts spilling way more than it was before

In both cases, I have no idea why it's happening beyond the fact that our current RA and scheduling has rather random behaviour at times.  Using SENDS should only ever decrease register pressure and increase RA freedom because it no longer has to build the message into a single hunk and can just send the two bits (address and data) separately.

As I said in the commit message I have another (unfortunately not public yet) customer workload where the opposite happens and using SENDS decreases spilling and improves performance by 2x.

Ken, Matt, Any thoughts?

(In reply to Jason Ekstrand from comment #4)
> Ugh...  I'm not really sure what we should do about this one.  Mark's bisect
> is exactly correct.  I've looked at the shaders, and there seems to be two
> issues:
> 
>  1) There's one SIMD8 shader which schedules massively differently for no
> apparent reason.
>
>  2) There's a SIMD16 shader which starts spilling way more than it was before

Based on your comment below I assume that SIMD8 shader also got worse, but does it also spill?  I.e. is the bad behavior limited to spilling shaders?

 
> In both cases, I have no idea why it's happening beyond the fact that our
> current RA and scheduling has rather random behaviour at times.  Using SENDS
> should only ever decrease register pressure and increase RA freedom because
> it no longer has to build the message into a single hunk and can just send
> the two bits (address and data) separately.
> 
> As I said in the commit message I have another (unfortunately not public
> yet) customer workload where the opposite happens and using SENDS decreases
> spilling and improves performance by 2x.

SENDS support is needed performance feature.  If the current implementation improves things more than it regresses, and especially if the improving cases are more important like here, I think letting regression in for the release is fine.

There could be some meta-bug about the RA / scheduler related issues which this (and e.g. bugs about bad sampler fetch scheduling) would link to though.

We had a discussion about this today and determined that we'd leave the bug open but drop it from the 19.0 release tracker.

Perf improved 5-10% (depending on platform) between following commits:
2019-02-28 17:30:48 df5cd51259: gitlab-ci: install xmllint to validate 00-mesa-defaults.conf
2019-03-01 16:46:32 fc82ea1350: Revert "swr/rast: Archrast codegen updates"

I assume improvement comes from the nir/copy_prop_vars series.

(In reply to Eero Tamminen from comment #7)
> I assume improvement comes from the nir/copy_prop_vars series.

Very likely.

*** Bug 110344 has been marked as a duplicate of this bug. ***

*** Bug 110412 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1786.