[Mesa-dev] Question about how to implement gl sharing extension in Open CL C with mesa

[Zhigang Gong]

Hi,

I'm developing gl sharing for Open Cl 1.1 implementation. My current solution is to
use the existing interface and extension to export a gl texture/buffer object to the
OpenCL domain, and create an cl memory object from the same buffer object(drm level).
But I met some gaps with current mesa implementation.

First, I want to talk about the gl 2d/3d texture sharing problem.
The basic idea is to use EGL_KHR_gl_texture_3D_image and EGL_KHR_gl_texture_2D_image
extension to create an EGL image from the 2d/3d textures, then use EGL API to get the
image's attribute and the image's bo's name. But I found there is no way to get the
image's detail attributes which are width/height/format/... . I also found that this
is as desgiend according KHR_image_base spec:

    3.  Should attributes (width, height, format, etc.) for EGLImages
        be queriable?

        SUGGESTION:  No.  Given the wealth of attributes that we would
        need to specify all possible EGLImages (and possible
        memory layout optimizations performed by implementations), we
        can dramatically simplify the API without loss of key
        functionality by making EGLImages opaque and allowing
        implementations to make the correct decisions internally.

But we do need to query these attributes when we want to create a CL memory object
from a gl texture/egl image. Another reason is that GLES doesn't provide APIs to
get a texture's width/height/internal format neighter.

I just wonder is there any possibility to provide such functions at the image extensions layer?
If no, then one alternative solution is to leverage gbm's capability. And we do need to
extent the GBM's interface to create a GBM device from a existing egl  dri2 display. Then
we can use GBM's API to query those attributes. Current GBM only support to create a new
GBM device as a new dri loader. Thus it can't be used to access the images created from
the existing EGL context. Is it doable/acceptable to add a new way to create a GBM device
from an existing egl dri2 display?

Or is there any other way to achieve the same goal more gracefully?

Second, back to the gl buffer object sharing problem.
If either the above two issues get fixed(extent EGL image extension or extent gbm
library), we can achieve the goal to share a gl 2d/3d texutres with Open CL. But
we still can't achieve the same goal with buffer object. As there is no any extension to export
a buffer object. I don't have any good idea about this point. Is there any suggestion
for the buffer object sharing with OpenCL in mesa?

Looking forward to your valuable suggestion/feedback.

- Zhigang
Thanks.