[Mesa-dev] GBM backend dynamic dispatch method

[Jammy Zhou]

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.


>
> 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 at lists.freedesktop.org
>>         <mailto:mesa-dev at lists.freedesktop.org>
>>         <mailto:mesa-dev at lists.freedesktop.org
>>         <mailto:mesa-dev at lists.freedesktop.org>>
>>         https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>>
>>
>>         _______________________________________________
>>         mesa-dev mailing list
>>         mesa-dev at lists.freedesktop.org
>>         <mailto:mesa-dev at lists.freedesktop.org>
>>         https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160513/4d739d19/attachment-0001.html>