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 > >