[Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Ilia Mirkin]

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.vogelhuber at 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[0] );
>
> 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
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev