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>
It was the default to show register pressure for each instruction,
but it gets in the way of cleaner diffs before/after an optimization pass.
Add INTEL_DEBUG=reg-pressure option to show it again.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29114>
The debug identifier is put into the captured buffers for error
capture. This helps us figure out what version of the driver people
are running when encountering a GPU hang. This identifier has the
git-sha1 + driver name.
libintel_dev is also a dependency of the compiler so any change to the
git-sha1 also triggers recompile which we want to avoid.
This changes moves the debug identifier to src/intel/common which
drivers already depend on, so the compiler is not affected anymore.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11136
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29128>
Starting from MTL there is registers in HW to read the IP version of
graphics, media and display IPs, those registers are called GMD.
IPs can be used in any combination to form a SOC/platform and each IP
has it own stepping/revision, making complex to track each IP stepping
using just PCI revision.
Since MTL will be supported by default by i915 KMD that don't have
a uAPI fetch IP versions, this feature will only be supported in LNL
and newer that are backed by Xe KMD.
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/26908>
The compiler only references `intel_device_info->subslice_masks` for
ray tracing workloads. Platforms which lack raytracing support can
share a cache even if they differ on this field.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28311>
Pci revision was included in the shader cache key because it can
enable platform workarounds. While some platform workarounds exist in
the compiler, none are dependent on the silicon stepping.
Many platforms differ only in the pci revision id, causing needless
duplication in cache entries between platforms.
When a platform ships publicly with stepping-specific compiler
workarounds, pci id must be incorporated into the shader cache key.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28085>
Xe KMD landed on drm-next, uAPI is now stable and we can remove
the build time parameter to enable support to it but platforms
older than Lunar lake will have experimental support with Xe KMD.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20418>
Workaround tool was already updated with MTL production stepping so no
need to return any stepping value for MTL.
For TGL it was also updated a long time ago, so no need to check for
revision 0.
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27399>
INTEL_PLATFORM_ATSM_G10 requires the same workarounds as INTEL_PLATFORM_DG2_G10
INTEL_PLATFORM_ATSM_G11 requires the same workarounds as INTEL_PLATFORM_DG2_G11
Closes: #10749
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27987>
This is a more sensible home for intel_dev_info.
Offline shader compilation will take intel_dev_info json files as
input. For that use case, the shader compiler hash value is needed in
the json file.
intel_dev_info will depend on intel/compiler, and must be located in
intel/tools to break a circular meson dependency.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26844>
intel/common has a build dependency on intel/dev so the later should
not have any dependendies on the first.
So here moving the definition of intel_engine_class to
intel_device_info.h because it is used in intel_device_info struct
and then including intel_device_info.h in intel_engine.h.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233>
Enable drm_shim to parse a serialized intel_device_info structure from
json. When overriding the gpu hardware, drm_shim provides the stubbed
intel_device_info structure to mesa through an unused ioctl.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27557>
intel_dev_info prints out struct intel_device_info in a user-friendly
format. Json format enables this information to be used as input for
tools.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27557>
Generate intel_device_serialize.c from a mako template, providing
functions to dump and parse intel_device_info.
intel_device_info.py declares python objects representing all type
declarations associated with intel_device_info. It is used as a data
source for intel_device_serialize_c.py
intel_device_serialize_c.py emits a c++ file with routines to dump
or load all struct members to/from json. The json format is a direct
translation of the c structure, with 2 exceptions:
- When parsing json, the no_hw member is always set to true to
indicate that the driver's intel_device_info does not correspond to
the current platform.
- When dumping to json, devinfo_type_sha1 is calculated to be a
checksum which changes whenever intel_device_info is updated. This
checksum is encoded in json. When parsing json, the driver verifies
that the checksum matches before loading data into
intel_device_info. This verifies compatibility.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27557>
Serialization of intel_device_info requires the specification of all
aspects of the type declaration in Python.
To avoid duplication, use the Python type information to generate the
struct as well as the serialization implementation.
This step is implemented first, because it provides explicit types for
some anonymous structures within intel_device_info. For example, the
'urb' member struct within intel_device_info cannot be serialized in a
C function unless we give it a type (eg, intel_device_info_urb_desc).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27540>
In preparation for generating struct intel_device_info, provide all
necessary details via python objects that describe it, including:
- integer macro definitions
- comments
- array sizes
- correct int types
- enumeration groups
- meaningful type names for inline struct members
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27540>
MTL and ARL share many code paths, and this macro will make it easier
to check for either of them.
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/27352>
While enumerating devices on a system with multiple implementations,
unnecessary ioctls will be issued before a driver checks if it supports a
given device.
This patch makes the driver fail early based on a intel_device_info.ver
check with 2 new parameters added to intel_get_device_info_from_fd.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27166>
While convenient, it was not necessary to use the mesa_scope in
intel_device_info.
Having a Intel specific enum here will help later the efforts
of serialization of intel_device_info.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27164>
Xe KMD reports SMEM size as half of RAM while i915 returns the whole
RAM size, so to keep it consistent here adjusting the values
returned by i915 KMD.
The free i915 SMEM also needs to be ajusted but as this is needed by
both KMDs because KMD uAPIs only reports free memory for applications
running elevated privileges, so this was moved to
intel_device_info_ajust_memory() to be shared by both KMD backends.
sram.mappable.size asserts had to be removed from i915 code paths
because of this adjustment.
anv_compute_sys_heap_size() was dropped in ANV and reduce in HASVK
because adjustments are now done in intel/dev level.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26567>
This function should only be used when i915 versions that don't have
DRM_I915_QUERY_MEMORY_REGIONS.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26567>
INTEL_NEEDS_WA macros are valid when a workaround applies to all
platforms which have the GFX_VERx10 versions for the workaround.
Some workarounds were fixed at a stepping after the platform release.
If a workaround applies partially to any platform, then GFX_VERx10
cannot be used to correctly apply the workaround.
This change invalidates INTEL_NEEDS_WA_16014538804 and
INTEL_NEEDS_WA_22014412737, which were fixed for MTL platforms at
stepping b0. The run-time checks were already present for all uses of
these macros. Updating the poisoned macros to INTEL_WA_{num}_GFX_VER
compiles out the run-time checks on platforms where they cannot apply.
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26898>
Gfx12.5 (DG2) will use DPAS instructions to accelerate the
implementation. Earlier platforms will use equivalent discrete
instructions (basically subgroup operations). Gfx12 (Tigerlake) will use
DP4A for 8-bit integer matrix multiplication. Older platforms, which
lack DP4A, will use a suboptimal instruction sequence. There is plenty
of room for improvement here.
On DG2 (Gfx12.5) gets the following results from the CTS:
Test run totals:
Passed: 1642/13982 (11.7%)
Failed: 0/13982 (0.0%)
Not supported: 12340/13982 (88.3%)
Warnings: 0/13982 (0.0%)
Waived: 0/13982 (0.0%)
On DG2 (Gfx12.5) with forced lowering, Raptor Lake (Gfx12) and Ice Lake
(Gfx11):
Test run totals:
Passed: 1662/13982 (11.9%)
Failed: 0/13982 (0.0%)
Not supported: 12320/13982 (88.1%)
Warnings: 0/13982 (0.0%)
Waived: 0/13982 (0.0%)
The difference in the number of tests run is due to
saturatingAccumulation not being set on DG2 when DPAS is used. There is
a comment in "intel/dev: Advertise integer configs with
saturatingAccumulation too" that explains how this could be added should
the need arise.
v2: Prefix type names with INTEL_CMAT_. Suggested by Lionel.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25994>
Note that the multipolygon PS disptach modes supported by Xe2 aren't
enabled by default yet, but they can be enabled manually via
INTEL_SIMD_DEBUG=fs2x8,fs4x8,fs2x16.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26606>
Xe2 follows MTL and has different prefetch sizes for different
types of engines.
BSpec: 60223
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26396>
Xe KMD requires that all platforms supported by it set PAT information.
This will be implemented in Iris and ANV in the next patches.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25462>
Xe KMD requires PAT for all platforms so here adding PAT entries to
all platforms supported by Xe KMD.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25462>
