We've traditionally stored shader variants in a per-context hash table, based on a key with many per-stage fields. On older hardware supported by i965, there were potentially quite a few variants, as many features had to be emulated in shaders, including things like texture swizzling. However, on the modern hardware targeted by iris, our NOS dependencies are much smaller. We almost always guess the correct state when doing the initial precompile, and so we have maybe 1-3 variants. iris NOS keys are also dramatically smaller (4 to 24 bytes) than i965's. Unlike the classic world, Gallium also provides a single kind of object for API shaders---pipe_shader_state aka iris_uncompiled_shader. We can simply store a list of shader variants there. This makes it possible to access shader variants across contexts, rather than compiling them separately for each context, which better matches how the APIs work. To look up variants, we simply walk the list and memcmp the keys. Since the list is almost always singular (and rarely ever long), and the keys are tiny, this should be quite low overhead. We continue storing internally generated shaders for BLORP and passthrough TCS in the per-context hash table, as they don't have an associated pipe_shader_state / iris_uncompiled_shader object. (There can also be many BLORP shaders, and the blit keys are large, so having a hash table rather than a list makes sense there.) Because iris_uncompiled_shaders are shared across multiple contexts, we do require locking when accessing this list. Fortunately, this is a per-shader lock, rather than a global one. Additionally, since we only append variants to the list, and generate the first one at precompile time (while only one context has the uncompiled shader), we can assume that it is safe to access that first entry without locking the list. This means that we only have to lock when we have multiple variants, which is relatively uncommon. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7668> |
||
---|---|---|
.appveyor | ||
.gitlab/issue_templates | ||
.gitlab-ci | ||
bin | ||
build-support | ||
docs | ||
doxygen | ||
include | ||
scons | ||
src | ||
subprojects | ||
.dir-locals.el | ||
.editorconfig | ||
.gitignore | ||
.gitlab-ci.yml | ||
.mailmap | ||
.travis.yml | ||
Android.common.mk | ||
Android.mk | ||
CleanSpec.mk | ||
README.rst | ||
REVIEWERS | ||
SConstruct | ||
VERSION | ||
appveyor.yml | ||
common.py | ||
meson.build | ||
meson_options.txt |
README.rst
`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://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `Freenode's #dri-devel <irc://chat.freenode.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://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.