[Mesa-dev] [PATCH v2 00/31] Nir support for Nouveau
Jason Ekstrand
jason at jlekstrand.net
Thu Jan 4 20:45:24 UTC 2018
On January 4, 2018 14:21:17 Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Thu, Jan 4, 2018 at 3:07 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On January 4, 2018 14:02:25 Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>
>>> On Thu, Jan 4, 2018 at 2:57 PM, Karol Herbst <kherbst at redhat.com> wrote:
>>>>
>>>> On Thu, Jan 4, 2018 at 8:56 PM, Jason Ekstrand <jason at 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).
More information about the mesa-dev
mailing list