GBM as standalone buffer allocator
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. 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 >
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-use of Intel driver genxml files in other project
Hi everyone, I'm currently working on a very simple OpenCL runtime for Intel GPUs, which I would like to make available as open source project (and maybe also distribute it). To generate the ring-commands (the command stream which controls the GPU, i.e. loads kernels and data, spawns worker threads, etc.) I used the genX.xml-files of the MESA project. They are located at src/intel/genxml in the source tree (i.e. https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/intel/genxml). Like MESA itself I am using these genX.xml-files to generate C(++) header files. Most code in that part of MESA's sources is covered by a MIT license, but I did not find a particular license for the genX.xml-files (however the generated headers are MIT-licensed, too). Am I allowed to distribute these genX.xml-files in my project, and if yes, under which terms? I would probably license my OpenCL runtime under the MIT license (SPDX-version), too. Regards, Thomas OpenPGP_signature.asc Description: OpenPGP digital signature