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

[Marek Olšák]

On Fri, Feb 5, 2016 at 8:31 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> 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?

Yes, because the radeonsi driver can't translate a GL texture object
into a pipe_resource. This must be done in a component that has access
to struct gl_context.

Also, libGL is the only library that can convert GLXContext to
__DRIcontext. On the other hand, the *_dri.so module is the only one
that can convert __DRIcontext to gl_context, so multiple components
will have to be touched, most probably these:
- libGL (GLXContext -> __DRIcontext)
- libEGL (EGLContext -> __DRIcontext)
- dri_interface.h (receives __DRIcontext regardless of API)
- st/dri (__DRIcontext -> gl_context & pipe_context; GL handle ->
pipe_resource; call resource_get_handle)
- gallium interface (passing the "flags" parameter to resource_get_handle)
- radeonsi (set buffer metadata via libdrm; eliminate CMASK; eliminate
DCC if flags != read-only, etc.)

>
> 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.

The reason for that is that OpenCL can't check if the target is valid,
so Mesa has to do it and return an error accordingly.

>
> 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.

We can't do that, because libdrm doesn't understand GL texture handles.

>
> 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?

Only ~1024 open DMABUF handles are allowed per process, which means we
can simply use all negative values for errors. The exact errors
returned by the functions are still to be determined.

Marek