On the host side virglrenderer creates dmabuf on demand when:
* cpu mapping is requested
* setting up scan out
* sharing buffers between guest processes
On-demand dmabuf creation only works if the ctx that created the
BO still exists and knows about this BO. This assumption works ok for
the first 2 cases, but can break with the last one (and it does cause
issues on Android). eg:
* process A allocates BO and exports it as a guest dmabuf
* process A closes its handle to the BO (-> detach_resource)
* process B imports the guest dmabuf -> this triggers the attach_resource
function in virglrenderer. If the given resource isn't a
VIRGL_RESOURCE_FD_DMABUF it'll try to get one... But for this to work,
process A needs to be used -> this fails because this resource was
detached from it.
The reason we create dmabuf on demand is to avoid hitting the number of
open file descriptor limit. So to cover the 3rd case, we'll use the
VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag, but try to limit to as few possible
buffers as possible.
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
The virtio-gpu guest kmd reports timelines as supported, so querying
DRM_CAP_SYNCOBJ_TIMELINE as vk_drm_syncobj_get_type() does will return
true.
The native context code on the other hand doesn't support timelines,
and support is disabled in the "ac/virtio: disable timeline_syncobj support"
commit.
Fix the inconsistency by manually disabling timeline support when
info.has_timeline_syncobj is false.
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
No big code changes are needed to support virtio. The main caveat with
radv is about buffer allocations.
Allocating a cpu visible buffer requires the host process (eg qemu) to
create a dmabuf, mmap it, then map the host CPU address into the guest
application CPU address space.
The first issue is about the number of dmabuf created because we
might hit the number of open file limit. The host process limit can
be raised but we would hit the second issue - at least on qemu:
there's a limit on how many sections can be mapped and ultimately
we hit this assert:
assert(map->sections_nb < TARGET_PAGE_SIZE);
(the third issue is a performance one: these operations have a cost,
and this increases some Vulkan app loading times)
radeonsi is not really affected because it's using pb_slab to
suballocate small buffers from larger ones.
radv on the other hand doesn't, so if an app decides to allocate
lots of cpu visible small buffers, we're likely to fail.
Earlier versions of the amdgpu nctx code had a suballoctor, but it
was removed to simplified the code. It could be restored later; or
radv could be modified to use a suballocator (like anv does AFAICT).
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
Native context support is implemented by diverting the libdrm_amdgpu functions
into new functions that use virtio-gpu.
VA allocations are done directly in the guest, using newly exposed libdrm_amdgpu
helpers (retrieved through dlopen/dlsym).
Guest <-> Host roundtrips can be expensive so we try to avoid them as much as
possible. When possible we also don't wait for the host reply in case where
it's not needed to get correct result.
Implicit sync works because virtio-gpu commands are submitted in order to the
host (there a single queue per device, shared by all the guest processes).
virtio-gpu also only supports one context per file description (but multiple
file descriptions per process) while amdgpu only allows one fd per process,
but multiple contexts per fd. This causes synchronization problems, because
virtio-gpu drops all sync primitive if they belong to the same fd/context/ring:
ie the amdgpu_ctx can't be expressed in virtio-gpu terms.
For now the solution is to only allocate a single amdgpu_ctx per application.
Contrary to radeonsi/radv, amdgpu_virtio can use libdrm_amdgpu directly: the
ones that don't rely on ioctl() are safe to use here.
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
This is required to implement virtio native-context.
In a virtualized environment, most of the functions provided
by libdrm_amdgpu will be implemented using virtio.
This allows to implement efficient virtualization, by
forwarding the kernel API to the host, instead of the GL/VK calls.
Similarly, the raw 'fd' or 'gem_handle' arguments are replaced
by opaque types. This allows to encapsulate all the needed
state in the handle, and use unmodified API between baremetal
and virtualized contexts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
Just like other input loads, radeonsi needs to know the barycentric
coordinates for it. This adds the src and determines the optimal barycentric
coordinates in nir_lower_point_smooth, the only producer of the intrinsic.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33046>
When using Zink with VK_EXT_descriptor_buffer enabled on IMG proprietary
drivers, the rendering behavior is incorrect and uniforms are not
updated properly (the gears of es2gears_x11 become all red and
overlaps).
Use lazy descriptors for IMG proprietary driver unless explicitly
overriden for testing purpose.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32343>
The goal is to reduce symbol pollution, especially when building
with Perfetto support, which previously led to an excessive number
of exported symbols.
objdump -T build/src/egl/libEGL_mesa.so.0.0.0 | grep perfetto | wc -l
- before: 6963
- after: 0
The new egl.sym version script explicitly exports only relevant egl and
MesaGLInteropEGL symbols, while marking all others as local.
While this change effectively removes all Perfetto-related exported symbols,
some C++ standard library symbols remain as undefined. These are pulled in
by the linker due to dependencies.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33001>
