mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-10 03:50:13 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
007f60c8b8
Currently, nir_lower_printf depends on a per-nir_shader table, writing out indices into the printf buffer. This works for real OpenCL implementations (rusticl, microsoft) which can associate the printf buffer with a particular kernel, I guess. (Actually it's not clear to me that it works well there either but that's not my problem.) This mechanism is unsuitable for internal driver shaders, where printfs with unique format strings can come from many different nir_shaders. There are two current solutions in tree to this for driver CL: * Honeykrisp: Only use one single nir_shader (libagx). This prevents us from using printf in common CL and requires extra driver tracking. It won't work with my upcoming vtn_bindgen rework, which is why I'm addressing this now. * Anv: Offset format-string indices by a dynamic "base identifier" using relocs or a push constant, then pool format strings into a table from nir_shader's across the device. The problem here is that these indices now depend on the order that nir_shaders are seen (which causes a mess for caching if relocs are used, or requires extra push constants and extra bookkeping if relocs aren't used). And the driver tracking required to do this pooling correctly is even more complicated than what Honeykrisp does. I do not want every driver in-tree needing to go down this path, and it wouldn't work with my upcoming vtn_bindgen. This MR introduces an alternate approach: rather than writing indices into the table, we instead hash the format string itself and write the hash. That doesn't depend on what nir_shader we came from, so we can freely mix & match and get consistent hashes. That greatly alleviates driver tracking burden. To make that possible, we need a global hash table mapping hashed format identifiers to the format strings themselves. That approach still requires a step to "register" format strings into the table. That step would not be required if we wrote the actual strings themselves into the table, but that was ruled out for performance/code size reasons. However, we do not want drivers to need to explicitly register all the strings they use, because once we have OpenCL in common code via vtn_bindgen2, drivers won't know all the strings they use. Fortunately, there's a neat solution for that too. By making this global table a singleton (with internal locking), vtn_bindgen2 can automatically register format strings via a static constructor. In conjunction with the infrastructure added here, that eliminates all driver bookkeeping required for format-strings. The code itself is inspired by the glsl type singleton. Is it pretty? Not really, but it gets the job done well. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Jesse Natalie <jenatali@microsoft.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33067> |
||
|---|---|---|
| .ci-farms | ||
| .ci-farms-disabled | ||
| .github/workflows | ||
| .gitlab | ||
| .gitlab-ci | ||
| .marge/hooks | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| licenses | ||
| src | ||
| subprojects | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .clang-format-include | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .graphqlrc.yml | ||
| .mailmap | ||
| .mr-label-maker.yml | ||
| .shellcheckrc | ||
| CODEOWNERS | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| rustfmt.toml | ||
| VERSION | ||
`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.