[Mesa-dev] [RFCv0 0/8] gallium: add support for NIR as alternate IR

[Rob Clark]

On Mon, Oct 19, 2015 at 8:53 PM, Marek Olšák <maraeo at gmail.com> wrote:
> Yes, drivers need to "dup" tokens if they want to keep them. Their
> lifetime is the create function and that's it. st/mesa only keeps the
> tokens for vertex shaders, because it needs for emulating some
> features with the Draw module.

It is something that I think would be worth revisiting, since the
common case is that drivers have to dup the tokens to do their own
variant mgmt.. so that seems like the better case to optimize for.  I
think the only one that isn't doing it's own variant mgmt is nouveau,
but Ilia mentioned at some point that there where some edge cases
where they really do need a variant.

it would be a lot of churn to change this for the tgsi case, but I
still think worthwhile.  Either way, I think we should at least
consider this while introducing the possibility for other IR's (since
cloning llvm or nir, for example, would be more expensive than cloning
tgsi)

> I think there are 2 groups of people:
> - one would be okay with nuking GLSL-to-TGSI and replacing it with
> NIR-to-TGSI if it improved compile times *and* the GLSL linker was
> moved to NIR as well
> - the other wants NIR everywhere

This is more ambitious than what I had in mind, at least to start
with.. probably worthwhile, but I am a bit skeptical about going
directly from glsl->tgsi to glsl->nir->tgsi for everyone all at once.

Basically my thinking is that most of the non glsl paths are
relatively simple shaders, so less advantage to skipping the tgsi
step.  Hence the idea of keeping tgsi for internally generated shaders
and prog->tgsi path.  This leaves a NIR version of tgsi_emulate to be
implemented, but that should be straightforward and something that can
be reused later if we do NIR everywhere.  So it seems generally like a
step in the right direction.

Using NIR everywhere does clean up some things as far as not having
two different paths in st_glsl_to_tgsi and st_program, but so far
those parts haven't seemed too intrusive.  And I guess it is useful to
start proving out the glsl_to_nir path for drivers like freedreno and
vc4 which don't yet care about doubles/tess/etc.

> NIR-to-TGSI would be possible and I think st/mesa needs one more
> cleanup for that: We need to move the final step of the translation to
> TGSI into LinkShader. There is also the WPOS emulation that can be
> moved to tgsi_emulate. This will also slightly clean up Mesa-to-TGSI,
> because it's intertwined with GLSL-to-TGSI a little. After that, you
> can replace GLSL-to-TGSI with NIR-to-TGSI merely by changing the
> LinkShader function pointer and it would support all features as it
> does now.

I'm open to suggestions for things to clean up (either as part of this
patchset or unrelated)..  but I do think an intermediate step of
having tgsi still be the common/fallback thing, but just having the
possibility to skip it in certain paths (like glsl_to_nir) is smaller
step that can be done in the near term.

My first goal is just to find and fix things that are incompatible
between glsl_to_nir vs tgsi_to_nir, so we can at least have some
confidence that the output of either is equivalent.  That seems useful
for a later step of supporting other paths to NIR (such as
spirv_to_nir).

BR,
-R

> Now, if you want NIR everywhere, it gets more complicated.
>
> These hardware-accelerated features require TGSI:
> - glBitmap
> - glDrawPixels
>
> These features emulated by the draw module require TGSI:
> - glRasterPos
> - GL_FEEDBACK mode
> - GL_SELECT mode
>
> If you ignore the features emulated by Draw, you don't need to
> generate TGSI for GLSL shaders if you do this:
>
> 1) For glBitmap, you need to write a NIR lowering pass that implements
> this transformation:
> http://cgit.freedesktop.org/mesa/mesa/diff/src/mesa/state_tracker/st_cb_bitmap_shader.c?id=f4ec81032bb9c1460794d3d843d0ffe47a181291
>
> 3) For glDrawPixels, you need to re-implement this pass:
> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_cb_drawpixels_shader.c?id=de6a004035f3de5879648f8afb4670ae82f4ad02
>
> It shouldn't take long. They are pretty simple. I would be more
> worried about Draw, but if your driver isn't supposed to be
> feature-complete with the compatibility profile, you may as well
> ignore it.
>
> Marek
>
> On Mon, Oct 19, 2015 at 9:58 PM, Rob Clark <robdclark at gmail.com> wrote:
>> On Mon, Oct 19, 2015 at 3:51 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Mon, Oct 19, 2015 at 3:47 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>> Also, there is some trivial shader variant handling in mesa st which
>>>> would have to be ported to NIR.  Or, perhaps, just somehow expose the
>>>> shader key to the driver.  (Currently most drivers are doing much more
>>>> variant handling within the driver, and having two levels of variants
>>>> does seem a bit silly.)
>>>
>>> With Marek's latest series, the are no more variants in st/mesa (well,
>>> except for glDrawPixels/glBitmap-related shaders) provided that your
>>> driver exposes the right caps.
>>
>> Ok, I guess I should rebase onto that.. I think the
>> glDrawPixels/glBitmap paths will still be TGSI.. so only having to
>> deal with variants in the GLSL->whatever path in drivers would be
>> nice..
>>
>> (note: I should probably point out some TODO comments I had in the
>> freedreno/ir3 parts about cso->{tokens/nir/etc} lifetime.. the current
>> state of having to dup/clone in driver since sometimes cso->tokens
>> don't exist after the pipe->create_xyz_state() is a bit ugly..)
>>
>> BR,
>> -R
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev