It's not invalid to have this value in the list, but the only case it
is actually valid as format in the creation of an image or image view
is with Android Hardware Buffers which have their format specified
externally.
So we can just ignore all entries with VK_FORMAT_UNDEFINED.
Cc: 22.2 <mesa-stable>
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17182>
It is observed that in display resolutions where width is not equal to
stride, vulkan rendering is being distorted. This is happening due to
stride calculation mismatch between minigbm and mesa.
This fix makes sure that the stride calculated in minigbm is passed to
anv and isl.
The issue was found while debugging the following android cts tests and
thus fixes them as well.
android.graphics.cts.VulkanPreTransformTest#testVulkanPreTransformNotSetToMatchCurrentTransform
android.graphics.cts.VulkanPreTransformTest#testVulkanPreTransformSetToMatchCurrentTransform
Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22163>
This will be useful for RADV since it hashes the state.
v3dv changes:
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20731>
There was a VUID-VkImageViewCreateInfo-image-04739 in the Vulkan 1.3
spec that said:
If image was created with the
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT flag and format is a
non-compressed format, viewType must not be VK_IMAGE_VIEW_TYPE_3D
That VUID has since been removed, and when a view of a 3D image is
created, with put the depth into the array_len, so it won't be always 1.
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20803>
We still maintain our own table of formats but all of the conversion and
sampling info we pull from common code.
Acked-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
image_aspect_to_binding() converts aspect to index by subrracting
VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT, however these enum values
are bitfields, not consecutive numbers, so comparing and subtracting
them won't work.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20269>
In 4ceaed7839 we made scratch surface state allocations part of the
internal heap (mapped to STATE_BASE_ADDRESS::SurfaceStateBaseAddress)
so that it doesn't uses slots in the application's expected 1M
descriptors (especially with vkd3d-proton).
But all our compiler code relies on BSS
(STATE_BASE_ADDRESS::BindlessSurfaceStateBaseAddress).
The additional issue is that there is only 26bits of surface offset
available in CS instruction (CFE_STATE, 3DSTATE_VS, etc...) for
scratch surfaces. So we need the drivers to put the scratch surfaces
in the first chunk of STATE_BASE_ADDRESS::SurfaceStateBaseAddress
(hence all the driver changes).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ceaed7839 ("anv: split internal surface states from descriptors")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7687
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19727>
On Intel HW we use the same mechanism for internal operations surfaces
as well as application surfaces (VkDescriptor).
This change splits the surface pool in 2, one part dedicated to
internal allocations, the other to application VkDescriptors.
To do so, the STATE_BASE_ADDRESS::SurfaceStateBaseAddress points to a
4Gb area, with the following layout :
- 1Gb of binding table pool
- 2Gb of internal surface states
- 1Gb of bindless surface states
That way any entry from the binding table can refer to both internal &
bindless surface states but none of the driver allocations interfere
with the allocation of the application.
Based off a change from Sviatoslav Peleshko.
v2: Allocate image view null surface state from bindless heap (Sviatoslav)
Removed debug stuff (Sviatoslav)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7110
Cc: mesa-stable
Tested-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19275>
These are only used for storage-compatible compressed surfaces on
Broadwell and earlier and Stencil on Gfx7 where there isn't proper
stencil sampling support.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18402>
With VK_FORMAT_B10G11R11_UFLOAT_PACK32 in particular, we're seeing
applications create image views with swizzle = R,G,B,0
But since the format has no alpha channel, the swizzle value for it
does not matter for the equivalence we're trying to verify.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: a9edc268b9 ("anv: validate image view lowered storage formats for storage")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18081>
Each logical device can point to its physical device intel_device_info
saving at least one intel_device_info.
This also allow us to set 'const' to avoid values in intel_device_info
being changed by mistake.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17897>
Ensure that if we have swizzle on the initial format, that the
component bits are identical with the lowered format.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17385>
For some formats like VK_FORMAT_B5G6R5_UNORM_PACK16, we have no direct
matching HW format. We can support it by swizzling.
We already apply those swizzles for image views. We just forgot to
deal with buffer views.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6235
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17385>
Because clear colors are stored as 4 32bit component values, there is
an issue if you try to format instance :
- clearing in R16G16_UNORM
- draw in R32_UINT
Clear will use 2 components of the clear color in dword0 & dword1.
While draw will use only one component of dword0.
This change uses the mutable format information to track whether clear
colors can be non-zero for fast clears.
With :
- non mutable formats, we can fast clear with any color on Gfx > 8
- mutable formats with incompatible component sizes, we can only
fast clear with 0 color
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5930
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17329>
Also move it to the end of the switch as is more conventional. For some
reason, later patches in the series make ANV fail to build because GCC
stops detecting the assert(!"str") as not returning.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17214>
It looks like atomics are slow on compressed surfaces so when enabling
compression for storage images that can be possibly used for atomic
operation hinders performance. Lets just disable compression in this
scenario.
v2: Reword comment (Ken)
Allow mutable with 16/32/64 bits (Ken)
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14712>
We already had a little workaround for v3dv where, for some if its meta
ops, it had to bind a depth/stenicil image as color. Instead of
special-casing binding depth/stencil as color, let's flip on the
drier_internal flag and get rid of most of the checks in that case.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16376>
This fixes a number of tests like :
dEQP-VK.renderpass*.suballocation.multisample.s8_uint.*
dEQP-VK.renderpass*.suballocation.multisample.separate_stencil_usage.d24_unorm_s8_uint.*.test_stencil
dEQP-VK.renderpass*.suballocation.multisample.d24_unorm_s8_uint.*
dEQP-VK.renderpass*.suballocation.multisample.d32_sfloat_s8_uint.*
Because the driver asserts when generating RENDER_SURFACE_STATE with a
8 Valign value for stencil buffer (only 2 & 4 are supported).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12670>
It was originally introduced in ca791f5c but it was never actually set
anywhere. It doesn't serve any purpose other than some sanity checking
so let's clean it up for now.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15799>
When CCS compression first came out on Skylake, we referred to it as
"renderbuffer compression", or RBC for short. However, that name has
long since fallen out of favor, and we refer to it as CCS nearly
everywhere.
This patch renames DEBUG_NO_RBC to DEBUG_NO_CCS inside the codebase
for clarity, and adds INTEL_DEBUG=noccs. The legacy INTEL_DEBUG=norbc
name continues to work, because it's one line of code and having both
names makes our lives easier in the interim.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15447>
This reverts commit d68b2db89c.
With this change, no regressions have been observed with the
dEQP-VK.synchronization* test group. There are regressions with
dEQP-VK.drm_format_modifiers.export_import.*, but those have been
root-caused to be test issues (see 3575).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6125
Fixes: 57445adc89 ("anv: Re-enable CCS_E on TGL+")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15420>
For dmabuf imports, configure the primary surface without support for
compression if the modifier doesn't specify it. This helps to create VkImages
with memory requirements that are compatible with the buffers apps provide.
Suggested-by: Philip Langdale <philipl@overt.org>
Cc: 22.0 <mesa-stable>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5940
Tested-by: Philip Langdale <philipl@overt.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15181>
Use a variable to store the anv_image_create_info struct. We'll modify it for a
bug fix in the next patch.
Cc: 22.0 <mesa-stable>
Tested-by: Philip Langdale <philipl@overt.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15181>
