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 <mar...@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 <mar...@gmail.com> wrote: > > On Fri, Feb 5, 2016 at 8:31 PM, Nicolai Hähnle <nhaeh...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev