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 <robdcl...@gmail.com> wrote: > On Mon, Oct 19, 2015 at 3:51 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Mon, Oct 19, 2015 at 3:47 PM, Rob Clark <robdcl...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
