Hi Maira, On Thu, Nov 09, 2023 at 09:14:29AM -0300, Maira Canal wrote: > On 11/9/23 04:45, Simon Ser wrote: > > User-space sometimes needs to allocate scanout-capable memory for > > GPU rendering purposes. On a vc4/v3d split render/display SoC, this > > is achieved via DRM dumb buffers: the v3d user-space driver opens > > the primary vc4 node, allocates a DRM dumb buffer there, exports it > > as a DMA-BUF, imports it into the v3d render node, and renders to it. > > > > However, DRM dumb buffers are only meant for CPU rendering, they are > > not intended to be used for GPU rendering. Primary nodes should only > > be used for mode-setting purposes, other programs should not attempt > > to open it. Moreover, opening the primary node is already broken on > > some setups: systemd grants permission to open primary nodes to > > physically logged in users, but this breaks when the user is not > > physically logged in (e.g. headless setup) and when the distribution > > is using a different init (e.g. Alpine Linux uses openrc). > > > > We need an alternate way for v3d to allocate scanout-capable memory. > > For me, it is a bit unclear how we import the vc4 DMA-BUF heap into v3d. > Should we create an IOCTL for it on v3d? dma-heaps are separate device files (under /dev/dma_heap) that have their specific uapi to allocate buffers: https://elixir.bootlin.com/linux/latest/source/drivers/dma-buf/dma-heap.c#L126 You then get a dma-buf handle you can import into whatever device you want. Maxime
Attachment:
signature.asc
Description: PGP signature
