[Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

Mon Apr 9 10:57:46 UTC 2018

Thanks for the response. I'm a bit confused. What is the difference 
between a PRIME handle and a generic DMABUF file descriptor? I'm 
importing a buffer from V4L2 into an Nvidia context. So the FD is backed 
by the V4L2's vb2_queue used in the UVC driver which provides the FD by 
using the VIDIOC_EXPBUF ioctl. I doubt that there is a GEM object 
associated with it at all, as V4L2 is probably not aware of GEM, is it?

I would have guessed, that the use case would be quite common, as having 
a Live video source rendered via OpenGL shouldn't be a very special 
topic and having a zero copy approach should be better than having to 
copy the data all the time. Would allocating a buffer in the GPU and 
exporting it via eglCreateDRMImageMESA an option. Then I would have to 
import that buffer into V4L2 via V4L2_MEMORY_DMABUF. But as 
eglCreateDRMImageMESA only accepts EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 
it's not very flexible regarding V4L2 input formats. Apart from that, I 
think those buffers use GPU specific tiling/swizzling, so V4L2 won't be 
able to properly write data into it. So having the GPU importing the 
buffer from V4L2 seems to be more straight forward to me and as the i915 
is able to do exactly this, and the code/interfaces are the same for 
nouveau I wouldn't expect the nouveau driver to behave differently.

On 06.04.2018 19:58, Ilia Mirkin wrote:
> 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

-- 

* *

*Volker Vogelhuber* | Head of Software Design

*PENTAX**Medical
*/Excellence in Focus/

*T:* // +49 (0)821 650566-18  | *F:* +49 (0)821 650566-20

Hoya Corporation – Pentax Medical Division

*Digital Endoscopy GmbH*

Paul-Lenz-Str. 5

86316 Friedberg – Germany

pentaxmedical.com

*Curious*about new *PENTAX*Medical products and activities?

*Follow us*on our Social Media channels!

   <https://www.linkedin.com/company/pentax-medical-company>
<https://www.youtube.com/channel/UCn2Ge1Wr7YsPZQiZ25nCkuA>

Handelsregister HRB 27226

Amtsgericht Augsburg

Geschäftsführer: Michael Drexel, Gerald Bottero

_____________________________________

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.