Before this patch, when querying the clear color plane's stride, iris
would return the aux surface stride. This was okay because the clear
color plane wasn't really used for anything.
This doesn't work on XeHP however. On that platform, the aux surface
stride is zero (because it doesn't have an ISL surface for the CCS).
This is a problem because mesa's implementation of eglCreateImage
rejects strides of zero (see dri2_check_dma_buf_attribs) and this value
may be queried from GBM and passed into EGL.
When the DG2 clear color modifier is enabled, this avoids EGL_BAD_ACCESS
errors when running the piglit test,
ext_image_dma_buf_import-intel_modifiers.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14759>
Pick the clear color BO if the clear color plane is being queried. This
avoids picking a NULL aux BO on XeHP.
When creating shared resources, we place the gallium-visible planes in
the same buffer object. However, when importing them, we aren't very
strict about each plane sharing the same BO. So, instead of just using
res->bo, we use a couple ternaries to figure out the right one.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14759>
Semaphores info was stored as an info of event_wait cpu jobs and this
leads to mem leak when the same event_wait job in the same cmd buffer
batch was submitted more than once. As a result,
`dEQP-VK.api.command_buffers.record_simul_use_primary` fails due to a
double-free of sems_info.
In this patch, we no longer use v3dv_event_wait_cpu_job_info to store
semaphores from a submit info, since semaphores is related to a queue
submission and not to the event_wait job type. If we spawn a wait_thread,
we copy semaphores to an auxiliary struct (v3dv_wait_thread_info) that
will be used in wait_thread to get job and semaphores information. When
the spawned thread finishes, it releases the related
v3dv_wait_thread_info and the semaphores copy as well.
Fixes: d5bd18fb ("v3dv: store wait semaphores in event_wait_cpu_job_info")
Suggested-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14736>
DXIL doesn't support a single varying having components belonging
to multiple streams. For geometry shader outputs, whenever we find
this to be the case, break up that variable into multiple sub-
variables, and update stores to that variable to write to the new
sub-variables instead.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14787>
The previous logic was a bit bolted-on, using a linked list of queries
to implement cases where a GL query needed maybe multiple D3D queries.
Once the sub-query was created, it was always begun/ended along with
the parent query, but that's not sufficient or correct.
Instead, we need to be able to have mutually-exclusive subqueries
underneath a parent query. This will let us handle using different
counters for the same GL query in different pipeline configs, and then
accumulating the results together.
Fixes the arb_transform_feedback2-pause-counting piglit test.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14787>
If an indirect arg buffer is being produced by a compute shader, then when
we go to consume it as an SSBO in a compute transform pass, we need to insert
a UAV barrier to prevent the two dispatches from overlapping. For app dispatches,
this is the app's responsibility via explicit barrier APIs, and if they don't,
then they're allowed to overlap.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14787>
Workgroup is only allowed in compute shaders, and Device should be more
in line with the intended use here
the alternative would be to keep using Workgroup for compute and use Device
otherwise, but this would effectively make atomic ops non-atomic, which seems
like it isn't desirable
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14690>
according to spec, these must match the texel pointer type
cc: mesa-stable
fixes (nvidia):
dEQP-GLES31.functional.image_load_store.2d.atomic.exchange_r32f_return_value
dEQP-GLES31.functional.image_load_store.2d_array.atomic.exchange_r32f_return_value
dEQP-GLES31.functional.image_load_store.cube.atomic.exchange_r32f_return_value
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14690>
glsl/nir automatically swizzle the value if a vecN is being used, but spirv
requires a single scalar, so this has to be detected and unswizzled to avoid
violating spec and crashing shader compilers that are less permissive than mesa's
fixes (nvidia):
dEQP-GLES31.functional.shaders.builtin_functions.integer.bitfieldextract*
KHR-GL46.shader_bitfield_operation.bitfieldExtract*
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14690>
Vulkan bindings take only one slot per variable, but d3d12 ones take one
slot per entry when the variable is an array. This forces us to pass
an explicit vulkan -> d3d12 mapping table when dealing with vulkan
shaders.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14765>
The unconditional Y-flip is needed for Vulkan 1.0 since D3D12 and
Vulkan coordinate systems differ. Conditional YZ-flip is needed if
we want to support negative viewport height/depth.
Prepare spirv_to_dxil() to support that, and while at it, prepare
things for multi-viewport: the Y/Z flips are per-viewport and encoded
in a 32bit bitmask, with the upper 16bits reserved for Z flips, and the
lower 16bits reserved for Y flips.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14765>
This guarantees that we get an image that's created with exactly the
swapchain image creation parameters instead of trying to emulate it
inside the driver. Ideally, we'd use the fancy new bind helper too but
our magic ANV_IMAGE_MEMORY_BINDING_PRIVATE gets in the way and we really
do want to re-bind ourself.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12031>
With Vulkan 1.1, we have a VkImageSwapchainCreateInfoKHR struct which
lets you create a new VkImage which aliases a swapchain image. However,
there is no corresponding swapchain create flag so we have to set
VK_IMAGE_CREATE_ALIAS_BIT all the time.
We need to do a bit of work in ANV to prevent it from asserting the
moment it sees one of these. Fortunately, they're already safe because
WSI images go through a different bind path for
VkBindImageMemorySwapchainInfoKHR.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12031>
