[Glamor] Discussing DRI3 support

[zhigang gong]

On Thu, Nov 28, 2013 at 2:14 AM, <davyaxel at free.fr> wrote:

> On 27/11/2013, Zhigang Gong wrote :
> > On Tue, Nov 26, 2013 at 09:08:16PM +0100, davyaxel at free.fr wrote:
> >
> >> I think the best approach is to consider we live in an argb8888 world
> (which seems a pretty good asumption right now).
> >
> > Actually, just as you mentioned in last email glamor already faces this
> problem and uses this assumption too.
> > And it uses ARGB8888 for depth32.
> >
> >>
> >> We can't know which component order will result when allocating a
> texture with GL_BGRA of GL_RGBA.
> > Right, the actual internal texture format, the real pixel format, is
> hardware driver dependent.
> >> For example with gallium drivers, GL_RGBA (the one we use now for all
> textures) is ABGR8888.
> >> To ensure we use ARGB8888, the best to me seems to allocate an argb8888
> gbm_bo, and create the texture from it (after converting to an image).
> > I agree with this solution.
> >
> > Thanks,
> > Zhigang Gong.
> >
> >
>
> Thanks.
>
> Could you please tell what you think of the following to enable/handle
> dri3:
>
> . glamor_init has a new flag GLAMOR_ENABLE_DRI3.
> glamor_init would call a glamor_egl function to indicate to glamor_egl the
> user wants to enable dri3 support.
>
> . In glamor_egl_init, glamor_egl decides if the egl display is dri3
> capable. It calls a glamor function that will enable
> dri3 support.
>
> . The user has access to a function to know if dri3 support is enabled.
>
> . If dri3 support is enabled, when creating a texture, glamor will first
> try to get the texture by calling
> a glamor_egl function to create a texture (and glamor_egl would use a
> gbm_bo for this).
>
> . glamor_egl can store the gbm_bo with its private pixmap key with the
> pixmap, to be able to avoid unnecessary steps when
> having to get an fd from a pixmap (it won't need to get the texture from
> glamor).
>
> . When a pixmap is destroyed, glamor will always call a glamor_egl
> function if dri3 support is enabled, to enable glamor_egl to delete the
> gbm_bo.
>
> . glamor defines a function to get the glamor_pixmap_type of a pixmap.
>
> . glamor_egl would define two functions to convert a pixmap to an fd and
> an fd to a pixmap. The behaviours and types would match exactly to what
> asks X Dri3 for the DDXs. The functions would do nothing if dri3 support
> isn't enabled.
>

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.

What do you think?

>
>
>
> Axel Davy
> _______________________________________________
> Glamor mailing list
> Glamor at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/glamor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/glamor/attachments/20131128/d5cd0a24/attachment.html>