Some people seem to have systems with more than 8 GPUs installed at
once. 256 is the maximum number of devices returned by libdrm, so using
this seems like a good choice for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27901>
In the fast-link case, we should just use the library shader and assume
that it's correct. We have to do this because we may not have a
precompiled shader in this case so we can't even generate the shader
hash.
In the link optimization case, we could still have a library shader
coming in from some library pipeline. That shader may happen to be
correct, in which case we can just use it and not even bother digging
around in the cache. In the more likely case, the keys won't match and
we should throw it away before we look up a different shader in the
cache and leak our reference.
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementation")
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27860>
These implementations are built on top of vk_shader. For the most part,
the driver shouldn't notice a difference between draws consuming
pipelines vs. draws consuming shaders. The only real difference is
that, when vk_driver_shader_ops::compile() is called for pipelines, a
struct vk_graphics_pipeline_state is provided. For shader objects, the
state object will be NULL indicating that all state is unknown. Besides
that, all the rest of the differences between Vulkan 1.0 pipelines,
VK_EXT_graphics_pipeline_library, and VK_EXT_shader_object are handled
by the Vulkan runtime code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
This adds a new base vk_shader object along with vtables for creating,
binding, and working with shader objects.
Unlike other parts of the runtime, the new shader object code is a bit
more sanitized and opinionated than just handing you the Vulkan
entrypoints. For one thing, the create_shaders() calback takes a NIR
shader, not SPIR-V. Conversion of SPIR-V into NIR, handling of magic
meta NIR shaders, etc. is all done in common code. [De]serialization is
done via `struct blob` and the common code does a checksum of the binary
and handles rejecting invalid binaries based on shaderBinaryUUID and
shaderBinaryVersion. This should make life a bit easier for driver
authors as well as provides a bit nicer interface for building the
common pipeline implementation on top of shader objects.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
DRM modifiers are a BSD/Linux phenomenon.
We can also remove a bunch of these checks too. No Linux specific
symbol or header is **actually** used, and the DRM modifier is
just represented as uint64_t. But kept the style of the file
as is.
Reviewed-by: Serdar Kocdemir <kocdemir@google.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27425>
The runtime is turning GENERAL layouts into FEEDBACK_LOOP ones when it
detects feedback loops in a render pass. This is breaking drivers that
would like to use a different HW layout for those 2 layouts because if
the application inserts barrier in the render pass, the barriers the
driver sees are inconsistent.
This could lead to barrier of this type :
- GENERAL -> FEEDBACK_LOOP (runtime)
- GENERAL -> GENERAL (app)
- FEEDBACK_LOOP -> GENERAL (runtime)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23523>
In the case both sample locations and rasterization samples is supported by a
driver as dynamic state, there is a case vk_multisample_sample_locations_state_init()
does not fill ms->sample_locations at all. In this case we need to check
this pointer when dereferencing it in vk_dynamic_graphics_state_init_ms().
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27025>
I noticed that my NVK build was always LTOing the library twice
(I managed to trace it to the vk_synchronization_helpers change)
This change fixes the double compilation/LTO issue (which should
definitely cut packaging times a bit) 🐸
Fixes: fe12c1c29e ("vulkan: Add some auto-generated synchronization helpers")
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26630>
This is for fixes the following error:
FAILED: src/vulkan/runtime/vk_synchronization_helpers.c src/vulkan/runtime/vk_synchronization_helpers.h
"C:\CI-Tools\msys64\mingw64\bin/python3.EXE" "../../src/vulkan/util/vk_synchronization_helpers_gen.py" "--xml" "../../src/vulkan/registry/vk.xml" "--out-c" "src/vulkan/runtime/vk_synchronization_helpers.c" "--beta" "false"
Traceback (most recent call last):
File "C:/work/xemu/mesa/src/vulkan/util/vk_synchronization_helpers_gen.py", line 213, in main
f.write(TEMPLATE_C.render(**environment))
UnicodeEncodeError: 'gbk' codec can't encode character '\xa9' in position 15: illegal multibyte sequence
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26515>
Friedrich Vock