this gives us new rasterizer states when multisample stuff changes instead
of new fs states, which is what we want since these correlate to pipeline
flags, not shader-specific things
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8631>
* struct shader_info provides a 32bit mask for textures_used
* samplers and samplerviews are a 1:1 mapping for shader descriptors
* also according to spec this is always 32 per stage
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8457>
some vulkan drivers (e.g., amdvlk) advertise absolutely huge values here,
resulting in bitmask overflows everywhere since gallium assumes a max of
32 for vertex inputs and nir uses 64bit types for others
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8318>
this makes tessellation work as expected in apps but has no impact on unit tests
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
Tested-by: Witold Baryluk <witold.baryluk@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8274>
This moves the parts of zink_format.c that also operates on zink_screen
into zink_screen.c. This has the benefit that we can start testing the
enum-translation code separately from the state.
This will make the next commit a bit cleaner.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7982>
There's no harm in checking for the extension on non-macOS, just do it.
Nor can I see any point in checking for both the layer and the
extension, since you're never going to see the extension if the layer
isn't available, so just check for the extension instead of the reduced
boolean. Simplify some variable naming while we're at it.
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8019>
This result isn't actually used within zink_create_instance, so don't do
it there.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8019>
Magic parameters are gross, this makes zink_internal_create_screen a bit
more reusable.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8019>
It's hooked up in all the pipe wrapper drivers, and all the
frontends except a couple places in glx/xlib.
This enables a more efficient path for drivers which use
swrast's Present, but hardware rendering (e.g. d3d12, zink).
Reviewed-by: Dave Airlie <airlied@redhat.com>
Acked-by: Marek Olák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8045>
PIPE_MAX_CONSTANT_BUFFERS is 32, however many Vulkan implementations
has maxPerStageDescriptorUniformBuffers that exceeds it, for example:
radv 8388606,
anv 64
nvidia 1048580 for RTX 2000 and up.
and, together with the current zink logic, the returned value
will exceed the maximum allowed value for the cap.
This causes cso_destroy_context to pass big values back to zink
(via zink_set_constant_buffer), resulting in access beyond end of
allocated buffer for all UBOs.
Cap the cap to PIPE_MAX_CONSTANT_BUFFERS (32), not INT_MAX.
Add an assert to verify future drivers.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7976>
MoltenVK does not export the vkGetPhysical*2() functionns, even in Vulkan 1.2.154.0 where the instance version moves from 1.0 to 1.1.
If the extension is present and used the KHR versions of the functions can be used.
From the spec the vkGetPhysicalDevice*2() functions should be avaiable from Vk 1.1 loaders and devices. Which implies MoltenVK might be misbehaving.
This change allows the extension to be used, if present, before the Vk 1.1 version check.
Fixes: 752f6d80 ("zink: setup version dependent VkPhysicalDeviceVulkan*Features and VkPhysicalDeviceVulkan*Properties.")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7960>
Moved the call to vkEnumerateInstanceVersion() into the create_instance() function,
so the result can be passed into the application apiVersion.
Will stop drivers from limiting a devices supported api version.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7533>
Some drivers will drop warnings about seeing these structs in the
pNext chain and not handling them. This change makes it so we
only include the structs with Vulkan drivers that are known to
require them for proper behavior (v3dv only for now) to avoid the
warnings.
It should be noted that here we are only supressing the messages
from Zink. Since the Mesa Vulkan WSI code will include these structs,
when native Vulkan Mesa drivers are used without Zink they might
still dump these messages.
Requested by Mike Blumenkrantz.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7523>
vkGetPhysicalDeviceFeatures2 and vkGetPhysicalDeviceProperties2 are not present on some MoltenVK versions.
VK_KHR_get_physical_device_properties2 exposes the KHR versions of the same functions.
These cannot be used via static linking, so we have to dynamically detect the loader version and then the extension
to work out which pointers to use.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7447>