[Mesa-dev] GBM backend dynamic dispatch method

Mon May 16 02:01:00 UTC 2016

Hi Daniel,

2016-05-13 18:49 GMT+08:00 Daniel Vetter <daniel at ffwll.ch>:

> On Fri, May 13, 2016 at 02:33:13PM +0800, Jammy Zhou wrote:
> > 2016-05-13 14:01 GMT+08:00 Nicolai Hähnle <nhaehnle at gmail.com>:
> >
> > > On 13.05.2016 00:22, Jammy Zhou wrote:
> > >
> > >>
> > >>
> > >> 2016-05-13 12:39 GMT+08:00 Nicolai Hähnle <nhaehnle at gmail.com
> > >> <mailto:nhaehnle at gmail.com>>:
> > >>
> > >>     On 12.05.2016 20:20, Jammy Zhou wrote:
> > >>
> > >>
> > >>
> > >>         2016-05-12 17:39 GMT+08:00 Michel Dänzer <michel at daenzer.net
> > >>         <mailto:michel at daenzer.net>
> > >>         <mailto:michel at daenzer.net <mailto:michel at daenzer.net>>>:
> > >>
> > >>
> > >>              On 12.05.2016 17:58, Yu, Qiang wrote:
> > >>              > Oh, what a crazy idea. So you mean it can work like
> this?
> > >>              >
> > >>              > 1. use the libgbm/gbm_dri/libEGL/libGLES from mesa
> which
> > >>         will load
> > >>              > radeonsi_dri.so
> > >>              >
> > >>              > 2. libGL/amdgpu_dri.so from amdgpu-pro
> > >>
> > >>              glamor uses libEGL/GBM and libGL, so this could only work
> > >>         with Mesa's
> > >>              libGL (or the GLVND one in the future). Can amdgpu_dri.so
> > >>         work with
> > >>              Mesa's libGL right now?
> > >>
> > >>
> > >>         I think amdgpu_dri.so is not completely compatible with Mesa's
> > >> libGL
> > >>         (considering some special feature requirements for amdgpu-pro
> > >>         and Mesa's
> > >>         evolving). Another problem is that Mesa's libgbm cannot share
> > >>         necessary
> > >>         buffer attributes (such as tiling info, etc) with
> amdgpu_dri.so
> > >>         at this
> > >>         moment.
> > >>
> > >>
> > >>     I think the long-term plan for such attributes is passing them via
> > >>     amdgpu_bo_metadata (which is defined in libdrm's amdgpu.h). This
> > >>     metadata is read and written directly through libdrm_amdgpu, and
> so
> > >>     libgbm doesn't have to be involved as far as I can see.
> > >>
> > >>
> > >> Yes, amdgpu_bo_metadata is exactly one good place for such kind of
> > >> information. But IMHO there are still several things to take care.
> Did I
> > >> miss something?
> > >> - Same meta data definition ("umd_metadata" field) should be used by
> > >> radeonsi and amdgpu-pro.
> > >>
> > >
> > > I absolutely agree that we need to coordinate on how the metadata
> fields
> > > are used.
> > >
> > > At this time, radeonsi uses and sets the explicit members of
> > > amdgpu_bo_metadata, i.e. tiling_info and size_metadata. As far as I can
> > > see, no flags have been defined - flags and umd_metadata are preserved
> by
> > > radeonsi if a different UMD were to set them, and are otherwise
> initialized
> > > to 0.
> > >
> > >
> > > - We need some way to translate gbm_bo or EGLImage into amdgpu_bo, so
> > >> that libdrm_amdgpu interfaces can be used.
> > >>
> > >
> > > In general, how to do this kind of mapping depends on the situation.
> For
> > > example, for gbm_bo it is the GBM backend that allocates the gbm_bo
> > > structure, so C-style inheritance can be used. For example, the DRI
> backend
> > > has a type:
> > >
> > > struct gbm_dri_bo {
> > >    struct gbm_drm_bo base;
> > >
> > >    __DRIimage *image;
> > >
> > >    /* Used for cursors and the swrast front BO */
> > >    uint32_t handle, size;
> > >    void *map;
> > > };
> > >
> > > It will allocate a struct gbm_dri_bo, and pass a pointer to base back
> to
> > > the caller. Then, callbacks implemented by the backend cast the
> provided
> > > gbm_bo pointer to gbm_dri_bo. The GBM backend implementation in
> amdgpu-pro
> > > can use the same trick, and store whatever internal info it requires
> in the
> > > "derived" structure, e.g. an amdgpu_bo_handle.
> > >
> >
> > To clarify, I was talking about retrieving the meta data from gbm_bo in
> > amdgpu-pro. This doesn't work if the DRI backend (radeonsi_dri.so) is
> used
> > with mesa libgbm, which was mentioned in previous discussion.
>
> Randomly jumping in here with a few notes. I'm digging through the entire
> egl/gbm/wayland stack right now to figure out what metadata needs to be
> added so that we can describe buffers faithfully and completely, including
> tiling, compression and all that, in a generic way.
>

That sounds good. How are you going to handle some vendor specific
attributes? For example, different tiling formats may be defined by vendors
for their own hardware.

>
> It will be just for color buffers (i.e. anything you might actually want
> to share), because that's the only thing we need to share across
> drivers/processes, but I think that's the same thing you need here. The
> basic idea is to add the fb_modifiers we have added to the kernel (and
> which are defined in drm_fourcc.h) to the DRIimage interfaces, both for
> exporting and importing.

DRIimage is mesa specific concept. But I'm wondering how it can work with
amdgpu-pro or some other non-mesa drivers.

> It's always been the idea that drm_fourcc.h could
> also contain fb_modifiers which are only useful for GL->GL sharing, so no
> requirement to have an in-kernel user for each define. E.g. when certain
> tiling layouts can't be scanned out.
>
> That should be enough that you could talk to 2 completely different dri
> drivers, and share buffers with them in a generic way.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160516/9105379a/attachment-0001.html>