Hi Daniel, 2016-05-13 18:49 GMT+08:00 Daniel Vetter <dan...@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 <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. > 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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
