As it could happens that when a bo is reused from the cache, it is
being mapped with a smaller size that needed. So let's just unmap it,
and let be remapped with the needed size.
Even if we could try to be smarter when deciding when to unmap or not,
to avoid uneeded re-mappings later, it is also true that doing the
unmap would help to reduce the memory used.
This fixes an assert when running the following tests in a row (same
deqp-vk execution):
dEQP-VK.pipeline.creation_feedback.graphics_tests.vertex_stage_fragment_stage
dEQP-VK.pipeline.executable_properties.graphics.vertex_stage_geometry_stage_fragment_stage
dEQP-VK.pipeline.executable_properties.graphics.vertex_stage_fragment_stage_internal_representations
That hits the following assertion:
assert(qpu_bo && qpu_bo->map_size >= variant->assembly_offset +
variant->qpu_insts_size);
at v3dv_pipeline.c, pipeline_get_qpu.
v2: use just one call to v3dv_bo_unmap (move call at v3dv_bo_free,
replace call at bo_free for assert) (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16678>
Originally, we had virtual opcodes for scratch access, and let the
generator count spills/fills separately from other sends. Later, we
started using the generic SHADER_OPCODE_SEND for spills/fills on some
generations of hardware, and simply detected stateless messages there.
But then we started using stateless messages for other things:
- anv uses stateless messages for the buffer device address feature.
- nir_opt_large_constants generates stateless messages.
- XeHP curbe setup can generate stateless messages.
So counting stateless messages is not accurate. Instead, we move the
spill/fill accounting to the register allocator, as it generates such
things, as well as the load/store_scratch intrinsic handling, as those
are basically spill/fills, just at a higher level.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16691>
When vulkan enables depth bias, enable it for all 3 prim types
in gallium.
This fixes:
dEQP-VK.draw.renderpass.depth_bias.depth_bias_*
and
one zink test in CI
Cc: mesa-stable
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16701>
if the program changes, assume the hashes changed
this could probably be improved in the future to check for matching shader
interfaces, but that's a problem for later
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16645>
this allows indirection for internal descriptor type -> vk descriptor set
and enables more easily altering the descriptor set index at runtime
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16645>
cts fix landed in vulkan-cts-1.2.5 while mesa CI has bumped once.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Tested-by: Mark Janes <markjanes@swizzler.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16694>
If we saw a HALT instruction, we would forget to invalidate our analysis
pass information before returning progress.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16677>
Unify the "create regular resource" and "create scanout resource" code paths.
They only differ in how the backing memory is allocated. This unifies the layout
code as well, avoiding hacks for AFBC.
What I really care about is that, if we're creating the resource, we choose the
layout first with pan_image_layout_init and allocate that layout.
pan_image_layout_init is a common, extensively tested (including unit tested)
helper written for correctness with a deep understanding of the hardware.
By contrast, we currently guess the layout with some hacks specific to AFBC,
allocate our guess, and then then tell pan_image_layout_init to use the layout
we guessed and pray everything works out. (It does work out, but it's all kinds
of wrong, in terms of layering violation. If that really is the way to go, I can
add the required routines to the layout code. But that doesn't seem right.)
All of this is motivated by extending the layout code to handle AFBC with other
superblock sizes or tiled headers without having to pile on extra hacks in this
WSI path.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16334>
It's meaningful for this intrinsic and so does not add noise to the
lowering pass.
(Although dual-source writes must be to RT 0, depth and stencil
writes, which store_combined_output_pan is also used for, can still be
done with MRT enabled.)
Fixes: 5c168f09eb ("nir: Eliminate store_combined_output_pan BASE")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16685>
Rename radv_emit_global_shader_pointers to radv_emit_graphics_shader_pointers
and don't call it on compute queues. Note that the registers
that this function sets, are not available on the async compute
queue anyway.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16395>
In the future we'll need a 1:N mapping between radv_queue objects and
HW queues, meaning that 1 radv_queue object will need to be able to
submit to multiple queues. To do that, we'll must also maintain a different
state for each HW queue.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16395>
This will be needed for a future refactor of these functions
where we won't pass radv_queue to them anymore.
Also remove the radv_queue pointer from functions which
don't actually need it.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16395>
This is to prevent excessive code repetition, and hopefully make the
code a bit easier to read.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16395>
Put the shader ring information into a separate structure.
Also clean up how this information is used when generating the preambles
and add a few comments that explain how it works.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16395>
The game Batman: Arkham Knight expects OpenGL behavior
with sample mask and multisampling which is different
from the Vulkan one.
This workaround fix changes key->ignore_sample_mask_out
value that is used for
prog_data->uses_omask definition in brv_fs.cpp(9740)
In that way prog_data->uses_omask also changes it value
and the cloak stops flickering.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6078
Signed-off-by: Viktoriia Palianytsia <v.palianytsia@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16551>
Task shaders work like compute shaders, their scratch pointer
is currently located at the first two user SGPRs.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16692>
Probably a wrong rebase. Also add Vangogh.
Fixes: 72910242a6 ("radv/ci: Skip slow/crashing ray tracing tests")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16690>
This is a copy of the sienna_cichlid ones and
only useful for running vk-cts-image on navi22
cards.
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16007>
Ray queries and acceleration structure builds
are quite stable now and so we can enable those
features for CI and more feedback and bug reports.
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16007>
In preparation to enable ray queries by default.
This is also useful for testing ray tracing
pipeline changes with vk-cts-image.
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16007>