[Glamor] Discussing DRI3 support

[davyaxel at free.fr]

>One major comment is, do we need to change the way of all pixmap's default creation behavior? I don't think we should do that. Only a few pixmaps will 
>be used as DRI3 buffer when it's referred by the two DRI3 APIs, we can convert it on demand. 
>
>
>For Get fd from pixmap: pixmap's texture --> image -->gbm_bo -->handle-->fd 
>For Get pixmap from fd: the same as you proposed . 
>
>
>This way we don't need to add a new option to the glamor_init. And we don't need to keep so many gbm_bos for each pixmap. And the libglamor.so 
>doesn't need to call any glamor_egl function directly. The reason why I split the library into libglamor.so and glamor_egl module is that the libglamor.so 
>maybe used by another gl context other than the egl. And at that time, one use case is the Xephyr. Although, I don't know whether it is still working 
>with xephyr now but it worked at the beginning. 
>
>
>As to the scan out pixmap, we may also need to remain the original method to let the DDX driver to allocate the buffer. 

The DDX still can. Only new textures would be created from a gbm_bo: the DDX can still create a textured pixmap, 
and the pixmap would have the texture taken from the bo given by the DDX.

>
>
>What do you think? 

One problem with this approach is that when we'll convert a pixmap to an fd for the first time (no attached image),
we'll have to create a new texture from a gbm_bo, and do the copy to the new texture and replace the old texture by the new texture,
because the old texture may be of the wrong format.

This can be avoided by always allocating the textures from a gbm_bo.
gbm_bo, like EGLimages, are on Mesa just a reference to the texture, plus some additional info.
It isn't really heavy to have a gbm_bo referencing the texture, but I fully agree the fact that glamor has to call
glamor_egl at every creation/destruction of texture can be annoying.
Plus it needs some functions to negociate dri3 between glamor and glamor_egl, that can be avoided with your method.


So if we accept that every first fd creation on a pixmap will cause a copy, I'll go your way, which is simpler.

Another question:
Can we assume that glamor_egl is loaded by the DDX?
It seems that glamor_egl can't call any glamor function,
so I need to have glamor_egl_dri3_fd_from_pixmap in glamor.c,
which would get the texture and check the type, and then call a glamor_egl function
to create the fd.

Axel Davy


PS: There is another thing to consider: 
When using the Present extension with a fullscreen pixmap, we can expect X to avoid a copy,
and flip the scanout buffer.
This is possible only if the buffers linked to the pixmap are scanout-compatible.
On radeonsi, for example, (not intel) scanout buffers have special tiling modes. 
That means that DDXs that have such cases, would need to always create a textured pixmap
for pixmaps of the size of the screen. 
For glamor, this changes absolutely anything, but documentation may have to indicate this to the DDX.