[Mesa-dev] MesaGL <-> non-Mesa OpenCL interop interface

[Marek Olšák]

Hi,

I would like to start a discussion about an OpenGL-OpenCL interop
interface where OpenCL is not part of Mesa.

I think the only way to do this is to have Mesa export functions that
convert Mesa OpenGL objects into DMABUF handles. Such functions can be
exported by DRI driver modules or libGL & libEGL, however, it's
possible that the OpenCL stack won't link against libGL & libEGL,
therefore it's not required to expose the interface as GLX/EGL
extensions.

The existing EGL extension for DMABUF exports only works with EGL
images, whereas this needs to work with OpenGL handles directly.

All functions should accept a context pointer, because that's what
OpenCL receives from the user and the context might not be current.

This is the proposed interface for sharing OpenGL buffers and
textures. This is just a draft and will most likely be changed. The
OpenCL stack is expected to obtain there via dlsym(RTLD_DEFAULT):

int glXBufferExportDMABUFHandle(GLXContext context, GLuint bufferObj,
unsigned flags);
int eglBufferExportDMABUFHandle(EGLContext context, GLuint bufferObj,
unsigned flags);
int glXTextureExportDMABUFHandle(GLXContext context, GLuint
textureObj, GLenum textureTarget, unsigned flags);
int eglTextureExportDMABUFHandle(EGLContext context, GLuint
textureObj, GLenum textureTarget, unsigned flags);

#define FLAG_CL_USAGE_READ_ONLY (1 << 0)

Mesa should return a value <= 0 if bufferObj, textureObj, or
textureTarget is invalid. (TBD)

The information about the texture format, texture layout (2D, 3D,
array, mipmap, ...), texture sizes, and hw-specific tiling parameters
is expected to be attached to the DMABUF handle using a
driver-specific ioctl (done by the Mesa driver), and likewise, the
OpenCL stack is expected to query it using a similar ioctl. Right now,
the DMABUF handle is the only piece of information that is publicly
returned to the OpenCL stack.

Comments welcome.

Thanks,
Marek