On 17.04.2018 15:44, Pekka Paalanen wrote:
On Mon, 9 Apr 2018 09:56:43 -0400
Ilia Mirkin <imir...@alum.mit.edu> wrote:
On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber
<v.vogelhu...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
