Alyssa Rosenzweig
b7447a94c8
This is a rewrite of vtn_bindgen. For now the two tools live in parallel, to give Intel time to migrate off v1. For a refresher, the classic vtn_bindgen reads a SPIR-V and generates a .h containing nir_builder stubs for each exported function. The stub inserts an unimplemented nir_function with the proper signature into the shader, and adds a "call" to that function. The driver is responsible for linking with the library later, which is annoying. vtn_bindgen2 instead generates a .c/.h pair. The header are just prototypes with identical signatures to what we have now. The .c implementations, however, are very different. Instead of generating unimplemented nir_function, the implementations contain the actual code (as serialized NIR, deserialized on-the-fly). There is no linking step, nor a library nir_shader that the driver has to keep around. The programming model here is that this is "just" nir_builder ... just a massively more competent way of using nir_builder. Additionally, the whole SPIR-V -> optimized lowered serialized NIR step is now all common code. There's no longer anything target-specific, and it's disentangled from the nir_precomp infrastructure. That means drivers can use CL with zero integration, except a few meson.build rules. This gives a very gentle on-ramp to CL for drivers. (Note: that applies only for library-style CL. For precompiled kernel-style CL, that still requires significant driver integration. I do have plans there, though. Also, printf/abort support requires a minimal amount of driver code.) Furthermore, this unblocks the use of CL library functions in common code. That makes this an important step towards common code geom/tess or maybe saner raytracing. For drivers already using classic vtn_bindgen, porting to vtn_bindgen2 should just be deleting all your linking/deserializing code. The .cl's are unchanged, as are the function prototypes exposed. Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33099>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://docs.mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://docs.mesa3d.org/meson.html>`_): .. code-block:: sh $ meson setup build $ ninja -C build/ $ sudo ninja -C build/ install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://docs.mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://docs.mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.