We were using a stale FAU buffer which meant we wrote to garbage addresses. I'm
guessing this was fallout from the big sysval rework but not 100% sure.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24199>
(cherry picked from commit c282f80c98)
iris needs to emit a PIPE_CONTROL_INSTRUCTION_INVALIDATE for the
aforementioned WA.
Fixes: 83716b08c ('iris: migrate WA 14013910100 to use the WA framework')
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24171>
(cherry picked from commit 07a9585898)
DIV_ROUND_UP is the correct replacement for ALIGN_TO.
Fixes: ba83c1e2
Signed-off-by: David Rosca <nowrep@gmail.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24127>
(cherry picked from commit d408ae88db)
Port of code from iris.
Original author: Nanley Chery
Helps with fast_color_clear@fcc-write-after-clear
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24135>
(cherry picked from commit 6e87b277bd)
This was missed in 0bf6dcb785
There is a loop which iterates over a temp array. NIR optimization
moves the real work out of the loop and what remains are just ALU ops
with undefs. So after converting undefs to zero, the ALU ops are
optimized out and DCE kills the loop. This is a good thing in
general and we don't fail the linking due to the loop presence.
However than we hit the shader constants and ALU limits later :-(
So from dEQP POW we go from NotSupported to Fail.
Fixes: 0bf6dcb785
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24134>
(cherry picked from commit 0a2a7bfd19)
Convert it to an opt-in for backends to prefer and use nir_load_texture_scale
instead of txs for nir lowerings.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Suggested-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24054>
Ben prefers that we use the firmware method where possible.
Cc: mesa-stable
Signed-off-by: Karol Herbst <git@karolherbst.de>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23802>
This is a bit hacky, but it does the right thing and counts the number
of textures instructions so the linear path can work for multiple textures.
Reviewed-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24066>
Before adding new copies of all of these for swapping start by
refactoring into macro templated code.
I avoided using inline functions because I want to test with
opts turned down, and this will kill perf.
Reviewed-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24066>
This is pretty straightforward, since we don't try to "coalesce" register access
the way a GPU backend would. In the old path, we generated register load/store
instructions internally when hitting register sources/destinations. In the new
path, we just translate the register load/store intrinsics to the LLVM
loads/stores and we're back where we started. It's a bit more code, but it's
more straightforward.
Notably, although this continues to use registers, this does NOT use the chasing
helpers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23089>
It doesn't do anything yet. We leave that to the subsequent patches so we can
keep the tree-wide refactor as simple as possible.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23089>
This has been broken for a while, but we weren't hitting the linear paths in CI
This fixes:
tests/spec/arb_enhanced_layouts/execution/component-layout/fs-output.shader_test.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24083>
Since the mesa state tracker can promote RGB texture formats
to RGBA texture formats (among other formats) without exposing
any of that information to a driver, it is more desirable to
have the behaviour of `PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND`
be the default. This avoids rendering bugs where an application
sets `DST_ALPHA` blending on a format where there is no alpha
channel, that has been promoted to a format that actually has an
alpha channel. The driver can instead rely on the common code
in the state tracker to convert the blending parameter to one
that reflects the limitations of the application requested format,
as long as `PIPE_CAP_INDEP_BLEND_FUNC` is supported.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24044>
When the vertex shader switches from hw GS to hw HS and vice versa, we need
to re-emit all draw user SGPRs.
Fixes: 1753b321f8 - radeonsi/gfx11: use SET_SH_REG_PAIRS_PACKED for gfx by buffering reg writes
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24087>
If there is a FS input but no VS output the behavior is undefined
but okay. Use a register 0 (position) for such cases.
glsl-routing test triggers it with e.g. the following subtest.
Test: VS(C0 -- T0 -- T2 -- T4 T5)
FS(C0 C1 T0 T1 T2 T3 T4 T5)
This will now end with following linker debug output:
link result:
vs -> fs comps use pa_attr
t1 -> t1 xyzw 0,0,0,0 0x000002f1
t2 -> t2 xyzw 0,0,0,0 0x000002f1
t0 -> t3 xyzw 0,0,0,0 0x000002f1
t3 -> t4 xyzw 0,0,0,0 0x000002f1
t0 -> t5 xyzw 0,0,0,0 0x000002f1
t4 -> t6 xyzw 0,0,0,0 0x000002f1
t5 -> t7 xyzw 0,0,0,0 0x000002f1
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24030>
The PRI* macros don't include the required introductory % character
Fixes: d29bb6467e ("aux/trace: use stdint.h types")
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24057>
Very likely a typo. Afaict radv/anv don't support this.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24078>
An out-of-bounds access has occurred to array ref[2] and it needs
to be fixed.
Fixes: 6b5aecb195 ("virgl: add support for hardware video acceleration")
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23160>
submit_count is used to disambiguate a batch_id based on the generation
id of a given batch: this value is incremented once on submit and once on
reset such that the diff of the values is > 1 any time the batch does not
represent the fence it was last submitted with
in the case of a batch's first use, however, this value was being incorrectly
incremented such that the first submit would cause disambiguation checks
to erroneously determine that the batch had already completed, breaking synchronization
fixes#9313
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24016>
Pretty much all the profiles references Vulkan 1.2 or 1.3 only
structures but only say they need a 1.0.X version.
This fails parsing of the Vulkan Profile scripts for generating
implementation checks against a particular profile.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24072>
The types of both 'encrypted' and 'picture->protected_playback'
are bool, so there is no need. I guess this is a typo.
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23202>
pipe_picture_desc.decrypt_key was alloced in function
handleVAProtectedSliceDataBufferType(), but nowhere to
free it. Now, it will be freed as the vlVaContext is
destroyed.
Fixes: deb7dc82f6 ("frontends/va: handle protected slice data buffer")
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23202>
From Bspec 46959, a programming note applicable to Gfx12+:
"Since HZ_OP has to be sent twice (first time set the clear/resolve
state and 2nd time to clear the state), and HW internally flushes the
depth cache on HZ_OP, there is no need to explicitly send a Depth
Cache flush after Clear or Resolve."
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24027>
