[Mesa-dev] [PATCH 0/6] RadeonSI: Let's just stop spilling SGPRs
Nicolai Hähnle
nhaehnle at gmail.com
Tue Sep 13 18:16:38 UTC 2016
On 13.09.2016 19:13, Marek Olšák wrote:
> This is quite easy because we just have to get rid of all of
> the preloading at the beginning of shaders.
>
> I also removed preloading of PS inputs with literal indexing, which
> has almost the same effect as sinking interp instructions.
>
> I'm slightly concerned that LICM won't move interps because they are
> not considered speculatively-executable (=movable) by LLVM, but
> the shader-db stats show that it doesn't matter.
>
> LLVM is smart enough to do CSE where needed for both descriptor loads
> and interps. In fact, it's the CSE which is responsible for some of
> the remaining SGPR spills. (It makes sense if you think about it)
>
> The compile time increased by 6% because CSE has a lot more work,
> but it's certainly worth it.
>
>
> shader-db stats:
>
> [PATCH 4/6] radeonsi: get rid of img/buf/sampler descriptor
> https://people.freedesktop.org/~mareko/no_preload1.html
> [PATCH 5/6] radeonsi: get rid of constant buffer preloading
> https://people.freedesktop.org/~mareko/no_preload2.html
> [PATCH 6/6] radeonsi: reload PS inputs with direct indexing at each
> https://people.freedesktop.org/~mareko/no_preload3_ps.html
>
> Total diff:
> https://people.freedesktop.org/~mareko/no_preload_total.html
Those numbers are impressive.
We do have to be slightly careful, I noticed that LLVM didn't lift some
constant loads out of loops with the earlier preload removal, in shaders
where SGPR pressure wasn't an issue at all.
I think the right way to deal with this is to improve heuristics in
LLVM, so I'm fine with changing Mesa in this way.
Some comments sent in reply to the respective patches. Patches 2, 3, and
5 are
Reviewed-by: Nicolai Hähnle <nicolai.haehnle at amd.com>
> Please review.
>
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list