On Fri, May 13, 2016 at 02:33:13PM +0800, Jammy Zhou wrote: > 2016-05-13 14:01 GMT+08:00 Nicolai Hähnle <nhaeh...@gmail.com>: > > > On 13.05.2016 00:22, Jammy Zhou wrote: > > > >> > >> > >> 2016-05-13 12:39 GMT+08:00 Nicolai Hähnle <nhaeh...@gmail.com > >> <mailto:nhaeh...@gmail.com>>: > >> > >> On 12.05.2016 20:20, Jammy Zhou wrote: > >> > >> > >> > >> 2016-05-12 17:39 GMT+08:00 Michel Dänzer <mic...@daenzer.net > >> <mailto:mic...@daenzer.net> > >> <mailto:mic...@daenzer.net <mailto:mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
