[Mesa-dev] NIR, SCons, and Gallium

[Rob Clark]

On Mon, Jan 11, 2016 at 7:40 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Mon, Jan 11, 2016 at 7:11 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 01/11/2016 06:21 AM, Jose Fonseca wrote:
>>> FWIW, I updated SCons to build NIR, both with GCC and MSVC:
>>>
>>>   http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=scons-nir
>>>
>>> It was actually simpler than I anticipated.
>>>
>>> But I hit a wall -- there's actually no way to get NIR used with
>>> softpipe/llvmpipe, not even as an intermediate IR somewhere between GLSL
>>> IR and TGSI, is there?
>>>
>>> Without this I can't actually test it.  And I'm afraid the scons
>>> integration will rot again unless it is used.
>>>
>>>
>>> I know other gallium drivers already use NIR, but IIUC, they use NIR
>>> internally, ie., TGSI -> NIR-> HW.
>>>
>>>
>>> So what is exactly the long term plan for NIR in Mesa general, and
>>> Gallium in particular?
>>> - replace GLSL IR completely?
>>
>> Not likely.  GLSL IR has a lot of GLSL-specific semantics that aren't
>> really appropriate for an IR at NIR's level.
>>
>>> - use NIR as intermediate IR betweem GLSL IR and TGSI, and run
>>> optimizations in there?
>>> - use NIR instead of TGSI at the gallium interface?
>>
>> I think folks have expressed a (slight?) preference for the latter
>> rather than the former.  However, the former may provide an easier
>> stepping stone.
>>
>> I know that Ilia has expressed some concerns about how NIR will effect
>> nouveau.  I don't recall hearing an opinion expressed by Marek or any of
>> the other AMD guys, but that probably just means that I wasn't paying
>> enough attention.
>
> To add a bit more precision -- my main concern is performance --
> throwing an extra FOO IR <-> BAR IR stage seems, intuitively, like
> it'll make things slower. Perhaps that could be mitigated by directly
> accepting some other IR in nouveau, but... seems like effort would be
> better spent towards accepting something like SPIR or SPIR-V than some
> other intermediate IR. I just don't see any benefit to NIR for a
> backend that already has an optimizing compiler.

I suppose a foo -> bar pass should really be O(n).. so not that big a
deal in the grand scheme of things as far as compilers go.  But since
nouveau has a fairly complete optimizing backend, NIR in and of itself
might not bring much advantage.  On the other hand if it came with the
option of cutting out time spent in glsl/tgsi passes, that might
change things..

> Having had some experience already dealing with NIR as a total newbie
> (through some freedreno work since Rob adopted NIR as the only input
> IR), I'm less-than-encouraged... at this point I very much prefer to
> deal with TGSI or (gasp!) GLSL IR. Both of those are relatively easy
> to deal with, even if imperfect. (Not to mention the fact that TGSI
> can be used as a transport IR, which AFAIK NIR cannot.) An argument
> could be made that it's because I have more experience with them, and
> it's probably true for GLSL IR, which I distinctly remember being
> confused by. But it was all followable code. And TGSI was intuitive
> from day one.

I would tend to say the *only* advantage that TGSI has is better docs ;-)

TGSI tends to enforce some real horrible things w/ (for example) array
packing..  like if you want to have an array of float or vec2..  and
it is kind of cumbersome to manipulate.  (Ie. comparing the previous
tgsi_lower vs all the same stuff done in nir now...  and also the
bitmap/drawpix/ytransform/emulate lowering that I ported to nir for
gallium glsl_to_nir branch.)

We really do need to get Connor's nir docs merged and start updating
them as we go.  That is something where NIR lags behind TGSI.  As far
as ease of dealing with, I'd tend to vote for NIR.  As far as
performance, it comes down to what other parts of the compile process
are being replaced.

BR,
-R


>
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev