To query if a DRI_IMAGE has separate plane buffer handle.
radeonsi's DCC compressed dri image has multiple planes
(compressed data and metadata). But they share the same
buffer with different offsets, so we only need one buffer
handle for them.
This attribute is used to distinguish single buffer multi
plane image from multi buffer multi plane image.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31658>
refcounting uses atomics, which are a significant source of CPU overhead
in many applications. by adding a method to inform the driver that
the frontend has released ownership of a buffer, all other refcounting
for the buffer can be eliminated
see MR for more details
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296>
This affects piglit/bin/ext_texture_array-compressed teximage pbo -auto -fbo
Routine create_surface() at src/gallium/drivers/crocus/crocus_state.c
does not suppport compressed format and returns NULL in that case.
Since MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34054
routine st_try_pbo_compressed_texsubimage() at src/mesa/state_tracker/st_cb_texture.c is missing a test via pipe->create_surface() and does
not fallback to _mesa_store_compressed_texsubimage() which causes a SIGSEGV abort.
Regression is solved by introducing the variable surface_no_compress at struct pipe_caps, causing the fallback.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13426
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37150>
This implements support for Decode processing allowing to perform
processing operation on the decoded picture in one single call without
having to use separate processing context.
This also implements the same functionality for encoding, which is
useful to perform conversion from RGB to YUV in a single call, and it
allows us to properly support the conversion inside encoder (eg. EFC on
AMD).
For Encode processing the additional output buffer is required same as
with Decode processing, but driver may not use it to perform the
conversion (in case where the conversion can be done by the encoder hw).
This means the contents of the additional buffer is undefined, and
application should not rely on the buffer actually containing output
picture of the conversion.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36755>
In some cases a format may be supported in a more limited way by the
hardware. For example, formats with NPoT pixel sizes. A driver might
normally prefer that mesa/st use R8G8B8X8 rather than R8G8B8. But if
the user wants to (dma-buf/etc) import R8G8B8, it is still possible,
and in this case zero copy is more important.
So add a PIPE_BIND_x flag as a hint to the driver when checking if
a format is supported.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35982>
using a screen method for this is broken since the value can change
before it is flushed. it must be passed along with the methods that use it
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35866>
functionally this is the same as other types of timeline semaphores, but
it is not actually the same as other types of timeline semaphores, e.g.,
in vulkan it would be VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT
whereas other types of timeline semaphores would have different handle types
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35866>
At the moment, the string passed to glObjectLabel() stays only within the
confines of GL objects. It would be nice if that textual description could
be made known to the underlying drivers somehow.
Expand the pipe screen function interface to allow passing GL object labels
down to the UM driver that handles a particular pipe screen.
Not all GL objects have an associated GL resources, so this behaviour has
been implemented for those which are associated with at least one.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34224>
More driver boilerplate we don't need. We do still have to go through the
transformation in st_atom_clip.c because the clip state can get used in
draw fallbacks. This revealed that lima had a dirty bit being set that
nobody was reading.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8953>
The old interfaces added back in clover's time were modeled after a very
bindful resource model.
However SVM (shared virtual memory) requires us to be way more flexible.
The new interfaces allow frontends to create a cut-out in the GPU's vm and
to assign addresses themselves. This gives us the following benefits:
- The frontend is empowered to synchronize resource addresses between
several devices. cl_mem objects in OpenCL span across a set of multiple
devices and SVM requires them to have the same VMA across all of them.
- Coarse grain SVM can be implemented without bothering drivers too much
as the frontend can be responsible to make sure a host allocation with
a specific VMA matches a GPU allocation with the identical VMA.
- Support for Global variables in the CrossWorkgroup storage class
Initializers. Those can depend on addresses of CrossWorkgroup memory,
if the frontend can just assign a VMA, this address can be passed as a
constant to spirv_to_nir and folded without the need to support
spilling of constant initializers.
Drivers not able to give us a vm-cutout are left with implementing
cl_ext_buffer_device_address instead.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942>
cl_ext_buffer_device_address requires us to set a fixed address for a
given memory allocation. As this extension is intended to be implemented
on top of vulkan we have to take its limitations into account.
For SVM we'll add proper VM management interfaces, but zink won't be able
to implement those, so here we are.
The old interfaces added back in clover's time were modeled after a very
bindful resource model and the frontend was require to bind all the used
resources ahead of launch_grid.
cl_ext_buffer_device_address and also SVM however will require us to
dynamically attach a list of buffers used in a dispatch with known
addresses, hence set_global_binding isn't really suited for those use
cases.
So PIPE_RESOURCE_FLAG_FIXED_ADDRESS is added to tell a driver that the
address of a resource needs to stay the same over its lifetime, which then
can be queried via pipe_screen::resource_get_address.
All such buffers then can be either bound via set_global_binding or passed
in via pipe_grid_info::globals.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942>
