It uses a poll function that waits for a second hoping for another thread
to catch up, which is not a reliable way to do synchronization. The test
has been spuriously failing merges on a regular basis recently.
This is issue #9222, which I'm leaving open until the author can fix the test.
Fixes: 3b69b67545 ("util/fossilize_db: add runtime RO foz db loading via FOZ_DBS_DYNAMIC_LIST")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24755>
Without this, gallivm doesn't know what to do with the result data of a
texture fetch. We have a bunch of gallivm code to handle these but, as
far as I can tell, none of it works properly without channel types. The
YUYV texturing helpers all consume a 32-bit packed value, unpack it,
shuffle things as needed, and then re-pack into a 32-bit RGBA value,
trusting later code to unpack that as 8-bit UNORM. For the raw formats,
this unpacking never happens.
What saves us is that I also don't think any of this code is ever used.
LLVMpipe supports the actual YUYV formats and we don't use the gallium
lowering pass which lowers to the raw formats.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
Both EGL and Vulkan implementations require obtaining buffer metadata,
e.g., format, modifier, offsets, strides, etc.
Currently, mesa3d doesn't have a generic solution, and every Vulkan
implementation uses its getters. Most of the getters rely on
kernel metadata storage that is available for x86-based GPU drivers.
ARM-based Vulkan drivers rely on userspace metadata sharing, making it
important to use advanced metadata API. Otherwise, the driver will work
with limited functionality (no YUV, lack of support for modifiers, etc.)
Current EGL buffer getter implementation is advanced enough and used as
a base for a common Android buffer-getter logic.
Use example:
void
android_buffer_test(android_handle_type *a_handle)
{
// First, get the gralloc object. It will be created if it doesn't
// exist. Use U_GRALLOC_TYPE_AUTO to let the implementation choose
// the best gralloc
struct u_gralloc *gralloc = u_gralloc_create(U_GRALLOC_TYPE_AUTO);
// Prepare the internal handle structure (hal_format and
// pixel_stride are required for the fallback implementation).
// Both Vulkan and EGL clients expose HAL format / pixel stride
// in their structures.
u_gralloc_buffer_handle hnd = {
.handle = a_handle->native_handle,
.hal_format = a_handle->hal_format,
.pixel_stride = a_handle->pixel_stride,
};
// Get the basic buffer info
u_gralloc_buffer_basic_info basic_info;
int ret = u_gralloc_get_buffer_basic_info(gralloc, &hnd, &basic_info);
if (ret) {
// Handle the error
}
// Get the color info
u_gralloc_buffer_color_info color_info;
ret = u_gralloc_get_buffer_color_info(gralloc, &hnd, &color_info);
if (ret) {
// Handle the error
}
// unref the gralloc object
u_gralloc_destroy(&gralloc);
}
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18215>
When NV21 lowering with hardware sampling and shader CSC was added, the
incorrect PIPE_FORMAT_G8_B8R8_UNORM was used. That format is supposed to
represent vulkan NV12 instead.
This commit introduces PIPE_FORMAT_R8_B8G8_UNORM, which correctly describes the
gallium mapping for YUV CSC, with R as Y, instead of G as Y.
Fixes: 26e3be513d ("gallium/st: add support for PIPE_FORMAT_NV21 and PIPE_FORMAT_G8_B8R8_420")
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24266>
This new format is similar to PIPE_FORMAT_G8_B8_R8_420, but with R as Y, G as U
and B as V. The need for two diferent formats here is because gallium maps the
YUV channels differently from vulkan.
Some hardware, e.g. Mali GPUs, can sample from I420 but need CSC in shader,
this patch implements that.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24266>
Some DX12 games require sparse resource support but don't
actually use sparse resources. Add a way to make these games work
while we still don't have sparse resources fully working on every
KMD backend.
When fake_sparse=true, anv advertises sparse resource support
despite lacking full support.
Based-on-patch-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24046>
ARM64EC is a new build target for Windows ARM64 devices for x64 support.
Currently that build flavor fails due to attempting to use x64 intrinsics.
This commit fixes it by changing the auto-detection to be aarch64
instead of x64 for arm64ec.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24119>
util_clear_texture implements clear_texture through a memset.
This patch implements u_default_clear_texture, which tries to clear the
given texture using a surface plus clear_render_target or
clear_depth_stencil.
In case this path fails, either because the formats are non-renderable
or for some other reason, we fallback to `util_clear_texture`, which is
guaranteed to work.
This will allow us to make ARB_clear_texture available to every driver,
as well as provide HW acceleration for the clear_texture operation.
If some hardware doesn't want to use it, such as llvmpipe, it can always
just directly point to the software version using pipe->clear_texture.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23735>
