On 8/14/20 3:12 PM, Daniel Vetter wrote:
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.
Couldn't we just import once, and then use the GEM handle afterwards?
I have also no idea why you wouldn't want to use the existing drm
infrastructure, it's all there.
Sure; I think I'll add the normal GEM IOCTLs, since as you said, it's
quite easy to do and standard. I think it was more of a question about
the philosophy of DMA-BUF Heaps. In the future there may be other issues
like allocation from certain carveouts, where it'd be better not to
duplicate the allocation logic in multiple drivers, though there should
be multiple ways to address that, too.
Cheers, Daniel
Thanks!
Mikko
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
