The OFFSET_LO in #instruction-cat6-a6xx-ibo-load-store aliased with
opcode of other instructions, resolve this by being less lax in some
instruction definitions.
A proper way to solve this would probably be to reconstruct instructions
hierarchy, but it's a much more complex task.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30018>
With LLVM-19, Module.h header is not being pulled, which results in
compile errors e.g.
src/amd/llvm/ac_llvm_helper.cpp:102:10: error: no matching function for call to ‘unwrap(LLVMOpaqueModule*&)’
102 | unwrap(module)->setTargetTriple(TM->getTargetTriple().getTriple());
| ~~~~~~^~~~~~~~
In file included from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/IR/Type.h:18,
from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/IR/DerivedTypes.h:23,
from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/IR/InstrTypes.h:26,
from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/Analysis/TargetLibraryInfo.h:14,
from ../mesa-24.0.7/src/amd/llvm/ac_llvm_helper.cpp:8:
Its getting the definition from llvm/IR/Type.h instead of Module.h and caused
confusion to compiler
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11424
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29993>
This is mainly to reject buffers allocated with modifiers not supported
for given entrypoint. There is no interface to query supported modifiers
for different formats and entrypoints in libva, so applications can
import externally allocated buffers that may be unsupported with some
entrypoints.
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29932>
Currently EFC would be used for every RGB->NV12 conversion, even if the
target surface wasn't going to be used as encode input. Also another
issue is that there may be multiple conversions from the same source
surface before the encode operation (this is the case with B-frames
when using one source surface).
EFC is now used only if the postproc conversion is the last postproc
operation immediately before encoding.
Until it's been observed that this is the case, the shader conversion is
also applied as a fallback in case EFC could not be used.
Tested with (fixes EFC + H264 with B-frames on radeonsi):
ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc \
-vf hwupload,scale_vaapi=format=nv12 -c:v h264_vaapi -bf 3 \
-vframes 200 out.mp4
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29932>
MI_REPORT_PERF_COUNT reports all 64 PEC counters, so there is no
need to read individual registers.
Also the individual registers reads privileged and UMDs can't access
it, causing it to always read as always zero and overwritting valid
data read with MI_REPORT_PERF_COUNT.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29529>
In tu_get_image_format_properties(), image usage flags are matched against
sets of required format feature flags for the specified image format.
These mappings are defined in the Vulkan 1.3 spec in section 49.3.3.,
"Format Feature Dependent Usage Flags".
Handling for the VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT flag was missing. When
specified, at least one of color attachment or depth-stencil attachment
format feature flags should be present for the given format.
Fixes 110 new Vulkan CTS tests:
- dEQP-VK.api.info.unsupported_image_usage.linear.*
- dEQP-VK.api.info.unsupported_image_usage.optimal.*
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30013>
While Raspberry PI OS 64-bit is the suggested version for rpi3 devices
and newers, for older devices like rpi1 to rpi2, which uses the same
GPU, the recommended flavour is 32-bit.
Also, while 64-bit is the recommended version, users can still decide to
use the 32-bit flavour.
Hence, spend a bit of nightly time to run a subset of the OpenGL/ES
tests.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30003>
Add basic KHR_8bit_storage support for Adreno 750 devices, for now enabling
the storageBuffer8BitAccess feature. A separate descriptor is provided for
8-bit storage access. The descriptor index is adjusted appropriately for
8-bit SSBO loads and stores.
The 8-bit SSBO loads cannot go through isam since that instruction isn't
able to handle those. The ldib and stib instruction encodings are a bit
peculiar but they match the blob's image buffer access through VK_FORMAT_R8
and the dedicated descriptor. These loads and stores do not work in
vectorized form, so they have to be scalarized. Additionally stores of
8-bit values have to clear up higher bits of those values.
8-bit truncation can leave higher bits as undefined. Zero-extension of
8-bit values has to use masking since the corresponding cov instruction
doesn't function as intended. 8-bit sign extension through cov from a
non-shared to a shared register also doesn't work, so an exception is
applied to avoid it.
Conversion of 8-bit values to and from floating-point values also doesn't
work with a straightforward cov instruction, instead the conversion has
to go through a 16-bit value.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9979
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254>
ir3's TYPE_S8 isn't actually a signed 8-bit type in a half-register, it's
in fact an unsigned 8-bit type in a full register. Only actual uses of
TYPE_S8 are in conversion operations, but those can be trivially replaced
with TYPE_U8, either truncating down to 8 bits or zero-extending or
sign-extending from 8 bits upward.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254>
