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>
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>
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>
The benchmarks we're tracking tend to prefer clearing depth buffers to
0.0f when the depth buffers are part of images with multiple aspects.
Otherwise, they tend to prefer clearing depth buffers to 1.0f.
Replace the ANV_HZ_FC_VAL constant with a function which implements this
heuristic.
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30767>
Xe2 can easily support fast-clearing depth buffers to multiple clear
values. Instead of assuming a hard-coded value in various parts of the
driver, pass the clear value down the expected paths.
For consistency, also adjust the slow depth clear function to have a
matching parameter.
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30767>
We're going to be storing clear colors from the drivers rather than
BLORP. Add a function for this purpose.
For now, the first use replaces init_fast_clear_color(). One change in
behavior is that the clear color initialization is now done without
write-checking on gfx12. This actually matches what anv does to other
writes to the image's fast-clear tracking state. We can fix this later
if and when we address the larger issue.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30824>
The hardware's clear color conversion feature requires invalidating the
texture cache for every fast clear. We're no longer using the hardware
feature, so we longer need the invalidation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30646>
This improves drivers in the following ways:
* iris_hiz_exec() and crocus_hiz_exec() gets rid of the narrowly-used
update_clear_depth parameters.
* iris avoids fast-clearing if the aux state is CLEAR. crocus avoids
this too, but didn't actually need it in the first place.
* iris updates the value once per fast_clear_depth() call instead of
doing an update for each layer being cleared.
* anv now updates the clear value when transitioning from an undefined
layout instead of doing so on every fast-clear. This should be safer
because we don't perform state cache invalidates when changing the
clear value. So, existing surface states won't have any stale values.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30520>
The PRMs suggest that certain classes of auxiliary surface operations
will automatically synchronize when performed back-to-back:
Any transition from any value in {Clear, Render, Resolve} to a
different value in {Clear, Render, Resolve} requires end of pipe
synchronization.
Make use of this functionality by batching CCS and MCS flushes when
compatible auxiliary surface operations are performed within a command
buffer.
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11325
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29922>
According to the HSD, this is an alternative option for Wa_14016712196.
Taking this option allows us to combine this workaround with a couple
other depth workarounds. Make sure to execute these workarounds before
the workaround for the depth register mode, so that the stalling flush
is not impacted.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29922>
This flush was introduced with the following commits:
8949d27bb8 ("anv: implement gen9 post sync pipe control workaround")
bcb611361b ("anv: implement gen12 post sync pipe control workaround")
The flush was unsued with the following commit:
e79e1ca304 ("intel: Drop Tigerlake revision 0 workarounds")
This prevents some extra pipecontrols caused by a following patch.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29922>
We want to reduce the buffer allocations for other type of data than
timestamps.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29944>
Pretty big change... Sorry for that.
I can't exactly remember why I created 2 heaps. I think it's because I
mistakenly thought the samplers in the binding sampler pointers needed
to be indexed from the binding table. But that's not the case, they
just need to be in the dynamic state heap.
In the future, this change will allow to also allocate buffers for
push constant data in the newly created dynamic_visible_pool which
will be useful on < Gfx12.0 where this is the only place push constant
data can live for compute shaders.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30047>
Newer hardware is smart enough to know that if something writes to a
NULL tile and immediately reads back the value (from the cache), the
value should read back as zero, not whatever was written to the cache
but not the memory. Due to that, we don't need to flush the tile
cache, which is quite expensive.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11029
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29953>
These were only applied in emit_apply_pipe_flushes but in theory could
be required for some other individually shot pipe controls.
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/29897>
Completely skip the stall & programming if the bindless address has
not changed. Only on Gfx12.5+ since previous generations also program
the binding table pool base address through STATE_BASE_ADDRESS.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29595>
The mi-builder already takes care of mi write/read fences, but we have
a few cases in Anv where we also need to fence mi-write ->
shader-read.
We also have one case where a command buffer jump address is modified
by a previous mi write command.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29595>
Since we don't need to share that data with other fixed functions.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29571>
We can remove a bunch of TRTT specific code from the backends as well
as manual submission tracking.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28975>
This AUX-TT is only updated on the CPU since ee6e2bc4a3 ("anv: Place
images into the aux-map when safe to do so"). So the only really
important invalidation that needs to happens is on the beginning of a
primary command buffer.
We are required to idle the pipes prior invalidation the AUX-TT. This
might not be happening when the invalidation is put at the beginning
of the secondary command buffers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29671>
We increased the size of the timestamps but only copied 64bit values
from the secondaries.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 521c216efc ("anv: use COMPUTE_WALKER post sync field to track compute work")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29438>
Most of what we do in this function is conditional to not have
VK_RENDERING_SUSPENDING_BIT, so check for it once.
Suggested-by: Iván Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27306>
Consider the following program:
- Uses a multi-sampled image as the color attachment.
- Draws simple geometry at the color attachment.
- Uses the (non-multi-sampled) swapchain image as the resolve image.
- Presents the result.
If the color attachment image (the multi-sampled one) is a sparse
image and it's fully bound, everything works and this patch is not
required.
If the image is partially bound (or just completely unbound), without
this patch the unbound area of the image that ends up being displayed
on the screen is not completely black, and it should be completely
black due to the fact that we claim to support
residencyNonResidentStrict (which is required by vkd3d for DX12).
On DG2, what ends up being displayed in the swapchain image is
actually the whole image as if it was completely bound. On TGL the
unbound area partially displays the geometry that was supposed to be
drawn, but the background is a different color: it's a weird corrupted
image. On both platforms the unbound areas should all be fully black.
This patch applies the proper flushing so that we get the results we
should have.
The bug fixed by this patch is not caught by dEQP or anything our CI
runs (dEQP does have some checks for residencynonResidentStrict
correctness, but none that catch this issue in particular). I was able
to catch this with my own sample program. Using INTEL_DEBUG=stall also
makes the problem go away.
If we had a way to track which images are fully bound we would be able
to avoid this flush. I had code for that in the earliest versions of
sparse before xe.ko had support for gpuva, but it requires maintaining
a bunch of lists, so I'm not sure that's actually worth it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27306>
Initial work by Rafael Antognolli <rafael.antognolli@intel.com>
Reworks
- Rebase to main
- Emit the right hiz op for higher mip levels when transitioning the
depth buffer
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28629>
