On 12 January 2016 at 03:04, Rob Clark <robdcl...@gmail.com> wrote: > On Mon, Jan 11, 2016 at 9:21 AM, Jose Fonseca <jfons...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
