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>
This flag is required to properly calculate the PAT index of the
imported BO.
Cc: mesa-stable
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>
Even if this technically won't change anything, it prevents a false-positive of
uninitialized use of variables with clang.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26067>
In the case `if (var)` is false, the value will still be used but uninitialized.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26067>
register_state_var will have to convert everything to gl_state_index16 and the
values given to it are already either gl_state_index or any short integer which
are covered by the gl_state_index16 type.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26067>
We need to manually resolve the CCS surface when it's available along
with the MSAA compression, currently we don't handle that so disable the
CCS compression for now.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26043>
This change introduce the full resolve of MCS data by copying compressed
surface to uncompressed surface and also disables the auxiliary buffer
if MSRT is bound as texture on ACM platform.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26043>
Normally, we insert barriers automatically based on bind points. If
a resource is bound as both a shader image/SSBO (UAV) and other read-only
bind points, we'll choose the UAV state. This behavior is modified by
the memory barrier API - if the memory barrier indicates that a read
is desired, previously, we would've just not put any barriers to UAV
states. Now, we just use that state to disambiguate between read states
vs write states for a resource that's bound as both.
This turns out to be problematic in some circumstances, e.g.:
* PBO download, which does a memory barrier afterwards, since it uses
shader images to write, and those might be accessed immediately as
a texture afterwards.
* A user-issued draw that writes to a SSBO. This should indicate in the
state tracker that the SSBO is in the UAV state.
* Some other op, like a copy, that writes to the SSBO.
Before, the "pending memory barrier" state would cause the user draw to
not be put in the UAV state, which means that the copy wouldn't issue a
barrier *out* of the UAV state, resulting in the copy being unsynchronized.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26104>
From:
if (sel->info.uses_grid_size) {
if (sctx->screen->info.has_set_sh_pairs_packed) ...
... else ...
}
if (sel->info.uses_variable_block_size) {
if (sctx->screen->info.has_set_sh_pairs_packed) ...
... else ...
}
if (sel->info.base.cs.user_data_components_amd) {
if (sctx->screen->info.has_set_sh_pairs_packed) ...
... else ...
}
To:
if (sctx->screen->info.has_set_sh_pairs_packed) {
if (sel->info.uses_grid_size) ...
if (sel->info.uses_variable_block_size) ...
if (sel->info.base.cs.user_data_components_amd) ...
} else {
if (sel->info.uses_grid_size) ...
if (sel->info.uses_variable_block_size) ...
if (sel->info.base.cs.user_data_components_amd) ...
}
si_cp_copy_data is moved to the beginning because it's shared.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26095>
First, the following universal helpers are defined:
- radeon_set_reg_seq
- radeon_set_reg
- radeon_opt_set_reg
- radeon_opt_set_reg2
- radeon_opt_set_reg3
- radeon_opt_set_reg4
- radeon_opt_set_reg5
- radeon_opt_set_regn
- gfx11_push_sh_reg
- gfx11_opt_push_sh_reg
Then the config, context, sh, uconfig, push_gfx and push_compute helpers
are implemented calling the above.
A lot of macros were receiving sctx via a parameter, which is changed to
use sctx directly in the macro (and the parameter is renamed to "_unused").
The only functional change is that the perfctr registers that incorrectly
set the predicate bit now correctly set the RESET_FILTER_CAM bit.
The helpers no longer check info.uses_kernel_cu_mask.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26095>
This unblocks Xwayland with zink-on-venus + sommelier wayland proxy.
- For glamor, zink uses linear modifier.
- For Virgl clients, classic 3d resource is used and sommelier fixes
the modifier and stride infos no matter wl-drm or dma-buf protocol.
- For Venus clients:
- via the legacy wl-drm protocol, invalid modifier is passed via
sommelier, and host recovers the tiling in the way dealing with
modifier unaware clients (e.g. I915_GEM_GET_TILING). For hosts
unable to recover, they assume linear and venus forces linear on
legacy path.
- via the new zwp_linux_dmabuf_feedback_v1 (version 3/4) protocol,
explicit modifier is used, and zink handles that without issues.
This doesn't deserve a driconfig as zink-on-venus to support xserver
itself already requires special enough integration beyond a config.
Reported-by: Igor Torrente <igor.torrente@collabora.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10066
Fixes: 1c3db3e39a ("zink: blow up broken xservers more reliably")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26082>
`libvdrm` is unconditionally linked to `libvulkan_freedreno` which isn't available without the `virtio` subdirectory being included. It has been gated behind the `virtio` KMD to prevent linking errors in other cases as it's not necessary.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26100>
The unconditional inclusion of the `virtio` subdirectory introduced by !24733 causes a full dependency on DRM, it breaks any systems that have `system_has_kms_drm = false`, including Turnip with just the KGSL KMD. A temporary solution to this is gating the inclusion when `system_has_kms_drm` isn't set but this should be replaced with more specific gating in the future.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26100>
Estimating the batch space required can be tricky because of all the
workarounds. So implement chaining of batches like we do for command
buffers.
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/26087>
Otherwise I trigger a compiler warning here about a potentially
unwritten variable. Let's just make it clear to the compiler what's
going on.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26064>
We need update kernel often. We need test kernel changes often.
Introduced `KERNEL_EXTERNAL_TAG` to differ between `KERNEL_TAG` which is
also used to rebuild the containers. We don't need rebuild containers
for the external kernel, so this way we don't have to.
Updating kernel goes wruuuuuum.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23563>
In the tagged commit, we stopped actually inverting the condition, and
instead relied on the "invert_cond" flag. But we missed a few places
where this flag should've been handled too.
Also, add a few more tests to make sure this won't regress in the future.
Fixes: 99a7a664 ("nir/loop_analyze: Change invert_cond instead of changing the condition")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10012
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26024>
