<div dir="ltr">Hi Daniel, <div class="gmail_extra"> <div class="gmail_quote">2016-05-13 18:49 GMT+08:00 Daniel Vetter <<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, May 13, 2016 at 02:33:13PM +0800, Jammy Zhou wrote: > 2016-05-13 14:01 GMT+08:00 Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>>: > > > On 13.05.2016 00:22, Jammy Zhou wrote: > > > >> > >> > >> 2016-05-13 12:39 GMT+08:00 Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a> > >> <mailto:<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>>>: > >> > >> On 12.05.2016 20:20, Jammy Zhou wrote: > >> > >> > >> > >> 2016-05-12 17:39 GMT+08:00 Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a> > >> <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> > >> <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a> <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>>>>: > >> > >> > >> 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. </div></div>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. </blockquote><div> </div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote><div> </div><div>DRIimage is mesa specific concept. But I'm wondering how it can work with amdgpu-pro or some other non-mesa drivers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="http://blog.ffwll.ch" rel="noreferrer" target="_blank">http://blog.ffwll.ch</a> </blockquote></div> </div></div>