On 8/14/20 11:53 PM, John Stultz wrote:
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. :)
I think TegraDRM doesn't have a particular need for that (at least in
its current state), since it already needs GEMs, and has the GEM
infrastructure from DRM to lean on.
Thanks for the information, anyway :)
thanks
-john
Mikko
