[Mesa-dev] GBM backend dynamic dispatch method
Daniel Vetter
daniel at ffwll.ch
Mon May 16 14:07:09 UTC 2016
On Mon, May 16, 2016 at 10:01:00AM +0800, Jammy Zhou wrote:
> 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.
The fb_modifier namespace in the kernel (which I plan to reuse) is a 64
bit opaque thing split into a 8bit vendor prefix + 56bits where you can
store whatever you want. Together with the pixel format fourcc, stride and
buffer size I hope that's enough to describe anything a vendor ever might
come up with.
For tiling formats we know are shared we could either do a shared vendor
prefix (well, one for the standard body that defined the tiling). Or in
cases we only notice this later on add an aliasing #define.
> > 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.
Well if you want to solve the problem of being able to use both radeonsi
and amdgpu-pro on the same system, then you absolutely must have a shared
libegl between them. I think the simplest approach to get that is to reuse
the mesa DRI loader interface, and specifically DRIimage as the backing
thing for EGLImage. Note that DRIimage is completely opaque to the mesa
EGL library, i.e. you can put in there whatever you need to make interop
between radeonsi and amgpu-pro work correctly.
I also hope that the same interfaces would be good enough (at least on the
driver side) to cover glx/dri3, but I'm starting out with just egl and
wayland.
The other option is to pull an Nvidia and invent your own standard
(loader) and try to shovel that down everyone's throat. It tends to not
work too well, see eglstreams ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the mesa-dev
mailing list