[Mesa-dev] NIR, SCons, and Gallium

[Dave Airlie]

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.

Dave.