Importing a bo whose handle is still in the bo cache crashes during cleanup.
Remove bo from cache when importing.
Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It is possible to hit a race condition in create_from_prime, when trying
to import a BO that's currently being freed. In case of prime sharing
we'll succesfully get a handle, but fail on get_tiling call, potentially
confusing the caller (and requiring different locking scheme than with
sharing using flink). Wrap fd_to_handle with struct_mutex to force
a more consistent behaviour between prime/flink, convert fprintf to DBG
when handling errors.
(From Chris:
The race is that the kernel returns us the same file-private handle as
the first thread, but that first thread is about to call gem_close
(thereby removing the handle from the file completely) and does so
between us acquiring the handle and taking the mutex. If we take
the mutex, then we acquire the refcnt on the bo prior to the first
thread completing its unref (and so preventing the early close). Or we
acquire the handle after the earlier close, in which case we are the new
owner.
)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/drm_import_export/import-close-race-prime
Signed-off-by: Rafał Sapała <rafal.a.sapala@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
[Emil Velikov: remove duplicate amdgpu.h from LIBDRM_AMDGPU_FILES]
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Use tabs and spaces consistently to align function arguments on
subsequent lines with those of the first line.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Usage of blank lines can be a matter of taste, of course, but for these
we can surely all agree that they're not needed and inconsistent.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Each device can have its own vamgr, so make it per device now.
This can fix the failure with multiple GPUs used in one single
process.
v2: rebase
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The AMDGPU_VA_RANGE_32_BIT flag is added to request VA range in the
32bit address space for amdgpu_va_range_alloc.
The 32bit address space is reserved at initialization time, and managed
with a separate VAMGR as part of the global VAMGR. And if no enough VA
space available in range above 4GB, this reserved range can be used as
fallback.
v2: add comment for AMDGPU_VA_RANGE_32_BIT, and add vamgr to va_range
v3: rebase to Emil's drm_private series
v4: fix one warning
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Make it a generic function independent of the device info.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
User should only see these with LIBGL_DEBUG=verbose. But in case you
are hitting issues like "handle X at index Y already on submit list"
errors from the kernel, this gives some useful visibility for debug.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It should be a less common case, but it is possible for a single bo to
be on multiple rings, for example when sharing a buffer across multiple
pipe_context's created from same pipe_screen.
So rather than completely fall over in this case, fallback to slow-path
of looping over all bo's in the ring's bo-table (but retain the fast-
path of constant-lookup for the first ring the buffer is on).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Group the parts related to building out submit ioctl into their own
sub-struct. Split out from next commit since it is just boring churn.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Allow connector names to be used in the specification of the -s option.
This requires storing the string passed on the command-line so that it
can later be resolved to a connector ID (after the DRM device has been
opened).
Connector names are constructed from the connector type name and
connector type ID using the same format as used internally in the
Linux kernel.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Thus the only symbols that we export are the ones officially provided by
the API.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
We need this include in porting changes for the OpenGL ES
conformance suite.
v2: remove c_plusplus usage
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Use only __cplusplus which is supported by the C++ standard.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
The PCI revision ID can be used to differentiate ASICs.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The amdgpu_device for a device node needs its own dup'ed fd, instead
of using the original fd passed in for a screen, to make multi-x-screen
ZaphodHeads configurations work on amdgpu.
The original fd's lifetime differs from that of the amdgpu_device, and from the
one stored in the hash. The hash key is the fd, and in order to compare hash
entries we fstat them, so the fd must be around for as long as the amdgpu_device
is.
This patch for libdrm/amdgpu is a translation of the radeon-winsys ZaphodHeads
fix for mesa's radeon-winsys, from mesa commit 28dda47ae4d974e3e032d60e8e0965c8c068c6d8
"winsys/radeon: Use dup fd as key in drm-winsys hash table to fix ZaphodHeads."
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
v2: Check for valid fd's being >= 0, because fd == 0 is in theory
a valid, although unlikely, fd and fd == -1 would denote an
invalid fd. Thanks to William Lewis for pointing this out.
Reported-by: William Lewis <minutemaidpark@hotmail.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
The include type changed from system to own.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alexandr Akulich <akulichalexander@gmail.com>
The following interfaces are changed accordingly:
- amdgpu_bo_alloc
- amdgpu_create_bo_from_user_mem
v2: update the interfaces
v3: remove virtual_mc_base_address from amdgpu_bo
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The flags is added for extensibility to cover some special requirements
in the future, i.e, request VA range in the first 4GB of address space
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Varad Gautam
Rafał Sapała
Hyungwon Hwang
Mauro Rossi
Rob Clark
Thierry Reding
Jammy Zhou
Michel Dänzer
Marek Olšák
Emil Velikov
Alex Deucher
Tapani Pälli
Mario Kleiner
Alexandr Akulich
Leo Liu
Ken Wang