On 13.05.2016 00:22, Jammy Zhou wrote:
2016-05-13 12:39 GMT+08:00 Nicolai Hähnle <[email protected]
<mailto:[email protected]>>:
On 12.05.2016 20:20, Jammy Zhou wrote:
2016-05-12 17:39 GMT+08:00 Michel Dänzer <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>:
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.
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
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
