On Thu, Jan 4, 2018 at 3:07 PM, Jason Ekstrand <[email protected]> wrote: > On January 4, 2018 14:02:25 Ilia Mirkin <[email protected]> wrote: > >> On Thu, Jan 4, 2018 at 2:57 PM, Karol Herbst <[email protected]> wrote: >>> >>> On Thu, Jan 4, 2018 at 8:56 PM, Jason Ekstrand <[email protected]> >>> 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. -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
