[Mesa-dev] GBM backend dynamic dispatch method
Mao, David
David.Mao at amd.com
Mon May 16 14:58:53 UTC 2016
Hi Daniel and Jammy,
I think we have off the track.
The motivation behind this thread is to see whether we could find a generally agreed way for gbm to be able to load different gbm backend in the fly.
It would be very appreciated if we could get back to this topic and reach the concur.
Regarding to the inter-op between amdgpu-pro and mesa or any other vendor's close source driver and mesa, I think it is a different topic and philosophy related.
>From mesa's perspective, the driImage is a natural level to do the inter-operation which has the descriptive metadata associated and it is just like the private 'MesaImage' extension for different modules to adopt.
>From my point of view, especially for amdgpu-pro and mesa, the well-defined opaque handle, no matter it is EGLImage or EGLStream, are a suitable level of sharing.
Different EGL implementation supposed to import/export the system level primitives backing the EGLImage, which is vendor agnostic and easy to be shared.
Furthermore, talking about gbm, IMO, it is unnatural for EGL gbm platform to set callbacks in gbm_device just to help to interpret the EGLImage. and it supposed to be gbm's caller's responsibility to query EGL implementation to get the gem_flink-name then calls gbm to import from system primitives. With that we even don't need to add more callbacks for new platforms, like wayland and mir.
Thanks.
Best Regards,
David
________________________________________
From: mesa-dev <mesa-dev-bounces at lists.freedesktop.org> on behalf of Daniel Vetter <daniel at ffwll.ch>
Sent: Monday, May 16, 2016 10:07:09 PM
To: Jammy Zhou
Cc: mesa-dev at lists.freedesktop.org; Michel Dänzer
Subject: Re: [Mesa-dev] GBM backend dynamic dispatch method
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
_______________________________________________
mesa-dev mailing list
mesa-dev at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list