When copying multiple regions that have the same image subresource we are
effectively copying various rects across the same layer range, so we can
batch together all the rects to copy for each layer in a single job.
This allows us to significantly reduce CPU overhead when recording the
command, as we need to produce less jobs and allocate less descriptor
sets. It also offers smaller gains in execution time due to the reduced
job count.
A stress test where we copy 10 subrects of an image in a loop 100 time,
choosing regions that will involve the texel buffer path, we get these
results:
| Recording Time | Execution Time |
----------|----------------|----------------|
master | 3.021s | 0.112s |
----------|----------------|----------------|
patch | 0.163s | 0.080s |
----------|----------------|----------------|
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7782>
This increases performance for indexed triangle strips up to +100%.
In practice, it's limited by memory bandwidth and compute power,
so 256-bit memory bus and a lot of CUs are recommended.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7681>
This workaround fixes a hang while loading a renderdoc trace for me.
Since the workload does 1 mip per cmdbuffer it is quite hard to confirm
what exactly the conditions for the hang are but this is the most
restrictive set I found and it corresponds to a workaround in AMDVLK as
well.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7210>
We forgot to document this previously, so let's add it now.
Fixes: feb9462bb1 ("zink: Added inbuilt debug logging from the VK_LAYER_LUNARG_standard_validation layer.")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7802>
Make it consistent with nir_intrinsics.py, the unlabelled indices just
before it and the intrinsic builders.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6587>
If bit_size_src is not -1, then it's the index of the source the
destination bit size can be expected to match. This will be useful for
generating intrinsic builders
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6587>
NIR can't CSE the read_first_invocation intrinsics, so we can end up
creating iand(read_first_invocation(a) == a, read_first_invocation(a) == a)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3813>
Quoting the spec :
"When a pool is destroyed, all descriptor sets allocated from the
pool are implicitly freed and become invalid. Descriptor sets
allocated from a given pool do not need to be freed before
destroying that descriptor pool."
This implies we might leak nodes allocated in the vma object.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0a6d2593b8 ("anv: Allocate descriptor buffers from the BO cache")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7796>
It fixes the following valgrind issue:
==141996== Invalid read of size 4
==141996== at 0x61F8806: gl_nir_link_uniforms (gl_nir_link_uniforms.c:1788)
==141996== by 0x60F17AA: gl_nir_link_glsl (gl_nir_linker.c:672)
==141996== by 0x5C1AEDF: st_link_nir (st_glsl_to_nir.cpp:739)
==141996== by 0x5C15574: st_link_shader (st_glsl_to_ir.cpp:172)
==141996== by 0x5C673B0: _mesa_glsl_link_shader (ir_to_mesa.cpp:3117)
==141996== by 0x5E7B61C: link_program (shaderapi.c:1311)
==141996== by 0x5E7B61C: link_program_error (shaderapi.c:1419)
==141996== by 0x5E7CF8A: _mesa_LinkProgram (shaderapi.c:1911)
==141996== by 0x4923D13: stub_glLinkProgram (piglit-dispatch-gen.c:33956)
==141996== by 0x1142C0: link_and_use_shaders (shader_runner.c:1636)
==141996== by 0x1205A6: init_test (shader_runner.c:5347)
==141996== by 0x121555: piglit_init (shader_runner.c:5725)
==141996== by 0x4991C84: run_test (piglit_fbo_framework.c:50)
It can be reproduced on `iris` using the following piglit test:
instance-matching-shader-storage-blocks-align-qualifier-mismatch.shader_test
Closes: #3818
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 47c35823 ("glsl: fix up location setting for variables pointing to a UBO's base")
Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7376>
This patch fixes these SCons build errors.
/usr/bin/ld: build/linux-x86_64-debug/gallium/auxiliary/libgallium.a(lp_bld_misc.os): in function `llvm::InitializeNativeTarget()':
llvm/Support/TargetSelect.h:118: undefined reference to `LLVMInitializeX86TargetInfo'
/usr/bin/ld: llvm/Support/TargetSelect.h:119: undefined reference to `LLVMInitializeX86Target'
/usr/bin/ld: llvm/Support/TargetSelect.h:120: undefined reference to `LLVMInitializeX86TargetMC'
/usr/bin/ld: build/linux-x86_64-debug/gallium/auxiliary/libgallium.a(lp_bld_misc.os): in function `llvm::InitializeNativeTargetAsmPrinter()':
llvm/Support/TargetSelect.h:132: undefined reference to `LLVMInitializeX86AsmPrinter'
/usr/bin/ld: build/linux-x86_64-debug/gallium/auxiliary/libgallium.a(lp_bld_misc.os): in function `llvm::InitializeNativeTargetDisassembler()':
llvm/Support/TargetSelect.h:156: undefined reference to `LLVMInitializeX86Disassembler'
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7722>
It's expected to be 0.
Fixes: 62d9ca696e ("radv: use 32-bit predication for conditional rendering on GFX10.3+")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7789>
We have been implementing some features without updating the file, and
we even had some that were supported for a while.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
v2: include VK_KHR_wayland_surface as !7303 got merged
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7758>
with a sequence like this:
glClear(STENCIL)
glBeginTransformFeedback()
...
glEndTransformFeedback()
glClear(STENCIL)
The second clear sometimes may produce an unexpected result.
Calling si_flush_gfx_cs() when doing ngg -> legacy transition seems to be a
valid workaround (both for the synthetic reproducer and the real Blender bug).
Using flush flags or events (BOTTOM_OF_PIPE_TS, RESET_TO_LOWEST_VGT) didn't help.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2941
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7750>
cnd_t operates on REALTIME clock, and isn't suitable for MONOTONIC use.
Clone the API, and implement using a monotonic clock.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7138>
Avoid small possibility of reading torn write on 32-bit platforms.
If frequency caching is desired, it's probably better to initialize from
C++ and extern "C" instead. It's not a tremendous optimization though.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7138>
When the VAAPI deinterlacing filter is chained with other VAAPI
post-processing filters, the image might get deinterlaced multiple
times, as the filters after the deinterlacing filter might still see an
interlaced buffer.
Signed-off-by: Thong Thai <thong.thai@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6803>
Updates the height of the blitting parameter to use the actual image
height instead of the buffer height, otherwise when scaling, garbage
lines are shown in the output.
Signed-off-by: Thong Thai <thong.thai@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6803>
The code works but is a bit fragile if we ever add a case that has a
less strict requirement (a smaller gen) than the case above. To avoid
having to reason about this, refactor code to use a variable to
indicate whether the SFID is supported or not.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7742>
Z32_S8X24 variants are actually stored in 2 planes (one per component),
we have to adjust the bytes_per_pixel value accordingly.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7653>
So we don't have to calculate it again when we create a texture or
framebuffer descriptor.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7653>
The expected stride calculation does not take the block width into
account, thus creating an expected line stride that's bigger than
required. Fix that by dividing the width by the block width.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7653>
So we can use it from pan_resource.c to retrieve the tile size based on
a modifier.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7653>
If we don't do that we end up with DATA_INVALID faults when accessing
3D textures on Bifrost.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7653>
