RE: GBM as standalone buffer allocator
+ Abhinav
From: Srinivas Pullakavi (QUIC)
Sent: Monday, January 22, 2024 10:44 PM
To: 'Yiwei Zhang'
Cc: Rob Clark ; mesa-dev@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 mailto:zzyi...@chromium.org>>
Sent: Monday, November 20, 2023 4:38 AM
To: Srinivas Pullakavi (QUIC)
mailto:quic_spull...@quicinc.com>>
Cc: Rob Clark mailto:robdcl...@gmail.com>>;
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@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)
mailto:quic_spull...@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, _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 mailto:robdcl...@gmail.com>>
Sent: Tuesday, October 24, 2023 1:06 AM
To: Srinivas Pullakavi (QUIC)
mailto:quic_spull...@quicinc.com>>
Cc: mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
Subject: Re: GBM as standalone buffer allocator
On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC)
mailto:quic_spull...@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
>
>
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
Sent: Monday, November 20, 2023 4:38 AM
To: Srinivas Pullakavi (QUIC)
Cc: Rob Clark ; mesa-dev@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)
mailto:quic_spull...@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, _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 mailto:robdcl...@gmail.com>>
Sent: Tuesday, October 24, 2023 1:06 AM
To: Srinivas Pullakavi (QUIC)
mailto:quic_spull...@quicinc.com>>
Cc: mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
Subject: Re: GBM as standalone buffer allocator
On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC)
mailto:quic_spull...@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
>
>
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_spull...@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, _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
> Sent: Tuesday, October 24, 2023 1:06 AM
> To: Srinivas Pullakavi (QUIC)
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: GBM as standalone buffer allocator
>
> On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC) <
> quic_spull...@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
> >
> >
>
RE: GBM as standalone buffer allocator
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, _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
Sent: Tuesday, October 24, 2023 1:06 AM
To: Srinivas Pullakavi (QUIC)
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: GBM as standalone buffer allocator
On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC)
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
>
>
Re: GBM as standalone buffer allocator
On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC) 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 > >
Re: GBM as standalone buffer allocator
On Mon, Oct 23, 2023 at 6:39 AM Srinivas Pullakavi (QUIC) < quic_spull...@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. > I don't understand the objection. drm devices are not compelled to have display support. The panfrost drm driver for example does not have any display support, only rendering. - ajax >
