On Mon, Jan 11, 2016 at 6:33 PM, Dave Airlie <airl...@gmail.com> wrote: > 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.
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
