Some hardware have native 10-bit and 12-bit formats. In order to be able to support these, we need
to translate these VK_FORMATs to new padded pipe formats instead of regular 16-bit formats.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30821>
Skip padding channels and only consider valid color channels.
Add and use a common helper for this.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30821>
Add new vk_format_get_plane_width/height helpers using ycbcr_info and use it to
replace RADV's ones which relied on util_format_get_plane_width/height.
We already have this data in the YCbCr table, so this avoids having the maintain the list
of pipe formats in util_format_get_plane_width/height.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30899>
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and VK_FORMAT_G8_B8R8_2PLANE_420_UNORM were being
translated to IYUV and NV12 formats which, in PIPE_FORMAT parlance, are auto-converted
formats, not raw data formats.
Use the raw data formats like everything else.
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30459>
Instead of having a hardcoded list of endian-independent format aliases
in the header, generate them from the format definitions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29649>
With the weak symbols changes and -Dvulkan-beta this fails to link.
Co-authored-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Fixes: 2953c93cca ("vulkan Add enqueue entrypoint for CmdDispatchGraphAMDX")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30057>
The symbols were not getting hidden visibility because
-fvisibility=hidden only applies to definitions, not declarations.
Declare them as hidden explicitly in the header so they don't end up in
.dynsym of linked shared objects.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29986>
The way ATTR_WEAK works is changed to eliminate the "don't declare as
weak on MinGW" weirdness. When a weak is not undefined, MinGW requires
the definition to be a regular symbol. Instead of declaring as weak
everywhere, we now declare the symbol as a regular by default, and only
make it weak when it needs to fallback to NULL when undefined, which is
only needed for the dispatch table. This unifies the approach for Unix
and MinGW.
The name ATTR_WEAK is changed to VK_ENTRY_WEAK since it's now controlled
by the entrypoint specific VK_ENTRY_USE_WEAK flag.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29986>
I'm not sure why Clang didn't warn for this case, but since we are
declaring in both .h and .c we should match both.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29986>
This is inspired from below MR but done in the fixed way:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26767
The requirements used to look up struct extensions are missing the alias
check for those promoted ones. This change fixes it so that the
condition now is correct.
We can land this now as all drivers have migrated to use the common
properties, which has now also been mandated.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29846>
implementation from lavapipe. there's no CTS coverage for this but hopefully
it works...
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28682>
We need some manual logic to work out the size of pData, so we handroll this
one. This fixes push DUT with emulated secondaries.
Affects dEQP-VK.binding_model.shader_access.secondary_cmd_buf.*push*templ* if
emulated secondaries are used.
Neither panvk nor dozen support push DUT yet, so this isn't hurting anyone and
doesn't need to be cc'd stable. But hopefully panvk & dozen get on that :}
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28682>
The last client, venus, has stopped using those either.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29180>
This takes in a (VkBaseInStructure *), checks for its type, casts it
into the right property struct and then copies its fields over the right
way to `struct vk_properties`.
v2: a few fixups (zzyiwei)
- add missing brackets required by clang
- fix some indents
- optimize to aovid deep-copying VkPhysicalDeviceProperties
- update to use DETECT_OS_ANDROID as suggested
- cast to avoid -Wswitch for Android struct beyond VkStructureType
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29180>
Fixes: 1afbf0ba4a ("vulkan/properties: support Android in the property generator")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Tested-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29180>
The Vulkan XML tells us exactly which caps are implied by which API versions,
features, extensions, and properties. We just need to parse that and
autogenerate some glue code, that way drivers don't need to track this manually.
This reduces the boilerplate needed when bringing up new features.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28905>
get_property_structs() now checks if a property struct is
in ANDROID_PROPERTIES and marks it as such.
The header file now includes vk_android_native_buffer.h and the
Android properties in vk_properties..
For the C file, also generate case statements for respective Android
property structs.
All of the Android-specific code is #ifdeffed behind ANDROID.
That being said, we only support PresentationPropertiesANDROID for now.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Tested-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26386>
STACK_ARRAY() is used in a lot of places. When games are running we
see STACK_ARRAY() arrays being used all the time: each queue
submission uses 6, WaitSemaphores and syncobj waiting also uses them:
they're constantly present in Vulkan runtime.
There's no need for STACK_ARRAY()'s stack array to be initialized,
callers cannot not depend on it. If the number of elements is greater
than STACK_ARRAY_SIZE, then STACK_ARRAY() will just malloc() the array
and return it not initialized: anybody depending of
zero-initialization is going to break when the array is big.
The reason why we're zero-intializing STACK_ARRAY()'s stack array is
to silence -Wmaybe-uninitialized warnings: see commit d7957df318
("vulkan: fix uninitialized variables"). I don't think that commit is
the ideal way to deal with the problem, so this patch proposes a
better solution.
The problem here is that zero-initializing it adds code we don't need
for every single caller. STACK_ARRAY() already has 63 callers and only
3 of them are affected by the -Wmaybe-uninitialized warining. So here
we undo what commit d7957df318 did and instead we fix the 3 cases
that actually generate the -Wmaybe-uninitialized warnings.
Gcc is only emitting those warinings because it knows that the number
of elements in the array may be zero, so the loops we have that set
elements to the array may end up do nothing, and then we pass the
array uninitialized to other functions.
For the cases related to vk_sync this is just returning VK_SUCCESS
earlier, instead of relying on the check that eventually happens at
__vk_sync_wait_many(). For the vkCmdWaitEvents() function, the Vulkan
spec says that "eventCount must be greater than 0", so the early
return doesn't hurt anybody either. In both cases we make the zero
case faster by not defining an 8-sized array, zero-initializing it,
then returning success without using it.
Reference: d7957df318 ("vulkan: fix uninitialized variables")
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28288>
The vk_format_description moved to front because it's referenced by vk_format_is_alpha_on_msb
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Matt Coster <matt.coster@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28266>
The generated "astc_spv.h" is for runtime internal use, so leave it
inside the runtime files to ensure the header is generated before being
used to compile.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28066>
this is a bandaid fix that allows users (zink) to actually call the
functions intended to be called. the real fix would be to figure out
which extensions are enabled on the device and then only GPA the
functions associated with those extensions
that's too hard though so I'm slapping some flex tape on it
cc: mesa-stable
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27834>
We don't need to start iterating from `pProperties`, as the first member
is already handled in vk_common_GetPhysicalDeviceProperties2. Eliminate
this iteration by starting from pProperties->pNext.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27671>
This works better if vk_dispatch_table.h is inside some "genDir",
and not generated "src/vulkan/util" directory. This is the
case for the AOSP Soong build system.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26874>
