We ran into an issue with Intel drivers where it became tricky to tell
whether a timestamp must be recorded with a special end-of-pipe
compute instruction or something else.
We initially tried to deal with that internally by checking some state
in the command buffers but turns out it doesn't work.
This change adds a flag field to the tracepoint to have that
information there and the flags are passed to the record_ts vfunc.
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/29438>
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>
The output of the POSTSYNC_DATA has to be 32-byte aligned.
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>
Ref: bspec 68090
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29457>
Bspec: 68090
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29457>
Without this mapping no temporary workaround will be applied to LNL.
BSpec: 70821
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29457>
intel/dev/mesa_defs.json also must be updated when the new platform
enum is added.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29457>
Currently for an "unavailable" query, if VK_QUERY_RESULT_PARTIAL_BIT is
set, anv will return (slot.end - slot.begin). This can cause underflow
because slot.end might still be at the initial value of 0.
This commit fixes the issue by returning 0 in that situation.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29447>
The only remaining restriction applies to single sampled 3D textures on
Gen12.0. Move the check to disable CCS on such resources to the right
place.
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/28646>
In order to build grl, we need to get the device_info struct from the
PCI ID, but for pre-production platforms we don't want to enable them
unless INTEL_FORCE_PROBE is set.
Setting it when running intel_clc allows us to get the device_info
struct when the pre-production hardware is not ready to be enabled by
default.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
This environment variable allows some Intel devices that are
unsupported to be forced to run. These devices have incomplete
support, and therefore might not work at all.
Reworks:
* José: Simplify scan_for_force_probe() with strtok()
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
For example:
CHIPSET(0x56a0, dg2_g10, "DG2", "Intel(R) Arc(tm) A770 Graphics", FORCE_PROBE)
For now if a PCI ID has FORCE_PROBE set, then we refuse to start the
device.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
The queueFlags of the associated queue may have more flags than just the
type of queue it is, based on what that queue supports, like sparse or
protected content. Check that the queue is a blitter engine instead.
Fixes a bunch of dEQP-VK.api.copy_and_blit.core.*_transfer on MTL with
ANV_SPARSE=0
Fixes: 17b8b2cffd ("anv: Add support for a transfer queue on Alchemist")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29336>
Rework:
* José: Restore "Register Poll Mode" default to "Memory Poll"
* José: Other minor formatting changes to match other genxml
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29264>
Reworks:
- Rohan: Use a uint for the surface format since we're dropping the
SURFACE_FORMAT enum from genxml
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29264>
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>
