Here renaming the PAT entries to a name that better express each
entry.
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/25447>
Iris and ANV will need to switch to this PAT entry for BOs without
special needs.
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/26099>
mmap mode information will be used to properly calculate the mmap flags
in the i915 mmap uAPI and also will be used for BO creation when the
PAT uAPI lands in Xe KMD.
Xe KMD will also require the coherency mode during the BO creation.
So to avoid information duplication, adding this information to
intel_device_info platform entries.
No changes in behavior here.
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/26099>
Depending on the ordering of includes, GFX_VER may not defined for
intel_device_info.h. The failure mode of this case is silent:
BITSET_TEST will be called when it could be compiled out.
GFX_VERx10 should be used in place of GFX_VER. GFX_VERx10 is defined
by a compiler flag, and is always present for genX compilation units.
Fixes: 3c9a8f7a6d ("intel/dev: generate helpers to identify platform workarounds")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21908>
This same information is also used in ANV, so intel_device_info is
a better place to have it.
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/21972>
Workarounds for defects in Intel silicon have been manually
implemented:
- consult defect database for the current platform
- add workaround code behind platform ifdef or devinfo->ver checks
Some bugs have occurred due to the manual process. Typical failure
modes:
- defect database is updated after a platform is enabled
- version checks are overly broad (eg gfx11+) for defects that were
fixed (eg in gfx12)
- version checks are too narrow for defects that were extended to
subsequent platforms.
- missed workarounds
This commit automates workaround handling:
- Internal automation queries the defect database to collate and
summarize defect documentation in json.
- mesa_defs.json describes all public defects and impacted platforms.
Defects which are extended to subsequent platforms are listed under
the original defect.
- gen_wa_helpers.py generates workaround helpers to be called
in place of version checks:
- NEEDS_WORKAROUND_{ID} provides a compile time check suitable for
use in genX routines.
- intel_device_info_needs_wa() provides a more precise runtime
check, differentiating platforms within a generation and
platform steppings.
Internal automation will generate new mesa_defs.json as needed.
Workarounds enabled with these helpers will apply correctly based on
updated information in Intel's defect database.
Reviewed-by: Dylan Baker <dylan@pnwbakers>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20825>
It's only used by fragment shaders, so halving it matches the size
used in the most optimal primitive pipeline (VS + FS).
This change frees some URB space for mesh and task shaders and as
a result improves vk_meshlet_cadscene performance by up to 2%,
depending on the model.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21559>
Tigerlake PRM: Volume 2c: Command Reference: Registers Part 2 - Registers M through Z
RCU_MODE :: Compute Engine Enable
This bit indicates if Compute Engine (a.k.a Dual Context or Multi
Context) is enabled or not. This bit must be treated as global
control for enabling and disabling of compute engine. Hardware
allocates required resources for the compute engine based on this
bit.
....
HW reserves 4KB of URB space...
Right now no gen12 platform has Dual Context enabled in kernel side,
exposing a compute engine but that can change, so here adding
has_compute_engine to intel_device_info and only reserving URB space
if compute engine is available.
While at it also fixing the error path when pb_slabs_init() fails.
Bspec: 46034
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21031>
This is a KMD independent struct to hold memory class and instance
values.
drm_i915_gem_memory_class_instance usage will be gradually replaced.
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/20948>
Intel GPUs will have a new kernel mode driver, support for some
platforms will overlap so we will need to detect in runtime what is
the kernel mode driver loaded for each device.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20773>
Unusual hardware features that require special hanlding usually get a
devinfo field, so do this for MTL's unordered DF types. This will
guarantee that any platform based on MTL (thus inheriting from
MTL_FEATURES) will automatically be handled in these special cases.
v2: s/has_unordered_64bit_float/has_64bit_float_via_math_pipe/ (Curro).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20072>
Whether or not CCS can be used without initialization depends on the
platform:
- On gfx7-8, each CCS element is 1-bit and encodes "fast-cleared" or
"pass-through". So, those platforms have no illegal values.
- On gfx9-11, each CCS element is 2-bits and some bit combinations
are invalid.
- On gfx12+, each CCS element is 4-bits but they have no truly illegal
values. Unused encodings are interpreted as "pass-through".
Refer to the "MCS/CCS Buffers for Render Target(s)" sections of the
PRMs for more info.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20118>
Iris, hasvk and anv were fetching the same information, better do it
on one place.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19425>
Iris, hasvk and anv were fetching the same information, better do it
on one place.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19425>
All 4 drivers were fetching the same information, better do it on one
place.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19425>
This convertions were missed due to bad rebased in my end, sorry.
Fixes: 03b959286e ("intel: Make engine related functions and types not i915 dependent")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18975>
v2: Use the upper bound of dual subslices as the ID is not remapped
with fused off parts and this is what we'll use for a bunch of
computation in RT.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16970>
MTL has different CS prefetch sizes for each CS type.
So here replacing the cs_prefetch_size in intel_device_info struct
by a function that takes as argument the i915 engine class.
Fixes:
- func.cmd-buffer.small-secondaries.q0
- dEQP-VK.multiview.secondary_cmd_buffer.*
- Several other VK CTS tests that uses secondary_cmd_buffer
v2:
- renamed to intel_device_info_get_engine_prefetch() (Jordan)
v3:
- renamed to intel_device_info_calc_engine_prefetch()
- store each engine class prefetch in intel_device_info
BSpec: 45718
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/18597>
Only on platforms that support it.
v3: Split out code setting up ray query shadow buffer (Caio)
Don't forget to setup ray query globals even when no shadow buffer
is used (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13719>
DG2 introduces per primitive coarse pixel settings (in stages
preceding the PS shader) and also a control surface specifying the
rate at through the resulting surface.
v2: update comment (Caio)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13739>
This should only be set on XeHP. It implies that CCS works via based on
the virtual addresses involved and a flat memory carve-out, rather than
treating CCS like a surface, or using auxiliary maps.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14687>
This will be used to conditionally use hwconfig values to update
intel_device_info at runtime.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13866>
The chipset_id should be named after i915 ioctl that's called
to get the device id. In user space this field holds pci device
id in reality. We now have a pci_device_id queried from drm
instead using the ioctl, so there is no much reason to keep
the chipset_id for the same purpose.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13936>
Having PCI bus and dev info in the base struct
'intel_device_info' enables us to utilize the info across
multiple drivers for several purposes, such as computing
device uuids in a multi-gpu system.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13936>
This field is an average computation that is not actually useful for
any of our driver code.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14510>
