On Fri, Aug 14, 2020 at 1:34 PM Mikko Perttunen <cyndis@xxxxxxxx> wrote: > > Hi, > > 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. > > My question is then: what is the role of DMA Heaps? If it is to be used > as a central allocator, should the FD issue be left to the application, > or addressed somehow? Should it be considered a potential alternative > for GEM allocations? Atm no one knows. What's for sure is that dma-buf fd are meant to establish sharing, and then once imported everywhere, closed again. dma-buf heaps might or might be useful for sharing the cross-device memory allocator problem (the rough idea is that in sysfs every device lists all the heaps it can use, and then you pick the common one that works for all devices). But that's for shared buffers only. For an acceleration driver you want drm gem ids, because yes fd limits. Also constantly having to reimport dma-buf for every cs ioctl doesn't sound like a bright idea either, there's a reason we have the drm_prime cache and all that stuff. I have also no idea why you wouldn't want to use the existing drm infrastructure, it's all there. Cheers, Daniel > > Thanks, > Mikko > > [1] https://www.spinics.net/lists/dri-devel/msg262021.html > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
