[Glamor] [PATCH] Allow to create textured pixmaps from gbm_bo without using gem names

[Axel Davy]

Hi,

On 19/11/2013, Axel Davy wrote :
>> There is no plan for DRI3 support currently. If you have any
>> proposal which could support DIR3 in glamor, you are welcome
>> to submit it here for discussion. For now, this patch LGTM.
>> will push it latter.
> eglCreateImageKHR allows to create an image from a texture
> (this is only supported on intel currently). Glamor could then
> import the image as gbm_bo, get an handle from it,
> and use the correct ioctl to get an fd.
>
> To convert an fd into pixmap, it could use the
> eglCreateImageKHR extension to import an fd as an
> image (only supported on intel currently), and import
> it as a texture.
>
> That said, it would mean the DDX has less control over the
> bo format used by pixmaps, since it would never allocate
> the bo itself (tiling, etc, would be under the control of Mesa)
> That can be a problem for using the pixmap bo
> as scanout buffer.
>

I've looked in Mesa code to see how much work it would require to
implement these eglCreateImageKHR extensions for gallium drivers,
and it seems it can be implemented pretty fast: It would need the
support of __DRIimage v8, and there are pending patches on the
Mesa mailing list to support partially __DRIimage v7. The remaining
functions look not to need to much work to implement.

I think it's worth it to implement the helpers pixmap to fd and
fd to pixmap in glamor.
Without this, the DDX would have to attach a bo everytime
it can when creating a pixmap, to be able to export an fd:
It would prevent glamor from fallback to the cpu.

If we rely on glamor to export the fd, glamor knows the
pixmaps for which it never exported any fd,
and that it can fallback to the cpu for them.

Axel Davy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/glamor/attachments/20131119/394591af/attachment.html>