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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
