This layer was blocking Android emulated ASTC support as it did not
take "emu_astc_ldr" in to account.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Mi, Yanfeng <yanfeng.mi@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29415>
Because of the differences between i915 and Xe KMD this function is
needed to abstract the special handling that Xe KMD needs while
reading perf stream.
This special handling will be implemented in the next patch.
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/29421>
To be more explicit lets have 2 macros one with sample lenght other
with header and sample length.
This will also help add Xe KMD support as it don't have a header like
i915.
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/29421>
drm_i915_perf_record_header requires i915_drm.h but we want to remove
all i915_drm.h includes from common code, so replacing it by
intel_perf_record_header.
No changes in behavior expected as the structs and enums are identical.
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/29421>
This is a i915 specific struct and Xe KMD will not need anything like
that so lets allocate it in heap memory.
This will help us remove the i915_drm.h includes from common code.
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/29421>
More code will be moved to i915 specific files in the next patches.
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/29421>
read_oa_samples_until() was returning OA_READ_STATUS_ERROR even
if already read samples, then it tried again and KMD returned 0/empty
or EAGAIN(as the read would block).
This is not causing any issue because read_oa_samples_for_query()
FALLTHROUGH OA_READ_STATUS_ERROR to OA_READ_STATUS_FINISHED
but that I think it is worthy to fix it.
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/29421>
Another architecture register that requires some care before reading.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 49ee3ae9e8 ("intel/compiler: Lower FIND_[LAST_]LIVE_CHANNEL in IR on Gfx8+")
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29319>
When compilation is required, we should return
VK_PIPELINE_COMPILE_REQUIRED. The spec prevents the application from
passing a module or SPIR-V code so we have nothing to compile if the
cache lookup fails :
VUID-VkPipelineShaderStageCreateInfo-stage-06844:
If a shader module identifier is specified for this stage, a
VkShaderModuleCreateInfo structure must not be present in the pNext
chain
VUID-VkPipelineShaderStageCreateInfo-stage-06848:
If a shader module identifier is specified for this stage, module
must be VK_NULL_HANDLE
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11208
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29340>
Per the Vulkan Spec section 10.1, the implementation is supposed to
attempt to create all pipelines even if creation of any one pipeline
in a create call fails. If more than one error occur, any one error
is valid as a return value.
Signed-off-by: Renato Pereyra <renatopereyra@chromium.org>
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29315>
So that as soon as pipelines are freed, they're removed from the
cache.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11185
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Tested-by: Brian Paul <brian.paul@broadcom.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29283>
This reduces the amount of manual dependency tracking developers need to
do. This is turned on if glslang >= 11.3.0 is used, or 11.9.0 on
Windows, but otherwise the status quo is maintained. This means I have
not removed any use of `depend_files`. We could make make these hard
requirements and remove the use of `depend_files` too.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28329>
Otherwise u_trace has to think that each submission is a frame,
and that's not great if we want to gather statistics on per real
frame basis.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29220>
Fixes failures of CTS tests that currently end up emitting 64-bit
integer ADDs with saturation, which isn't supported by the hardware.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28283>
Note that some previously-supported 64-bit integer operations have
been removed from the hardware, so we need to instruct NIR to lower
them.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28283>
According to the simulator a cacheline of the blend state cache
corresponds to 3 cachelines of L3 that are always filled regardless of
the number of render targets in use. Allocate enough space to avoid
pagefaults under simulation, since a scratch page isn't bound by
default.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28283>
Rework:
* Francisco Jerez: Specify the src1 length value in the correct
units. Don't break earlier platforms.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28283>
So that the driver can decode the printf buffer.
We're not going to use the NIR data directly from the driver
(Iris/Anv) because the late compile steps might want to add more
printfs.
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/25814>
We'll use the delta for an upcoming internal printf mechanism, where
the PARAM_IDX will be the base printf reloc identifier and the BASE
will be the string id.
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/25814>
A format can't be standard and non-standard at the same time. If we
ever hit this assertion, it's because something behind the scenes has
evolved (such as the tiling formats) so something that was marked as
non-standard became standard. Add an assertion so we can quickly catch
these issues in the future and adjust the code.
I don't want to mix this assertion with the one in the line above
since that one is the most useful assertion we have in all the sparse
code, so it's good to know which one we're hitting.
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>
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>
The newer platforms can't support 8x and 16x since Tile64's shape for
them is not a standard block shape (and claiming standard block shapes
is higher priority than supporting things without it). The TileYs
platforms are fine.
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>
The Tile64 format from Xe2 is weird and some of its MSAA shapes are
non-standard. Reject them. Otherwise, we'll get dEQP failures such as:
deqp-vk: ../../src/intel/vulkan/anv_sparse.c:829: anv_sparse_calc_image_format_properties: Assertion `is_standard || is_known_nonstandard_format' failed.
Many tests can reproduce this issue, including:
dEQP-VK.memory.requirements.extended.image.sparse_tiling_optimal
Testcase: dEQP-VK.memory.requirements.extended.image.sparse_tiling_optimal
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>
This is all that's needed to make anv_sparse_bind_image_memory() work
with multi-sampled images.
The assert() we just added would have been really helpful when
debugging this.
All the dEQP tests with "sparse" in their names are passing *even*
without this patch. Real-world applications show very clear visual
corruption for sparse MSAA images bound through non-opaque binds since
only a fraction of the the actual image ends up being bound.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27306>
We call anv_get_image_format_properties() from
anv_GetPhysicalDeviceSparseImageFormatProperties2() because we want to
reject all images that we don't support for the non-sparse case. That
function does not take sample counts as its input, it outputs a list
of possible sample counts. In this patch we check the sample counts it
outputs: if what the user is querying isn't even supported by
non-sparse, reject it right away.
That saves us from having to code in anv_sparse_image_check_support()
cases that are coded elsewhere. Examples include: 1D images and
compressed formats.
This change affects a number of dEQP tests, including:
- dEQP-VK.api.info.sparse_image_format_properties2.1d.optimal.r4g4b4a4_unorm_pack16
- dEQP-VK.api.info.sparse_image_format_properties2.2d.optimal.bc2_srgb_block
Without this patch, and with sparse multi-sampling enabled, this would
hit the following assertion:
anv_formats.c:1903: anv_GetPhysicalDeviceSparseImageFormatProperties2: Assertion `false' failed.
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>
