Is the dma buf backed by a GEM object? In nouveau_screen_bo_from_handle, we assume that it's a PRIME handle, and look up the associated GEM object.
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_screen.c#n90 https://cgit.freedesktop.org/mesa/drm/tree/nouveau/nouveau.c#n789 Not sure if this is correct. Is this DMABUF even in system memory? Otherwise this whole thing can't work. I think you may be the first to explore this use-case, so expect a bumpy road ahead. Note that rendering to sysram = very slow, so you probably will just want to copy such texture objects to vram (i.e. just create a new texture, and use glCopyImageSubData). Depends on precisely what you're doing, I suppose. Cheers, -ilia On Fri, Apr 6, 2018 at 1:33 PM, Volker Vogelhuber <v.vogelhu...@digitalendoscopy.de> wrote: > Not sure if this is the right mailing list, or if the problem may belong to > the libdrm part. > I'm currently trying to import a DMABUF from V4L2 UVC source (using > VIDIOC_EXPBUF) into OpenGL using EGL_LINUX_DMA_BUF_EXT. While this is > working fine with the i915 driver it fails with the Nouveau driver. > As a test case I have a UVC camera with a resolution of 400x400 and an 8bit > raw bayer format. So the following attributes are set during the EGL image > creation: > > // Texture width > attrs.push_back(EGL_WIDTH); > attrs.push_back(400); > // Texture height > attrs.push_back(EGL_HEIGHT); > attrs.push_back(400); > // Color > attrs.push_back(EGL_LINUX_DRM_FOURCC_EXT); > attrs.push_back(DRM_FORMAT_R8); > // FD > attrs.push_back(EGL_DMA_BUF_PLANE0_FD_EXT); > attrs.push_back(fd); > // Offset > attrs.push_back(EGL_DMA_BUF_PLANE0_OFFSET_EXT); > attrs.push_back(0); > // Pitch > attrs.push_back(EGL_DMA_BUF_PLANE0_PITCH_EXT); > attrs.push_back(400); > > eglCreateImage( eglGetCurrentDisplay(), EGL_NO_CONTEXT, > EGL_LINUX_DMA_BUF_EXT, NULL, &attrs ); > > So far no error or any other problem. But when I want to render the image it > is distorted, like if the stride is not correct. I debugged into the system > libraries but couldn't find any code that may give a hint if there are some > constraints to be met regarding the stride when importing a DMABUF into the > nouveau driver. The only thing I found was while the size of the V4L2 buffer > is 400x400x1 = 160000 the size returned by > > drmCommandWriteRead(drm->fd, DRM_NOUVEAU_GEM_INFO, &req, sizeof(req)); > > in the libdrm nouveau part returned a page aligned size of 163840 bytes. > > While the sample case with this camera only resulted in a wrongly displayed > image, I also have another V4L2 source with RGBX format where using the > texture with DMABUF even results in a total crash of my machine. I haven't > debugged that case further as I wanted to resolve the issue with the 400x400 > image first (debugging is easier if the machine does not freeze all the > time). > > I'm currently running Ubuntu 17.10 with libdrm 2.4.83 and mesa 17.2.8. So > the libraries are not the most current one. Are there any known issues for > my use case? > > _______________________________________________ > mesa-dev mailing list > email@example.com > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev