[Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

Lucas Stach l.stach at pengutronix.de
Fri Mar 4 16:08:24 UTC 2016


Am Freitag, den 04.03.2016, 15:09 +0000 schrieb Daniel Stone:
> Hi Lucas,
> 
> On 4 March 2016 at 13:49, Lucas Stach <l.stach at pengutronix.de> wrote:
> > this is a first shot at trying to hash out an API to allow bootstrapping
> > an EGL context on top of split render/scanout DRM devices. It tries to make
> > things really easy for applications, while leaving them in full control over
> > swap/flip scheduling etc.
> >
> > It adds 2 new API calls:
> >
> > 1. gbm_device_set_kms_provider()
> >    This is used to add a KMS device to the render GBM device.
> > 2. gbm_bo_get_kms_bo()
> >    This should be used by applications to translate the buffer returned
> >    by gbm_surface_lock_front_buffer() into a buffer that can be used to
> >    construct DRM FBs.
> 
> Thanks for taking this on, it looks really good! I just have the one
> question though - did you look at the EGLDevice extension? Using that
> to enumerate the GPUs, we could create the gbm_device using the KMS
> device and pass that in to the EGLDisplay, with an additional attrib
> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
> possibly be better since it is more independent of DRM as the API, and
> also allows people to share device enumeration/selection code with
> other platforms (e.g. choosing between multiple GPUs when using a
> winsys like Wayland or X11).
> 
I have not looked at this in detail yet, but I think it's just an
extension to the interface outlined by this series.

If we require the KMS device to have a DRI2/Gallium driver it should be
easy to hook up the EGLDevice discovery for them.
Passing in a second device handle for the KMS device is then just the
EGL implementation calling gbm_device_set_kms_provider() on the render
GBM device, instead of the application doing it manually.

Regards,
Lucas





More information about the mesa-dev mailing list