GBM as standalone buffer allocator

[Srinivas Pullakavi (QUIC)]

+ Abhinav

From: Srinivas Pullakavi (QUIC)
Sent: Monday, January 22, 2024 10:44 PM
To: 'Yiwei Zhang' <zzyiwei at chromium.org>
Cc: Rob Clark <robdclark at gmail.com>; mesa-dev at lists.freedesktop.org
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 <zzyiwei at chromium.org<mailto:zzyiwei at chromium.org>>
Sent: Monday, November 20, 2023 4:38 AM
To: Srinivas Pullakavi (QUIC) <quic_spullaka at quicinc.com<mailto:quic_spullaka at quicinc.com>>
Cc: Rob Clark <robdclark at gmail.com<mailto:robdclark at gmail.com>>; mesa-dev at lists.freedesktop.org<mailto:mesa-dev at lists.freedesktop.org>
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) <quic_spullaka at quicinc.com<mailto:quic_spullaka at quicinc.com>> 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 <robdclark at gmail.com<mailto:robdclark at gmail.com>>
Sent: Tuesday, October 24, 2023 1:06 AM
To: Srinivas Pullakavi (QUIC) <quic_spullaka at quicinc.com<mailto:quic_spullaka at quicinc.com>>
Cc: mesa-dev at lists.freedesktop.org<mailto:mesa-dev at lists.freedesktop.org>
Subject: Re: GBM as standalone buffer allocator

On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC) <quic_spullaka at quicinc.com<mailto:quic_spullaka at quicinc.com>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20240222/663da54e/attachment.htm>