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

[Marek Olšák]

Also, to clear up some confusion about libdrm_amdgpu, there is always
one amdgpu_device instance per device (not per fd, reopened and dup'd
fds are matched to one device and one instance). (Also, the uniqueness
of amdgpu_device extends to amdgpu_winsys and pipe_screen, because the
winsys only creates one instance of itself and one pipe_screen for
each unique amdgpu_device_handle. This is a requirement for GL-VDPAU
interop, which requires one pipe_screen per process, but I digress.)
amdgpu_device also maintains a list of existing buffer handles, and
buffer imports and exports are skipped if the handles are known. This
means that amdgpu_bo instances aren't recreated when doing an export
and then import to another client.

Marek

On Fri, Feb 5, 2016 at 10:31 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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