In commit 44351d67f8, I needed to change some variables in a check for
compression in anv_can_fast_clear_color_view(). Instead of doing that, I
dropped the check altogether because I thought the call to
anv_layout_to_fast_clear_type() which followed right afterwards would
return ANV_FAST_CLEAR_NONE if the aux usage was ISL_AUX_USAGE_NONE.
That turned out not to be the case, due to special-casing of Xe2+. For
now, make Xe2+ more like other platforms when it comes to enabling
fast-clears. If there comes a reason to actually fast-clear with
ISL_AUX_USAGE_NONE, we can revisit this.
Fixes: 44351d67f8 ("anv: Change params of anv_can_fast_clear_color_view")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11920
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31297>
When no pipeline cache is provided by the application and we rely on the
internal one, cache hits are not counted as such.
This was causing us to return COMPILE_REQUIRED on some cases where all
shaders had been found in the cache, as well as some unnecessary extra
processing in the case that we did have to compile the pipeline.
Fixes: 1dacea10f3 ("anv: implement caching for ray tracing pipelines")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31298>
We have not yet added the shaders to the pipeline->shaders array at
this point. If we couldn't compile (or were asked not to) the
pipeline, we were leaking references to any shaders found in the cache.
This would manifest as an assert on device destruction:
vk_pipeline_cache_destroy: Assertion `cache->object_cache->entries == 0' failed.
Fixes: 58c9f817cb ("anv: fix pipeline executable properties with graphics libraries")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31298>
We setup an empty render target when there are no color attachments,
which effectively makes it a different surface state. In most cases
the compiler will insert a null-rt bit in the extended descriptor
which means the RT isn't even accessed. But in some cases like
alpha-to-coverage output + depth/stencil write, we will access the
render target because using the null-rt will prevent alpha-to-coverage
from happening.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 2bd304bc8f ("anv: Skip the RT flush when doing depth-only rendering.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31196>
Whenever we execute a fast-clear due to LOAD_OP_CLEAR, we decrease the
number of layers to clear by one. We then enter the slow clear function
and possibly exit without clearing if the layer count is zero.
Unfortunately, we've already compiled the shader for slow clears by the
time we exit. Skip the slow clear function if there are no layers to
clear.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31167>
vk_common_QueueWaitIdle() creates a syncobj, does a submit with no
batch buffers what translates to execute trivial_batch_bo and then
waits for syncobj to be signaled when trivial_batch_bo finishes.
On Xe KMD on other hand we can avoid the trivial_batch_bo submission
and instead use the special DRM_IOCTL_XE_EXEC with num_batch_buffer == 0
to get a syncobj to be signaled when the last exec finish execution.
This should free a bit GPU to execute more important workloads.
This will also optimize vkDeviceWaitIdle() that calls QueueWaitIdle().
It have to fallback to vk_common_QueueWaitIdle() when queue is in
VK_QUEUE_SUBMIT_MODE_THREADED mode because vkQueueWaitIdle()
could return but there still stuff in VK/CPU submission queue.
Also it could cause use after free when resources attached to
submission are freed before it is processed, example:
vkCreateFence() or vkCreateSemaphore()
vkQueueSubmit() // with Fence or Semaphore created above
vkQueueWaitIdle() // with the race it returns
vkDestroyFence() or vkDestroySemaphore()
// vk_queue_submit_thread_func() start to process submission above...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30958>
Split anv_xe_wait_exec_queue_idle() into 2 functions, the first
function creates the syncobj and prepares it to be signaled when the
last workload in queue is completed.
And the second one that calls the first function, then waits for the
syncobj to be signaled and destroy the syncobj.
The main reason for that is that the first function can be reused in
Iris and a future patch will add another user, so lets share it.
No changes in behavior are expected here.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30958>
It was always using device->context_id what is not valid in i915 when
has_vm_control is true or when running with Xe KMD.
But anv_AcquireProfilingLockKHR() don't have the queue information so
at least for now we will only support queries in a single queue.
And for consistency doing the same in
anv_QueueSetPerformanceConfigurationINTEL() although here we have the
queue parameter but queries are only supported in render engine
so it would only expose other queues if user set some parameters.
Cc: 24.2 <mesa-stable>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30652>
We have a couple of checks where we allow this to be NULL, but later we
unconditionally and unavoidably dereference the pointer, which means
there's no way that it ever could have been NULL. Change the assert at
the top to not allow NULL, and remove checks for it being NULL
CID: 1616544
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31156>
Our array has a fixed size of 32, and we know at the start of the block
that our type_count is < 32, but in the loop we grow the block, in
theory up to 31 times. Coverity notes that, and points out we could
write off the end of the array. Add an assert in the loop to ensure we
don't, and to help Coverity out.
CID: 1615171
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31173>
In the error handling path we end up creating a vk_sync and then later
we vk_sync_wait() on it. If that wait fails somehow we'll end up calling
vk_queue_set_lost(&queue->vk, ...) which would segfault if queue is
NULL.
If we end up in this situation (no queue), return directly whatever the
backend's vm_bind function returned, propagating the error up if
necessary.
Fixes: dd5362c78a ("anv/xe: try harder when the vm_bind ioctl fails")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31048>
Coverity alerts that the uint32_t pointer I was passing into
isl_color_value_pack() could possibly be used as an array. The value is
being used as such, but only the first element of that array should be
accessed. That's because the depth buffer formats I'm also passing into
the function only have a single channel, R. Nonetheless, let's update
the code to avoid the warning.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31123>
In c1a7d520f3, we disabled AUX usage for imported images when they are
using an explicit modifier that doesn't support it.
We need to do the same when the modifier is picked by the driver,
otherwise the memory requirements reported for an exported image don't
match those we report for import.
Fixes: c1a7d520f3 ("anv: Disable aux if the explicit modifier lacks it")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31051>
anv_tests tries to create a large number of threads, all of which wait
to be able to execute simultaneously, then launch a reasonable-size
workload.
Under load, cloning each of the 16 threads takes 15ms serially, for a
delay of 240ms before the tests start running; running the test 64
times gives us 15.36s for a single testcase in isolation, assuming that
the bits which aren't forking are free.
To give it the best shot at completing in time, mark it as a
non-parallelisable test (since Meson will also try to parallelise it
out), and also halve the number of runs it attempts. And then give it a
longer timeout so it doesn't fail even in extremis.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31059>
Otherwise we can end up with uninitialized values, this fixes following
valgrind warning:
==31283== Uninitialised byte(s) found during client check request
==31283== at 0x503E4DE: anv_batch_bo_finish (anv_batch_chain.c:345)
==31283== by 0x504220A: anv_cmd_buffer_end_batch_buffer (anv_batch_chain.c:1103)
==31283== by 0x55A0E4F: end_command_buffer (genX_cmd_buffer.c:3455)
==31283== by 0x55A0E82: gfx11_EndCommandBuffer (genX_cmd_buffer.c:3466)
==31283== by 0x11233A: ??? (in /usr/bin/vkcube)
==31283== by 0x10BDEE: ??? (in /usr/bin/vkcube)
==31283== by 0x49B5149: (below main) (in /usr/lib64/libc.so.6)
==31283== Address 0xc10c4d8 is 1,240 bytes inside a block of size 8,192 client-defined
==31283== at 0x5036EF6: anv_bo_pool_alloc (anv_allocator.c:1284)
==31283== by 0x503E0E1: anv_batch_bo_create (anv_batch_chain.c:262)
==31283== by 0x5040D3F: anv_cmd_buffer_init_batch_bo_chain (anv_batch_chain.c:868)
==31283== by 0x504F9C1: anv_create_cmd_buffer (anv_cmd_buffer.c:147)
==31283== by 0x6B718C4: vk_common_AllocateCommandBuffers (vk_command_pool.c:206)
==31283== by 0x4FB06B2: vkAllocateCommandBuffers (trampoline.c:1996)
==31283== by 0x111E6B: ??? (in /usr/bin/vkcube)
==31283== by 0x10BDEE: ??? (in /usr/bin/vkcube)
==31283== by 0x49B5149: (below main) (in /usr/lib64/libc.so.6)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30990>
