Re: [Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Ilia Mirkin]

On Wed, Apr 18, 2018 at 6:04 AM, Volker Vogelhuber
 wrote:
> On 17.04.2018 15:44, Pekka Paalanen wrote:
>> If Nouveau cannot handle that correctly, it would hopefully refuse the
>> import.
>
> Although it would not solve my problem, it would be at least a proper
> handling of the API calls. I still doubt the implementations is not
> supported, as I got the image data rendered. It's just it is not rendered
> correctly. So it seems like data transfer is successfully done in general,
> but only not with the right parameters.

My leading theory is that NVIDIA hardware can only texture/render from
linear surfaces with pitch (and offset) aligned to 64 bytes.
Unfortunately this is something of a pain to test without all the
proper setup, but it's something I'll hopefully get to. If that theory
pans out, we'll start failing the imports of such images.

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Volker Vogelhuber]

On 17.04.2018 15:44, Pekka Paalanen wrote:

On Mon, 9 Apr 2018 09:56:43 -0400
Ilia Mirkin  wrote:


On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber
 wrote:

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


FWIW, in Wayland architecture this would be the preferred path to play
back video. A hardware decoder or a camera provides frames via V4L2
API, which the player app sends to a Wayland compositor as dmabuf fds,
which then imports them via EGL to GL for GPU compositing or directly to
KMS for hardware overlay plane.

Weston the compositor does the EGL import, and should "soon" do the KMS
import as well automatically when possible. It also has a test app
weston-simple-dmabuf-v4l which uses a V4L device to provide dmabuf and
send them to the compositor for importing. It has instructions on how
to set up vivid for testing.
Interesting, if I find the time I will have a look at this test app. 
Unfortunately I doubt this will be the case very soon.



Volker, did you try querying V4L2 for the right pitch, ensure you got
bytes vs. pixels correct, and feed that into
EGL_DMA_BUF_PLANE0_PITCH_EXT?
I played around with the pitch values. Although the value (400) itself 
seems to be correct, as the i915 implementations handles it correctly, 
it seems like changing the pitch value does not have any effect until I 
change it to 16. Then it suddenly has an effect, but one that seems to 
be too much. So instead of having a distortion to the right I have one 
to the left. That brought me to the conclusion that there might be some 
alignment restrictions anywhere in the code, but I couldn't find any 
check or change of the pitch or width value.
I still wonder where the information of 163840bytes for the whole buffer 
size comes from when calling drmCommandWriteRead(drm->fd, 
DRM_NOUVEAU_GEM_INFO, , sizeof(req)); Maybe it's just that the 
kernel driver always calculates it's size from page blocks, but even 
then the readout of the buffer should be correct with the given stride 
and pitch.



If Nouveau cannot handle that correctly, it would hopefully refuse the
import.
Although it would not solve my problem, it would be at least a proper 
handling of the API calls. I still doubt the implementations is not 
supported, as I got the image data rendered. It's just it is not 
rendered correctly. So it seems like data transfer is successfully done 
in general, but only not with the right parameters.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Pekka Paalanen]

On Mon, 9 Apr 2018 09:56:43 -0400
Ilia Mirkin  wrote:

> On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber
>  wrote:
> > 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.)

Hi,

FWIW, in Wayland architecture this would be the preferred path to play
back video. A hardware decoder or a camera provides frames via V4L2
API, which the player app sends to a Wayland compositor as dmabuf fds,
which then imports them via EGL to GL for GPU compositing or directly to
KMS for hardware overlay plane.

Weston the compositor does the EGL import, and should "soon" do the KMS
import as well automatically when possible. It also has a test app
weston-simple-dmabuf-v4l which uses a V4L device to provide dmabuf and
send them to the compositor for importing. It has instructions on how
to set up vivid for testing.

Volker, did you try querying V4L2 for the right pitch, ensure you got
bytes vs. pixels correct, and feed that into
EGL_DMA_BUF_PLANE0_PITCH_EXT?

If Nouveau cannot handle that correctly, it would hopefully refuse the
import.


Thanks,
pq


pgpzMNDE85Bfy.pgp
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [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
 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.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Ilia Mirkin]

On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber
 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 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.)

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

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

[Volker Vogelhuber]

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
 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, [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 = 16 the size returned by

drmCommandWriteRead(drm->fd, DRM_NOUVEAU_GEM_INFO, , 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!



  

Re: [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
 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, [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 = 16 the size returned by
>
> drmCommandWriteRead(drm->fd, DRM_NOUVEAU_GEM_INFO, , 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev