a helper function to create and initialize amdgpu bo
v2: update error handling: add label and free bo
v3: update error handling: separate each error label
v4: update error handling and rebase
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Fix potential memory leak when handle flink bo in bo import.
Free the flink bo after bo import and in error handling.
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Arithmetic using void* pointers isn't defined by the C standard, only as
a GCC extension. Avoids compiler warnings:
../../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../../amdgpu/amdgpu_bo.c:554:48: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]
if (cpu >= bo->cpu_ptr && cpu < (bo->cpu_ptr + bo->alloc_size))
^
../../amdgpu/amdgpu_bo.c:561:23: warning: pointer of type ‘void *’ used in subtraction [-Wpointer-arith]
*offset_in_bo = cpu - bo->cpu_ptr;
^
v2: Use uintptr_t instead of char*, don't change function signature
(Junwei Zhang)
Fixes: 4d454424e1 ("amdgpu: add a function to find bo by cpu mapping
(v2)")
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Stupid me, max_key must always be larger than key.
Signed-off-by: Christian König <christian.koenig@amd.com>
Bugzilla: https://bugs.freedesktop.org/107552
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
The compiler points out that an int doesn't work as intended if
dev->bo_handles.max_key > INT_MAX:
../../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../../amdgpu/amdgpu_bo.c:550:16: warning: comparison of integer expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Wsign-compare]
for (i = 0; i < dev->bo_handles.max_key; i++) {
^
../../amdgpu/amdgpu_bo.c:558:8: warning: comparison of integer expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Wsign-compare]
if (i < dev->bo_handles.max_key) {
^
Fixes: 4d454424e1 ("amdgpu: add a function to find bo by cpu mapping
(v2)")
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Userspace needs to know if the user memory is from BO or malloc.
v2: update mutex range and rebase
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Use the correct files to build libdrm_amdgpu.
Signed-of-by: Mike Lothian <mike@fireburn.co.uk>
Fixes: d6cb0ee408 ("amdgpu: remove the hash table implementation")
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This way we can always find a BO structure by its handle.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
Not used any more.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
Instead of the hash use the handle table.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
Instead of the hash use the handle table.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
The kernel handles are dense and the kernel always tries to use the
lowest free id. Use this to implement a more efficient handle table
by using a resizeable array instead of a hash.
v2: add handle_table_fini function, extra key checks,
fix typo in function name
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
We have so few devices that just walking a linked list is probably
faster.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
Otherwise we leak file descriptors into child processes.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This reverts commit fe0488aa13.
It caused messages like
amdgpu 0000:23:00.0: bo 000000007dce0b3e va 0x0000101800-0x000010181f conflict with 0x0000101800-0x0000101820
in dmesg, and eventually a Xorg crash while running piglit.
Evidently, such BOs can actually be re-imported by other means than via
a KMS handle.
Fixes memory leak on module unload.
Analogous to mesa commit of the same name.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Analogous to the mesa commit of the same name.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Close the file descriptors under lock as well.
v2: close fds after removing from hash table
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Currently while exporting prime handle to fd read write access is
not granted. mmap fails because of this. mmap was not supported on
prime initially.
Here is link to related discussion
https://lists.freedesktop.org/archives/dri-devel/2017-February/131840.html
Adding the DRM_RDWR flag in amdgpu_bo_export to support mmap.
Signed-off-by: Satyajit <satyajit.sahu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
This will prevent any more missing `#include "config.h"` bug, at the
cost of having to recompile some files that didn't need to be when
changing build options.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
to support SRIOV and MCBP, need 16 IBs per submit
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The range is stored as exclusive, not inclusive. Subtracts one to get
the inclusive interval for the calculation. This fixes crashes when 32bit
addresses are in use.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Return high addresses if requested and available.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This reverts commit 07ea20d5be.
Unfortunately it turned out that this change broke some corner cases in
Mesa.
Revert it for now, but keep the high range in separate VA managers.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Helpful if your nm executable has a prefix based on the
architecture, for example.
Signed-off-by: Heiko Becker <heirecka@exherbo.org>
Cc: Timo Gurr <timo.gurr@gmail.com>
[Eric: v2: rebase and add Meson support]
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
issue: UMD allocates top 4GB, but don't do anything, just reserve top 4GB space,
but the performance of VP13 drops from 162fps to 99fps.
root cause:
our va hole list of vamgr is too long by time going.
fix:
reusing old hole as much as possible can make the list shortest.
result:
performance recovers as non-list path, next patch will remove non-list code path.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
That constant needs to be 64bits.
Fixes: amdgpu: use the high VA range if possible v2
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
It means it just didn't find an entry for the GPU in the amdgpu.ids file.
Fixes spurious
amdgpu_parse_asic_ids: Cannot parse ASIC IDs: Resource temporarily unavailable
error messages in that case.
Reported-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Retire the low range on Vega10 this frees up everything below 0xffff800000000000 for HMM.
v2: keep the 32bit range working.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
There's no point in keeping around the full table of marketing names,
when amdgpu_get_marketing_name only ever returns the device's marketing
name.
Acked-by: Slava Abramov <slava.abramov@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* Move empty/commented line check before the strdup and return -EAGAIN
directly
* Initialize r = -EAGAIN and remove redundant assignments
* Set r = -ENOMEM if last strdup fails, and remove redundant goto
Acked-by: Slava Abramov <slava.abramov@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* Move error message printing into amdgpu_parse_asic_ids and make it
return void
* Print only "Invalid format" error message if parse_one_line returns
-EINVAL
* Use strerror instead of printing the (negative) error code in hex
Acked-by: Slava Abramov <slava.abramov@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>