[Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Volker Vogelhuber]

On 09.04.2018 15:56, Ilia Mirkin wrote:
> On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber
> <v.vogelhuber at digitalendoscopy.de> wrote:
>> 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?
> Right, there probably isn't. I'm also not 100% sure it's required,
> just seemed like it may be based on a quick glance at the code.
I don't think that it is required, as I can see the texture and the data 
is updated with the real camera image. It's just that the stride seems 
to be wrong and playing around with the EGL_DMA_BUF_PLANE0_PITCH_EXT 
parameter did not solve the problem either. Maybe I can play around with 
the Virtual Video Test Driver to check if a power of two resolution 
solves the stride problem. It would also allow to setup a minimal code 
example that illustrates the problem to others.

>> 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
> Having a live video source is a pretty special topic. (Esp having one
> that you ever use.)
Well, now I'm surprised. :-)


>> 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.

> Well, clearly it does. I'm not particularly surprised, since, like I
> said, it seems likely that you're the first to attempt it (or at least
> inquire as to its failure after attempting it). If you're interested
> in debugging this, I'd recommend joining #nouveau on irc.freenode.net.
> Otherwise, focus on hardware whose makers invest in open-source GL
> drivers -- i.e. not NVIDIA.
Actually we normally do use Intel hardware. It's just that on my 
development machine I have an i9 without onboard GPU and so I had to use 
an Nvidia card. I doubt I have enough insights in the nouveau driver 
code that I can help in debugging this. Maybe I will find some time to 
prepare some simple example for that use case, so other developers may 
be able to find the reason for that behavior more easily. But for now I 
will fallback to glTexImage2D on Nvidia.

Thanks for your insights.