[Mesa-dev] GBM backend dynamic dispatch method

[Daniel Vetter]

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.

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