[PATCH libdrm 0/9] amdgpu:

Koenig, Christian Christian.Koenig at amd.com
Tue Jun 25 09:44:31 UTC 2019

Am 25.06.19 um 10:02 schrieb Michel Dänzer:
> On 2019-06-24 7:31 p.m., Christian König wrote:
>> Patches #1 - #3 look good to me, but I'm not sure if the rest is such a
>> good idea.
>> Basically you not only want to use the same FD for CS, but also for
>> basically all buffer functions and as far as I can see we break that here.
> How so? The core FD is used for everything except flink and
> amdgpu_bo_handle_type_kms_user.

IIRC in the Mesa winsys we compare the amdgpu_device and amdgpu_bo 
pointers to figure out if an opened device or imported BO is the same as 
one we already know.

With this patch that won't work any more and for example OpenGL and 
VA-API could potentially use separate amdgpu_bo pointers for the same 
underlying buffer. That in turn would break synchronization.

Additional to that we potentially could keep a bunch of file descriptors 
around which we don't necessary want. In other words we previously 
closed the extra file descriptors, but now we keep them open as well. 
But that should probably be only a minor problem.

>> I would rather add a new function to export the KMS handle for a certain
>> BO/FD pair. Exporting the handle based on a type was also like trying to
>> squeeze a round pig through a square hole in the first place.
>> KMS, flink and DMA-buf fd are fundamentally different and shouldn't be
>> handled by the same function in the first place.
> I don't really see the problem. radeonsi & RADV are using
> amdgpu_bo_handle_type_kms to get handles for command stream submission,
> so those handles have to be valid for the core FD. Now there's
> amdgpu_bo_handle_type_kms_user to get a handle valid for the FD passed
> to amdgpu_device_initialize. Can you describe a scenario where a handle
> valid for yet another file description is needed?

Not yet another file descriptor, but the underlying problem here seems 
to be that we don't tell libdrm in which domain/file descriptor the KMS 
should actually be valid in.


More information about the amd-gfx mailing list