Likely a game bug but can't be 100% sure because the game uses RT by
default and renderdoc still doesn't have support for it.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32528>
Not every implementation supports VK_EXT_debug_marker.
VK_EXT_debug_utils is also pretty similar, it would be nice to plug
into whatever is available.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32483>
"constant" is a special keyword in OpenCL C, and we'd like to #define it
suitably in host C23 to facilitate compatiblity between host/device headers.
That means we can't have any identifiers named "global" or "constant".
Fortunately, this is the only 'constant' in any file I'm hitting.
To avoid the clash, don't abbreviate "constant factor", use "constant_factor"
instead. For consistency, "slope factor" then becomes "slope_factor".
The new names are longer but match the Vulkan API exactly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> [Intel]
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> [NVK and panvk]
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [V3DV]
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com> [IMG]
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32505>
The pass that lowers PS outputs has been rewritten since 45d8cd037a
("ac/nir: rewrite ac_nir_lower_ps epilog to fix dual src blending
with mono PS") to handle invalid uses of dual-source blending.
This drirc used to workaround game bugs on GFX11 only should no longer
be necessary.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32514>
VRS rates should only be preserved for clears, otherwise the HTILE
buffer should be cleared completely.
This fixes some failures/flakes in CI.
Fixes: 8197d744f5 ("radv: Do not overwrite VRS rates when doing fast clears")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32463>
They are a maintainenance burden since they would need changes to
support more instruction types that nir_opt_varyings will be able to
move between shaders, and they are almost identical to
default_varying_estimate_instr_cost, so just use that.
The cost threshold is adjusted for AMD because
default_varying_estimate_instr_cost is slightly different.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
This was broken for two reasons:
- the number of bytes per element should be 1 (8-bit for stencil)
- the base offset should be adjusted for the stencil
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32459>
The bitstreamStartOffset from the VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR query in RADV is currently relative to the dstBuffer, and not dstBuffer + dstBufferOffset like the spec states.
To fix this, let's append the offset to the VA directly and not tell the encoder about the offset relative to the VA at all.
The Vulkan spec states:
"VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_BUFFER_OFFSET_BIT_KHR specifies that queries managed by the pool will capture the byte offset of the bitstream data written by the video encode operation to the bitstream buffer specified in VkVideoEncodeInfoKHR::dstBuffer relative to the offset specified in VkVideoEncodeInfoKHR::dstBufferOffset."
The relevant part being that is is relative to dstBufferOffset and not the start of the VkBuffer.
Signed-off-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32452>
GFX6-7 can't support Vulkan 1.4 because indexTypeUint8 isn't supported
in hardware, and emulating features for very old hardware isn't the
option I would personally choose.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32432>
This performs some very basic verifications with the faulty VA we get
from the kernel. This will probably be improved over time.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32403>
The Vulkan headers add typedefs to fix aliasing issues whenever a type
gets renamed. However, C doesn't allow "enum typedef" so this doesn't
work if people stick the "enum" keyword in front.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32433>
This is mostly adapted from radv's BVH building. This defines a common
"IR" for BVH trees, two algorithms for constructing it, and a callback
that the driver implements for encoding. The framework takes care of
parallelizing the different passes, so the driver just has to split the
encoding process into "stages" and implement just one part for each
stage.
The runtime changes are:
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
The radv changes are;
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
This is mostly adapted from radv's BVH building. This defines a common
"IR" for BVH trees, two algorithms for constructing it, and a callback
that the driver implements for encoding. The framework takes care of
parallelizing the different passes, so the driver just has to split the
encoding process into "stages" and implement just one part for each
stage.
The runtime changes are:
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
The radv changes are;
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
Use box with largest ray interval for shadow rays (terminate on first
hit) as it maximizes the probability of finding some object in that box;
for reflection (closest hit) rays, use midpoint instead, which defers
processing of larger boxes the ray origin is in in favor of smaller
boxes closer to origin.
Since the sorting mode must be uniform, when terminate_on_first_hit flag
is divergent, we leave it as closest.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32416>
Prior to VCN4, the encode queue is separate from the decode queue. For
encode, the WRITE_MEMORY command can be executed with similar framing as
for VCN4, but notably there is no signature support, so it must be
skipped.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32400>
The previous code not only left them undefined, but also
didn't increment the array index, so subsequent PS inputs
would be broken after the undefined one.
Note that this doesn't affect any valid Vulkan apps, but it makes
the code a bit simpler and it makes undefined inputs a little more
forgiving, at no expense for valid PS.
This code actually uncovers a bug in Zink, so I'm also documenting
the failing Zink test case.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32220>
