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

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