With dynamic rendering, it's allowed to begin rendering with depth or
stencil only but still with a depth/stencil format. The test below
checks that unbound part of ds isn't modified, if depth is bound and
stencil not and vice versa.
This fixes a recent CTS
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.partial_binding_depth_stencil.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25350>
(cherry picked from commit 1ef5feac5e)
Fixes the build on OpenBSD, where major() is in sys/types and
sys/sysmacros.h does not exist. Also include sys/mkdev.h if
MAJOR_IN_MKDEV is defined.
Fixes: 6d60115be7 ("zink: Fix enumerate devices when running compositor")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26735>
(cherry picked from commit 33eecafe75)
We only need it for indirect draws.
Improves performance on an i7-12700 and A770:
- Piglit's drawoverhead base case +150.639% +/- 2.86933% (n=15).
- gfxbench5 gl_driver2_off +19.7219% +/- 1.13778% (n=15)
- SPECviewperf2020 catiav5test1 +1.6831% +/- 0.552052% (n=10).
Cc: mesa-stable
Reviewed-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/26806>
(cherry picked from commit 55c262898a)
Whenever we use a BO in a batch, we need to find its corresponding exec
list entry, either to a) record that it's been used, b) update whether
it's being written, c) check for cross-batch implicit dependencies.
bo->index exists to accelerate these lookups. If a BO is used multiple
times by a batch, bo->index is its location in the list. Because the
field is global, and a BO can in theory be used concurrently by multiple
contexts, we need to double-check whether it's still there. If not, we
fall back to a linear search of all BOs in the list, looking to see if
our index was simply wrong (but presumably right for another context).
However, there's one glaringly obvious case that we missed here. If
bo->index is -1, then it's wrong for /all/ contexts, and in fact implies
that said BO has never been added to any exec list, ever. This is quite
common in fact: a new BO, never been used before, say from the BO cache,
or streaming uploaders, gets used for the first time.
In this case we can simply conclude that it's not in the list and skip
the linear walk through all buffers referenced by the batch.
Improves performance on an i7-12700 and A770:
- SPECviewperf2020 catiav5test1: 72.9214% +/- 0.312735% (n=45)
Cc: mesa-stable
Reviewed-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/26806>
(cherry picked from commit d55b5d4af5)
The initial logic was to remember the place were SPI_SHADER_PGM_LO_*
are written, then assume that we can get the register offset because
the sequence would always be:
PKT3_SET_SH_REG
SPI_SHADER_PGM_LO_* register offset
VA low 32 bits value <- reg_va_low_idx
The problem is that this sequence isn't guaranteed, for instance we
can get this instead:
0 c0067600 |
1 00000046 |
2 003ffffd | SPI_SHADER_PGM_RSRC3_VS
3 00000020 | SPI_SHADER_LATE_ALLOC_VS
4 * 00002080 | SPI_SHADER_PGM_LO_VS
5 00000080 | SPI_SHADER_PGM_HI_VS
So the assert in si_state_draw.cpp would fail as well as the VA
update logic.
So instead remember which the SPI_SHADER_PGM_LO_* offset, and the low
32 bits of the VA in si_update_shaders.
Fixes: 8034a71430 ("radeonsi/sqtt: re-export shaders in a single bo")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26774>
(cherry picked from commit b55a2065e0)
Not expecting this to actually fix anything externally visible,
but reduces some invalid usage when the resulting vector is
not 16 elements long (e.g. the C/result matrix).
Fixes: 9df4703fbb ("radv: Add cooperative matrix lowering.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26768>
(cherry picked from commit 07ad6fd34a)
When `MESA_LOADER_DRIVER_OVERRIDE` is set to `zink` and the display
initialization fails, fallback to software rendering.
The error was reported in #10123 and it can be reproduced with:
$ MESA_LOADER_DRIVER_OVERRIDE=zink eglinfo
`eglinfo` would crash in `dri2_display_release()` because of
`assert(dri2_dpy->ref_count > 0)`.
After bisecting the error to commit 8cd44b8843 ("egl/glx: add
autoloading for zink"), I found out that, before this change, the
display was set to initialized even when `_eglDriver.Initialize(disp)`
failed:
disp->Options.Zink = env && !strcmp(env, "zink");
// disp->Options.Zink is true
if (!_eglDriver.Initialize(disp)) {
[...]
// Zink initialization has failed at this point
// However, success is set to true:
bool success = disp->Options.Zink;
if (!disp->Options.Zink && !getenv("GALLIUM_DRIVER")) {
[...]
}
// Software initialization is ignored because success is true
if (!success) {
[...]
}
}
// The display is set as initialized even though it shouldn't
disp->Initialized = EGL_TRUE;
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10123
Fixes: 8cd44b8843 ("egl/glx: add autoloading for zink")
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26184>
(cherry picked from commit d913927fe9)
