On Fri, Aug 14, 2020 at 3:59 AM Mikko Perttunen cyndis@kapsi.fi wrote:
I'm currently working on a new UAPI for Host1x/TegraDRM (see first draft in thread "[RFC] Host1x/TegraDRM UAPI"[1]). One question that has come up is regarding the buffer allocation mechanism. Traditionally, DRM drivers provide custom GEM allocation IOCTLs. However, we now have DMA Heaps, which would be sufficient for TegraDRM's needs, so we could skip implementing any GEM IOCTLs in the TegraDRM UAPI, and rely on importing DMA-BUFs. This would mean less code on TegraDRM's side.
However, one complication with using DMA Heaps is that it only provides DMA-BUF FDs, so it is possible that a user application could run out of free file descriptors if it is not adjusting its soft FD limit. This would especially be a problem for existing applications that might have worked with the traditional GEM model and didn't need to adjust their FD limits, but would then fail in some situations with the increased FD usage of DMA-BUF FDs.
I'm not sure exactly if this would help, but I am working on some exploratory tweaks to DMA BUF Heaps so that there could be an in-kernel accessor that returns a struct dma_buf instead of a fd.
This is motivated as some folks want to use DMA BUF Heaps (if I understand your approach) in a similar fashion, where the driver wants to generate a DMA BUF but doesn't want to create their own DMA BUF exporter which would duplicate one of the DMA BUF Heaps.
I'm a little mixed on this as part of the reason DMA BUF Heaps exists as a userland interface is because its userland which knows the path that a buffer will take, so userland is in the best position to understand what type of buffer it needs to allocate. It seems to me that drivers should instead import a buffer provided to them from userland to fill, rather than allocating a buffer from a heap they choose (which may constraint later use of that buffer). But, I also grant that drivers implementing their own DMA BUF exporters that duplicate existing code is silly, so having in-kernel allocation interfaces may be reasonable.
However, the efforts are also somewhat blocked on having a public in-kernel user of such an interface, so they are basically only exploratory at the moment. So if you have an in-kernel user interested in something like this, I'd be glad to get further input.
This probably doesn't help answer your question wrt to GEM, and I'd defer to Daniel there. :)
thanks -john