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. Regards, Christian. _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx