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.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[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@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
