[Mesa-dev] NIR, SCons, and Gallium

[Rob Clark]

On Mon, Jan 11, 2016 at 6:33 PM, Dave Airlie <airlied at gmail.com> wrote:
> On 12 January 2016 at 03:04, Rob Clark <robdclark at gmail.com> wrote:
>> On Mon, Jan 11, 2016 at 9:21 AM, Jose Fonseca <jfonseca at vmware.com> 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?
>>> - use NIR as intermediate IR betweem GLSL IR and TGSI, and run optimizations
>>> in there?
>>> - use NIR instead of TGSI at the gallium interface?
>>> - be only used internally by drivers?
>>> - something else?
>>
>> Just fwiw, I've already started some work for gallium support for NIR,
>> and mesa/st support for glsl_to_nir.  Although what I've started on so
>> far might not really help you (yet).  I haven't reposted that patchset
>> for a while, but at this point mostly it is blocking on me fixing
>> things in freedreno/ir3 compiler backend.  (Last status was ~230
>> piglit regressions, mostly variable-indexing, due to things I need to
>> fix in ir3, compared to glsl->tgsi->nir.)
>>
>> Basically my idea was:
>>
>> 1) gallium support to pass one of several different IR's to driver for
>> compute or gfx shaders..  The idea is that drivers would always have
>> to support TGSI but could ask for NIR (or presumably llvm/spirv/etc)
>> as an alternative.
>>
>> 2) in mesa-st, if driver asks for NIR, then instead of glsl_to_tgsi,
>> it would do glsl_to_nir and then run the various lowering that mesa st
>> does (bitmap/drawpix/ypos-transform/edgeflags/etc) in NIR.  Currently
>> ARB shader programs and some internally generated blit shaders will
>> still come to the driver as TGSI, but stuff that starts out as glsl
>> will skip the TGSI step.
>>
>> So with that you'd still need a device that could run vc4/freedreno
>> (or maybe someday ilo) to exercise the NIR paths.
>>
>> I think, long term, it would be nice to resurrect the nir_to_tgsi pass
>> that Eric started.  That would be a path to replacing some of the
>> opt/lowering done in glsl or tgsi with nir, and then converting out
>> into tgsi for the non-nir-consuming drivers.  That was a bit more than
>> I was planning on tackling right now, although I think at least what
>> I'm doing is a step in that direction.
>
> It would be I suppose nice to have an in-tree nir->tgsi convertor.
>
> Then we can at least test softpipe with a glsl->nir->tgsi pipeline
> alongside the glsl->tgsi pipeline.

I don't remember how complete nir->tgsi was.  I remember that
tgsi->nir gained a lot of (mostly gl(es)3) features since then.. But I
suppose if it were an non-default path, we could at least get started
w/ a 90% complete nir->tgsi..

BR,
-R