The presentation timing extension is used for doing WaitForPresent
properly, but we accidentally bind it after an early return intended to
stop us from binding dmabuf when software rendering.
Remove the early return.
cc: mesa-stable
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24588>
amdgpu_bo_destroy is called when the bo ref count reaches 0. But if the
bo is on bo_export_table, amdgpu_bo_from_handle can race with
amdgpu_bo_destroy and increments the bo ref count. When that happens,
amdgpu_bo_destroy should bail.
v2:
- reorder amdgpu_bo_free and amdgpu_bo_unmap
- fix an assert
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24526>
The clause local registers can't be used if a new CF is started, but
the assembler still may introduce a CFs to work around some hardware bug,
so make sure RA doesn't assume that the predicate ALU op is in the same ALU
CF like the ALU ops before.
This is a hotfix, the scheduler should handle this better.
Fixes: cfbd1fd413
r600/sfn: Use clause local registers in RA
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24611>
vkQueuePresentKHR might return VK_SUBOPTIMAL_KHR which is not VK_SUCCESS
but presentation succeeded anyway. We should capture a trace even if
VK_SUBOPTIMAL_KHR is returned.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24052>
Now that there's only one user, inline the function.
While we're here, update the stale comment about unknown sampling
formats causing us to implement a simplified workaround. We've had
visibility into the formats that blorp_copy will use for some time now.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24446>
iris_copy_region improperly handles destinations that have
ISL_AUX_USAGE_FCV_CCS_E in use. To avoid corruption when copying to a
resource which has this aux usage, this function needs to:
1. Remove existing fast-clear blocks that would be incompatible with
the surface format that will be used by blorp_copy.
This is actually a general rendering requirement that affects more
aux usages than just FCV_CCS_E.
2. Either avoid generating new fast-clear blocks that would be
incompatible with the original surface format, or remove the newly
generated incompatible fast-clear blocks.
This is particular to FCV_CCS_E, which sometimes generates
fast-clear blocks during a rendering operation. The generation is
dependent on the surface format, the clear color, and the pixels
being written.
iris_copy_region does step 1, only allowing fast-clear blocks that
represent the value of zero. These are compatible with every surface
format. This function does not do step 2 however, leading to rendering
corruption in certain cases.
Fix this by generally relying more on the standard resource preparation
functions, which account for this issue. Specifically, by using
iris_resource_prepare_render, steps 1 and 2 are both handled for us.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3732
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24446>
When a resource goes from being accessed with one aux usage to another,
iris_resource_prepare_access will flush the appropriate caches to
prevent rendering/sampling corruption. So, we must be careful to call
the prepare access function with the aux usage that will match the next
memory access of the resource.
iris_resource_prepare_render fails to do this because it sometimes calls
the prepare access function with the resource's aux usage after calling
that same function with the aux usage that will be used in the next
memory access.
Fix this by reversing the order of the prepare access function calls.
Fixes: 046bba0be0 ("iris: Handle clear color compatibility in prepare_render")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24446>
We already expose the *2() functions and allow the common vulkan code
to provide the vulkan 1.0 equivalents, so we might as well expose this
extension.
Coverage in dEQP is dEQP-VK.api.copy_and_blit.copy_commands2.*, which
are mostly identical to dEQP-VK.api.copy_and_blit.core.* without
additional extensions.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24489>
Common vulkan wsi code already exposes the *2() functions (as well as
the vulkan 1.0 equivalents), so we might as well expose this extension.
Coverage in dEQP is dEQP-VK.wsi.*.surface.query_capabilities2, which
are all currently unsupported as we do not expose any platform surface
extensions.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24489>
We already expose the *2() functions and allow the common vulkan code
to provide the vulkan 1.0 equivalents, so we might as well expose this
extension.
The runtime also provides common implementations for the *2() functions
based on VK_KHR_maintenance4, but those functions require the
requirements to be evaluated without creating a resource; that would
need significantly more refactoring work to achieve.
Coverage in dEQP is dEQP-VK.memory.requirements.extended.*, which all
pass or are unsupported.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24489>
Common vulkan wsi code already exposes the *2() functions (as well as
the vulkan 1.0 equivalents), so we might as well expose this extension.
Coverage in dEQP is dEQP-VK.wsi.display.get_display_*2, which all pass
or are unsupported.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24489>
This makes use of the vk_get_physical_device_core_1_*_property_ext()
helpers.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24489>
Switches PVR_USE_WSI_PLATFORM to be an always defined boolean to allow
for cleaner use in the extension tables (borrowed from tu) and extends
the pattern to create PVR_USE_WSI_PLATFORM_* equivalents for each
supported platform.
Also fixes the ordering to match the struct definitions.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24489>
GCC zeroes out the unreferenced parts of the union when assigning by
the smaller member, but clang doesn't. Neither is wrong, because the C
standard calls this UB; insert padding to ensure any compiler behaves
predictably.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24477>
The NIR backend is good enough and here is already a long list of
reasons why SB should not be called because it doesn't handle certain
instructions correctly.
v2: - remove more references to SB (Vitaly Kuzmin)
- remove unused sb context (Sam Ravnborg)
v3: - drop used variable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7166
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24509>
as in the producer case, big io needs to reserve the appropriate number
of slots
fixes:
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-float-index-rd-after-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-float-index-wr-before-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-vec2-index-rd-after-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-vec2-index-wr-before-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-vec3-index-rd-after-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-vec3-index-wr-before-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-vec4-index-rd-after-barrier,Fail
spec@arb_tessellation_shader@execution@variable-indexing@tcs-output-array-vec4-index-wr-before-barrier,Fail
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24568>
This helper is used to initialize a radv_shader_stage struct for
pipelines, while radv_shader_stage_init() would be for shader object
only (ie. using VkCreateShaderInfoEXT).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24562>
With pipelines, the shader layout is inherited from the pipeline layout
but with shader objects, the layout is passed through
VkCreateShaderInfoEXT.
This basically replaces uses of radv_pipeline_layout by
radv_shader_layout during shaders compilation. This will avoid
creating a pipeline layout with ESO.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24562>
For texture instructions that don't have sampler state we have
been incorrectly using sampler index to retrive texture packing
information. This is incorrect for two reasons:
1. These instructions don't have a defined sampler index by
definition.
2. The driver was not setting it either, so effectively, we
have always been using whatever we had set for the first
texture, which is obviously bogus.
Fix this by running a lowering pass that sets the index to use
in backend_flags, which is what the compiler expects, based on
the texture index, which is what we want in GL since we make
this decision based on the texture format.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24537>
For tex instructions that don't have sampler state use backend_flags
instead of sampler index to bind default sampler state.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24537>
The lower_tex_packing pass relies on the sampler index to access packing
information, but this is only valid for tex instructions that have sampler
state (so not txf, etc). Instead, let backends provide a callback to inform
the lowering about the packing used with a given texture instruction which
is more flexible.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24537>
It can be useful to compare 2 runs with different compiler changes.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24552>
