On 2024-05-07 19:45, Christian König wrote: > Am 07.05.24 um 18:46 schrieb Linus Torvalds: >> >> Just what are the requirements for the GPU stack? Is one of the file >> descriptors "trusted", IOW, you know what kind it is? >> >> Because dammit, it's *so* easy to do. You could just add a core DRM >> ioctl for it. Literally just >> >> struct fd f1 = fdget(fd1); >> struct fd f2 = fdget(fd2); >> int same; >> >> same = f1.file && f1.file == f2.file; >> fdput(fd1); >> fdput(fd2); >> return same; >> >> where the only question is if you also woudl want to deal with O_PATH >> fd's, in which case the "fdget()" would be "fdget_raw()". >> >> Honestly, adding some DRM ioctl for this sounds hacky, but it sounds >> less hacky than relying on EPOLL or KCMP. >> >> I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl >> too, if this is possibly a more common thing. and not just DRM wants >> it. >> >> Would something like that work for you? > > Well the generic approach yes, the DRM specific one maybe. IIRC we need to be > able to compare both DRM as well as DMA-buf file descriptors. > > The basic problem userspace tries to solve is that drivers might get the same > fd through two different code paths. > > For example application using OpenGL/Vulkan for rendering and VA-API for > video decoding/encoding at the same time. > > Both APIs get a fd which identifies the device to use. It can be the same, > but it doesn't have to. > > If it's the same device driver connection (or in kernel speak underlying > struct file) then you can optimize away importing and exporting of buffers > for example.
It's not just about optimization. Mesa needs to know this for correct tracking of GEM handles. If it guesses incorrectly, there can be misbehaviour. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
