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

[Marek Olšák]

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.

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

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.

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