On Fri, Aug 14, 2020 at 3:59 AM Mikko Perttunen <cyndis@xxxxxxxx> 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
