14:48 <marex> austriancoder: hey, I was looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418/ again (NV12 blit), since I am running into bandwidth issues on MX8MP, but that is using GPU 3D for the blit, right ? I wonder if it would make sense to also revisit https://lists.freedesktop.org/archives/mesa-dev/2018-July/199703.html this GPU 2D YUV blit, which could take some load off the GPU 3D ?

14:49 <marex> austriancoder: basically I am looking for a way to do pixel format conversion between the VPU there (planar or semiplanar YUV) and lcdif (packet YUV or RGB) , and I think the GPU2D is the way to go , but I am not sure whether this is the right way to integrate that implementation

15:26 <lynxeye> marex: depends on where you want your video to go. The 2D GPU is faster than the 3D GPU and using 2D GPU will reduce load on the underpowered 3D GPU, but if you want to integrate the video in a 3D scene then the yuv tiler is probably the better option as the texture lookup is then still sampling yuv at 16bpp, instead of rgb at 32bpp.

15:57 <marex> lynxeye: I want to pump it directly into lcdif, hence the gpu2d

15:58 <marex> lynxeye: fullscreen that is

15:58 <marex> lynxeye: and sigh, I feel like the subtle design issues of the mx8mp are starting to show up now

15:59 <lynxeye> marex: In that case you might want to talk directly with the 2D GPU in your video pipeline. We did a PoC of a gstreamer element doing this on i.MX6 ages ago.

16:00 <marex> lynxeye: I was thinking about that too, but I dont want to do downstream hacks

16:03 <lynxeye> I don't see why one couldn't upstream such a gst element, aside from the obvious effort to do so.

16:04 <marex> lynxeye: upstreaming it into gstreamer isnt the problem, it doesn't feel really systematic to me

16:05 <marex> lynxeye: like, if I can do ... v4l2sl... ! glvideoconvert ! gldownload (uh) ! kmssink , that would be ... not nice either

16:05 <marex> hmmmmmmm

16:09 <lynxeye> right and going through GL you need to render, so you do the conversion using the yuv tiler or 2d gpu into a internal buffer and then use that to render into the buffer for kmssink. That's more 3D GPU load and bandwidth usage than straight using the 2D GPU to convert between the 2 buffers.

16:10 <marex> lynxeye: indeed

16:11 <marex> lynxeye: lemme think this through one more time

20:41 <marex> hmmm , programming the G2D is suprisingly easy

20:44 <mntirc> marex: oh?

20:49 <marex> mntirc: yeah ... sec

20:50 <marex> mntirc: compile libdrm -- $ meson builddir/ -Dbuildtype=debug -Dtests=true -Detnaviv=enabled && ninja -C builddir/

20:50 <marex> mntirc: edit tests/etnaviv/etnaviv_2d_test.c

20:50 <marex> mntirc: compile and explore -- $ ninja -C builddir/ && ./builddir/tests/etnaviv/etnaviv_2d_test /dev/dri/renderD128 /tmp/etna.bmp

20:50 <marex> mntirc: then observe result in /tmp/etna.bmp

20:51 <marex> mntirc: repeat last two steps until happy

20:53 <mntirc> oh cool

20:53 <mntirc> gotta play around with that soon

20:55 <marex> mntirc: I got nv12 to rgb blit out of it like this https://paste.debian.net/hidden/222571a2/

20:56 <marex> mntirc: mostly copied from the patch link above