[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 <imirkin at alum.mit.edu> wrote:
> 
>> On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber
>> <v.vogelhuber at digitalendoscopy.de> 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, &req, 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.