Allows to opt-out from the device deduplication logic. This is not the
recommended way of using dev handles, but it's necessary for native context:
in this situation one process (eg: Qemu) will init many devices and we
want independent devices to make sure guest applications are isolated from
each other.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is the same functionnality that amdgpu_va_range_alloc offers,
except it's now usable without a device handle.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This will allow applications to use this feature without a device.
The first use case will be native context: we want VA address to
be managed by the guest (to avoid a round-trip to the host to only
generate a VA) but the amdgpu_device only exist on the host.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Dual purpose:
- The drm fd dedupe functionality confuses the radeonsi
amdgpu winsys if radeonsi isn't the first thing opening
the device. By exposing the fd we can detect this case.
- For a common mesa Vulkan sync objects implementation
with syncobj. (notable: no buffer allocation)
Both shouldn't interferece with libdrm_amdgpu functionality
though it does somewhat piece the abstraction of the library.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3424
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5630
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Pierre-Eric Pelloux-Prayer
Marek Olšák
Samuel Pitoiset
Bas Nieuwenhuizen
Leo Liu
Eric Engestrom