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>
Until now VA management was tied to a device handle, but there's no
reason for this.
As a first step to export VA management outside of amdgpu_device,
this commit adds a new structure type holding the 4 va_mgr.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Device will be removed from dev_list when refcount reaches 0, so the
dev_mutex must be locked before decreasing reference otherwise there's
a race where this device is still in dev_list with refcount 0 which will
assert or crash in amdgpu_device_initialize trying to use this device
instead of creating new one.
Fixes issue reported in https://gitlab.freedesktop.org/drm/amd/-/issues/2156#note_2268110
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
On 32-bit:
../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../amdgpu/amdgpu_bo.c:554:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpu < (void*)((uintptr_t)bo->cpu_ptr + bo->alloc_size))
^
Indeed, as amdgpu_bo_info.alloc_size is "uint64_t", the sum is
always 64-bit, while "void *" can be 32-bit or 64-bit.
Fix this by casting bo->alloc_size to "size_t", which is either
32-bit or 64-bit, just like "void *".
Fixes: c6493f360e ("amdgpu: Eliminate void* arithmetic in amdgpu_find_bo_by_cpu_mapping")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
---
v2:
- Add Reviewed-by.
pthread-stubs >= 0.4 simply passes -pthread which is similar to what
dependency('threads') returns. And make it a private dependency
for subprojects even on Linux.
Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org>
The compiler isn't smart enough to tell that this can't happen:
[30/74] Compiling C object amdgpu/libdrm_amdgpu.so.1.0.0.p/amdgpu_bo.c.o
In file included from ../amdgpu/amdgpu_internal.h:32,
from ../amdgpu/amdgpu_bo.c:39:
../xf86atomic.h: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../xf86atomic.h:47:54: warning: ‘bo’ may be used uninitialized [-Wmaybe-uninitialized]
47 | # define atomic_inc(x) ((void) __sync_fetch_and_add (&(x)->atomic, 1))
| ^
../amdgpu/amdgpu_bo.c:536:27: note: ‘bo’ was declared here
536 | struct amdgpu_bo *bo;
| ^~
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Apparently quite a few apps use this API to get the GPU
name and end up with NULL as the GPU name.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This produces no differences in the generated output. I've had to
manually add `requires : 'libdrm'` to libdrm_intel, otherwise libdrm
ends up in `Requires.private` instead of `Requires`.
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This allows consumers of libdrm as a subproject to use the simpler
`dependency('libdrm', fallback : 'libdrm')` syntax, as the libdrm build
files already tell meson that they override a dependency called
"libdrm".
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
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>
Instead of using a hand-rolled amdgpu_close_kms_handle function,
use the function from libdrm core, which does exactly the same
thing.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
In Vulkan we have extensions to assist with capture in replay in a
world where addresses are returned to the application. This involves
creating buffers at the same VA during replay as they were during
capture.
By itself libdrm_amdgpu already has support for this, but there is
the obvious failure mode that if another buffer is already allocated
at that VA things fail spectacularly. This is an actual issue as
internal buffers, like winsys images or shader binaries also
participate in the same VA allocation.
To avoid this problem applications have to create buffers which
are going to be captured with a flag, and the implementation is to
separate VA allocation for those buffers to reduce the collision risk:
"Implementations are expected to separate such buffers in the GPU address
space so normal allocations will avoid using these addresses. Apps/tools
should avoid mixing app-provided and implementation-provided addresses for
buffers created with VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT,
to avoid address space allocation conflicts."
This patch implements that by adding a flag for these buffers and allocating
address space from the top of the address range instead of the bottom.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Christian König <christian.koenig@amd.com>
This allows users to select the library type (static or shared)
using the Meson -Ddefault_library built-in option.
Issue: https://gitlab.freedesktop.org/mesa/drm/-/issues/45
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Fang Tan <tanfang@uniontech.com>
The amdgpu implementation uses `clock_gettime` so it needs to check whether it needs to link
against `-librt`.
Signed-off-by: Valentin Churavy <v.churavy@gmail.com>
Mesa expects to be able to map the same buffer, without unmapping it.
This leads to problem on long-running program.
On the other hand, libdrm uses cpu_map_count as a refcount and expects
its value to decrease so it can unmap buffers.
The previoulsy proprosed fix (https://patchwork.freedesktop.org/patch/258005/)
stopped increased the counter when it went past INT_MAX.
This commit instead proposes to use a larger type to store cpu_map_count.
The outcome is the same: long running apps will not crash, only the
implementation differs.
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1423
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch is to use generic variables as the input of amdgpu_cs_submit_raw2.
Because amdgpu_cs_submit_one won't handle IOCTL directly.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
So far, amdgpu_cs_submit_raw2 is mainly used for upper layer (Mesa), however,
amdgpu_cs_submit is used for current all unit tests. Our intention is that the
unit tests can actually verify the API which is really used.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Use alloca instead of malloc, then we don't need free them at the end of this
function.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Combined with -Wundef (added in 75758d2ccf & enforced in ba17673eed),
this provides absolute safety against #ifdef typos.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
v2: nit-picks fix
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Christian König <Christian.Koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
For the xf86drm.[ch] part : Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
None of the tests are bash specific. Tested with bash, zsh, dash, mksh
and ksh.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Niclas Zeising <zeising@daemonic.se>
Reviewed-by: Niclas Zeising <zeising@daemonic.se>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Simplifies its callers.
dev->bo_table_mutex is now always held when amdgpu_bo_create is called
(this was already the case in amdgpu_bo_import).
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
And propagate drmIoctl's return value.
This allows replacing all remaining open-coded DRM_IOCTL_GEM_CLOSE
ioctl calls with amdgpu_close_kms_handle calls.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Avoids compiler warning:
../../amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_ctx_override_priority':
../../amdgpu/amdgpu_cs.c:155:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
union drm_amdgpu_sched args;
^~~~~
Reviewed-by: Christian König <christian.koenig@amd.com>
v2: adapt to new one transfer ioctl
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
v2: symbos are stored in lexical order.
v3: drop export/import and extra query indirection
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Clang complains when initializing unions using "= {0}"
so instead use memset.
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Marissa Wall <marissaw@google.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
This way we can override the priority of a single context using a
master fd.
Since we cannot usefully create an amdgpu device of a master fd
without the fd deduplication kicking in this takes a plain fd.
This can be used by e.g. radv to get high priority contexts using
a master fd from the primary node or a lease.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Saw a couple of typos fixes in the patch DragonFlyBSD carries [1], so
I ran codespell (a spell checker for code) on the whole repo.
[1] https://github.com/DragonFlyBSD/DPorts/blob/master/graphics/libdrm/files/patch-xf86drm.c
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Pierre-Eric Pelloux-Prayer
David Rosca
Marek Olšák
Dylan Baker
Samuel Pitoiset
Geert Uytterhoeven
Jan Beich
Simon Ser
Alex Deucher
Bas Nieuwenhuizen
Leo Liu
Fang Tan
Valentin Churavy
Huang Rui
Eric Engestrom
Chunming Zhou
Emil Velikov
Michel Dänzer
John Stultz