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. > > Cheers, > Nicolai > > >> Regards, >> Jammy >> >> >> Or is there some use-case that I'm forgetting where libgbm _does_ >> need those attributes? >> >> Cheers, >> Nicolai >> >> >> >> Also, I'm afraid there might still be cases where >> amdgpu-pro supports >> new hardware before radeonsi, in which case amdgpu_dri.so >> needs to >> support GBM for glamor and EGL in general. >> >> >> IIRC radeonsi can support Southern Islands and later ASICs. I >> don't >> think amdgpu-pro can support pre-GCN products easily, given >> current >> amdgpu kernel driver support. >> >> >> >> Also note that Nvidia developers were talking about >> possibly creating an >> nvidia specific GBM backend recently on the wayland-devel >> mailing list. >> >> >> Will nvidia open source their code for GBM backend? >> >> >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa >> and X developer >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> <mailto:mesa-dev@lists.freedesktop.org> >> <mailto:mesa-dev@lists.freedesktop.org >> <mailto:mesa-dev@lists.freedesktop.org>> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> >> >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> <mailto:mesa-dev@lists.freedesktop.org> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> >>
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
