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

Sat Feb 6 17:53:08 UTC 2016

I'm adding Chad to the Cc.  At some point, it would be good to get Beignet
playing well with mesa.  Personally, I have substantial reservations about
getting the kernel involved in surface layout for anything more than 2-D
non-mipmapped non-array surfaces.  Laying them out can be complicated, and
committing to a stable API, or worse a kernel API seems a bit tricky.  But
I'll let chad rant about that :-)

On Sat, Feb 6, 2016 at 2:55 AM, Marek Olšák <maraeo at gmail.com> wrote:

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160206/f704ba41/attachment-0001.html>