GBM as standalone buffer allocator

2023-10-23 Thread Srinivas Pullakavi (QUIC)
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

2023-10-23 Thread Adam Jackson
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

2023-10-23 Thread Rob Clark
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

2023-10-23 Thread Thomas Erbesdobler

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