RE: GBM as standalone buffer allocator

"Srinivas Pullakavi (QUIC)" <[email protected]>
Newsgroups gmane.comp.video.mesa3d.devel
Message-ID <[email protected]>
+ Abhinav

From: Srinivas Pullakavi (QUIC)
Sent: Monday, January 22, 2024 10:44 PM
To: 'Yiwei Zhang' <[email protected]>
Cc: Rob Clark <[email protected]>; [email protected]
Subject: RE: GBM as standalone buffer allocator

Hi Yiwei,

Looks like this thread is closed.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26038#note_2243187

Can we collaborate on this?

Thanks,
Srinivas


From: Yiwei Zhang <[email protected]<mailto:[email protected]>>
Sent: Monday, November 20, 2023 4:38 AM
To: Srinivas Pullakavi (QUIC) <[email protected]<mailto:[email protected]>>
Cc: Rob Clark <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>
Subject: Re: GBM as standalone buffer allocator

There’s
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26038. It is quite appealing to me considering a VK only scenario.

On Thu, Nov 2, 2023 at 5:50 AM Srinivas Pullakavi (QUIC) <[email protected]<mailto:[email protected]>> wrote:
Hi Rob,

Thanks for your inputs.

We are planning to use DMA-Buf for GBM backend. DMA-buf supported heaps are listed in /dev/dma_heap/
Gbm backend selects the best heap based on usage. For example: Secure buffers will be allocated from secure heap.

Sample output:
                     # ls /dev/dma_heap
                 reserved  system

Sample code to allocate a buffer from system heap:
        int heap_fd = open(/dev/dma_heap/system, O_RDONLY | O_CLOEXEC))
        struct dma_heap_allocation_data heap_data {
              .len = size,                      // length of data to be allocated in bytes
              .fd_flags = O_RDWR | O_CLOEXEC,   // permissions for the memory to be allocated
              };
        int status = ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &heap_data)
        if (status == 0) {
                 int buffer_fd = heap_data.fd;
              }

In this case, there is no dependency on display / Graphics driver. But still GBM create device expects a device fd to be passed.

Can we make it optional to pass device fd ?

Thanks,
Srinivas

-----Original Message-----
From: Rob Clark <[email protected]<mailto:[email protected]>>
Sent: Tuesday, October 24, 2023 1:06 AM
To: Srinivas Pullakavi (QUIC) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: GBM as standalone buffer allocator

On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC) <[email protected]<mailto:[email protected]>> wrote:
>
> Hi,
>
>
>
> We are planning to enhance GBM as a standalone buffer allocator, which
> can be used for all multi-media clients. Ex: video, camera, display
> etc;
>
>
>
> GBM create device expects a file descriptor to be passed, which points to drm node. This brings in a dependency on display for buffer allocation. On headless devices where display driver is not present, GBM cannot be used for buffer allocations. E.g. Recording cases where pipeline is setup between Camera, Video, Graphics.
>

Note that you need some sort of device to allocate buffers from.  With mesa and upstream kernel, that would be the drm device.  (However as Adam points out, a drm device does not necessarily need a display..
for example, several vendors have compute-only GPUs (pci) which have no display outputs.)

You might want to look at ChromeOS's minigbm.  It already handles these cases (buffer sharing across display/gpu/video/camera).

BR,
-R

[1] https://chromium.googlesource.com/chromiumos/platform/minigbm/

>
> Could you please share your comments on what will be a good design to make GBM flexible for above?
>
>
>
> Thanks,
>
> Srinivas
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.