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>
If the value is 64bit, but the alignment is 32bit type, the high 32bit
will be clamped with previous definition
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This is safe now because the ioctl uses an absolute timeout.
This prevents amdgpu_cs_query_fence_status from returning early e.g.
when a signal is delivered, which in turn caused Mesa winsys code to
assume a BO was idle when it actually wasn't yet.
Reviewed-by: Christian König <christian.koenig@amd.com>
make amdgpu_cs_query_fence reusable to support multi-fence query
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
amdgpu_va_range_query interface is added so that client can query va
range supported by specific device.
Signed-off-by: Sabre Shao <Sabre.Shao@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Two new interfaces are added to support client request for
allocate virtual address without physical memory committed to.
The virtual address space can be managed by client itself.
Signed-off-by: Sabre Shao <Sabre.Shao@amd.com>
Signed-off-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
base_preferred parameter is added to amdgpu_vamgr_find_va
so UMD can specify preferred va address when allocating.
Signed-off-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Useful when Mesa wants to wait for a lot of fences at the same time and
doesn't want to recalculate the relative timeout after every call.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Jammy Zhou
Rob Clark
Michel Dänzer
Thierry Reding
Marek Olšák
Emil Velikov
Alex Deucher
Tapani Pälli
Mario Kleiner
Alexandr Akulich
Leo Liu
Ken Wang
Christian König
Sabre Shao