[Mesa-dev] NIR, SCons, and Gallium

[Rob Clark]

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.

BR,
-R

PS. I guess it would involve adding freedreno to scons build, but you
can build it for x86, and there is a standalone ir3_compiler binary
that consumes tgsi, converts to NIR, and feeds through the
freedreno/ir3 compiler backend.  Not sure if that is at all helpful.

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