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

[Nicolai Hähnle]

Hi,

On 04.02.2016 17:25, Marek Olšák wrote:
> 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.

Some thoughts: if this information must be queried via a driver-specific 
ioctl anyway, then does it really make sense to define a generic 
exporting interface for textures?

If the consensus is yes, then I'd say the interface looks pretty 
reasonable. Having the textureTarget as a parameter seems to be 
redundant if the layout is attached to the DMABUF. I notice the OpenCL 
interface exposes it though, so I don't feel strongly about it.

If OpenCL lives outside of Mesa but still calls into the kernel via 
libdrm, then it could potentially be more efficient to do the sharing 
via libdrm structures. Should that be done with an additional interface? 
Since they are hw-specific, wiring up such an interface might end up 
being awkward. I think it'd nicer to have these functions return a void* 
which is interpreted depending on the flags.

What's the error handling story? It seems most errors checked by these 
functions would result in CL_INVALID_GL_OBJECT, but perhaps some 
implementations want to signal CL_OUT_OF_HOST_MEMORY. How to distinguish 
between them?

So how about something like this:

int glXBufferExport(GLXContext context, GLuint bufferObj, unsigned 
flags, void **phandle);
... the others analogously ...

#define FLAG_USAGE_READ_ONLY (1 << 0)
#define FLAG_DMABUF (1 << 1)

... and a negative return value indicates an error code.

Cheers,
Nicolai

> Comments welcome.
>
> Thanks,
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>