<div dir="ltr">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 :-) </div><div class="gmail_extra"> <div class="gmail_quote">On Sat, Feb 6, 2016 at 2:55 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div><div class="h5"> On Fri, Feb 5, 2016 at 10:31 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: > On Fri, Feb 5, 2016 at 8:31 PM, Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>> 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 <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> </div></div><a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div> </div>