When TCS isn't linked with VS, the vertex stride should be computed
from vertex outputs. This is only for shader object and shouldn't
change anything right now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24540>
With shader object, if VS and TCS aren't linked together, the LSHS
vertex stride should be computed from the vertex outputs. Otherwise,
if an output is unused, the stride is wrong in TCS.
This is currently for GFX8 only because for merged shaders this won't
be needed but shader object on GFX9+ isn't yet a thing.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24540>
According to WA description, we need to track DS write state
and emit a PSS_STALL_SYNC whenever that state changes.
Signed-off-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/18411>
According to WA description, we need to track DS write state
and emit a PSS_STALL_SYNC whenever that state changes.
Signed-off-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/18411>
This is required for Wa_18019816803 when blorp emit DS state.
Signed-off-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/18411>
This patch removes start_slot from set_vertex_buffers() as suggested in
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8142
compilation testing:
all gallium drivers, nine frontend compilation has been tested.
d3d10umd compilation has not been tested
driver, frontend testing:
only llvmpipe and radeonsi driver was tested running game
only the nine frontend changes are complex. All other changes are easy.
nine front end was using start slot and also using multi context.
nine frontend code changes:
In update_vertex_elements() and update_vertex_buffers(), the vertex
buffers or streams are ordered removing the holes. In update_vertex_elements()
the vertex_buffer_index is updated for pipe driver to match the ordered list.
v2: remove start_slot usage code from Marek (Marek Olšák)
v3: nine stream number holes mask code from Axel (Axel Davy)
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> (except nine, which is Ab)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22436>
Currently, negative array texture indices get saturated to 0 which,
while technically in-bounds, isn't what we want for Vulkan with image
robustness or robustness2. Vulkan requires that a negative index on a
texelFetch() count as out-of-bounds but a negative index on any other
texture operation gets clamped to 0. (See the spec section entitled
"(u,v,w,a) to (i,j,k,l,n) Transformation And Array Layer Selection").
Instead of using CVT for TXF, we now take U32 MAX with 0xffff. Because
it's unsigned, this ensures that negative array indices clamp to 0xffff
and will be considered out-of-bounds by the hardware (there are a
maximum of 2048 array indices in an image descriptor). For everything
other than TXF, we keep using an F32->U16 conversion but add a saturate.
This ensures that negative array indices clamp to 0 as per the Vulkan
spec. Very large indices will clamp to 0xffff which the hardware will
clamp to the maximum array index.
This fixes 324 tests in the dEQP-VK.robustness.* group, all those for 1D
and 2D array textures
Acked-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24593>
ARB shaders have no rules restricting i/o interfaces since it's assumed
that they'll match by name. given that mesa marks these all as separate
shaders, a separate path is needed to ensure these variables correctly
match up their i/o even when it's mismatched
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24608>
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>
