On January 4, 2018 14:21:17 Ilia Mirkin <imir...@alum.mit.edu> wrote:
On Thu, Jan 4, 2018 at 3:07 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
On January 4, 2018 14:02:25 Ilia Mirkin <imir...@alum.mit.edu> wrote:
On Thu, Jan 4, 2018 at 2:57 PM, Karol Herbst <kher...@redhat.com> wrote:
On Thu, Jan 4, 2018 at 8:56 PM, Jason Ekstrand <ja...@jlekstrand.net>
wrote:
What is the nature of the immediate problem? We may have a similar
issue.
we don't do rescheduling, so all the immediates are at the top of the
shader.
The implication being that any values that are initialized to an
immediate (which is not infrequent) are done so at the top of the
shader, extending live ranges dramatically.
It's not difficult to move them somewhere closer to first use, just
needs to be done.
I think our back-end compiler's copy propagation and constant communication
passes handle that for us fairly well. The primary place it's likely to
still be an issue for is loop counters and the like.
Well, even without anything fancy, let's say you have
x = uniform + 1
NVIDIA instruction encoding doesn't allow both a uniform and an
immediate at the same time, so one has to stay behind in a register.
If the move to the register happens at the top of the program, then
its live range is substantially extended.
Ok, that makes sense. Intel is a bit less restrictive in that regard.
Also, Matt's constant combining pass is kind of fantastic (though I doubt
it would work on Nvidia).
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
