11:03 <schramm> Hi. We're trying to play video on an i.MX6 with Qt and GStreamer as backend and I guess we're also bitten by this bug: https://bugreports.qt.io/browse/QTBUG-95819

11:03 <schramm> My GPU and OpenGL knowledge is limited and I'm trying to understand if fixing this while using etnaviv is possible at all.

11:03 <schramm> According to the comments: "It relies on Vivante (the GPU vendor) specific OpenGL extensions that, combined with GStreamer, allow zero-copy video decoding into an OpenGL texture. These are not available when using the reverse-engineered, open-source graphics stack based on Mesa and Etnaviv."

11:03 <schramm> And the last question in the comments is still unanswered: "Do you have any ideas how this (zero copy to opengl texture) could be done with OSS drivers?"

11:08 <lynxeye> schramm: etnaviv support zero-copy import of dmabuf video buffers via EGL images and GL OES_EGL_image_external, same as all the other open-source drivers. No need for any specialized extensions just for Vivante hardware.

11:09 <schramm> lynxeye: Thank you.

11:11 <lynxeye> gstreamer glupload has a direct import path to take advantage of that, but the sink need to know how to handle OES external textures for this path to be negotiated. I have no idea what the Qt videonode is doing in that regard.

11:12 <lynxeye> A colleague of mine is working on supporting this in the qmlglsink for qt6.

11:14 <schramm> Sounds interesting, we're also using QML for video playing. Is his code already available somewhere?

12:06 <lynxeye> schramm: Not yet, but the intention is to upstream the patches, so they should show up as soon as they are working as intended.

12:12 <schramm> lynxeye: Good to hear. Will this then end up in Qt src or GStreamer src? I just stumbled upon GstGLQt6VideoItem and this might also be a workaround for now as far as I understand, but would at least require some code rewriting.

14:50 <cphealy> not that it'

14:50 <cphealy> s needed but I can attest to this zero-copy method with etnaviv with Qt plugin. I used to use this architecture and it worked great!

19:07 <marex> I've been experimenting with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418 and gstreamer NV12 playback -> dmabuf -> GPU import

19:08 <marex> I noticed I need ETNA_MESA_DEBUG="no_ts" else I get the corruption

19:08 <marex> austriancoder: lynxeye: ^ any idea why I need to disable the TS ?

19:08 <marex> that's on MX8MM, so GC600

19:10 <mntirc> > 4 years ago

19:10 <mntirc> wow

19:12 <marex> mntirc: I got it mostly going

19:12 <marex> mntirc: see the end, there is a hint on how-to

19:19 <lynxeye> marex: I don't exactly know how the YUV tiler works, but given that it uses the usual RS kicker, the MC might look at tile status when enabled for the source fetch.

19:20 <lynxeye> to avoid this you may need to clear the fast clear bit in TS_MEM_CONFIG before kicking the YUV tiler

19:21 <lynxeye> and flush the TS cache before and set ETNA_DIRTY_DERIVE_TS afterwards

19:21 <marex> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418#note_2448115 like that ?

19:21 <marex> (part of it anyway)

19:23 <lynxeye> Yep, that seems mostly right. Just also set TS_MEM_CONFIG to 0 after the TS cache flush.

19:26 <marex> lynxeye: nope, that hangs the rendering

19:26 <marex> lynxeye: but I think you might be onto something

19:26 <marex> sec

19:29 <marex> shouldn't I clear the depth/color fast clear bits in ctx->framebuffer.TS_MEM_CONFIG and then write it into TS_MEM_CONFIG ?

19:30 <marex> hmmm, seems like any manipulation with TS_MEM_CONFIG causes a hang, hmmm

19:30 <lynxeye> nope, just emit TS_MEM_CONFIG 0 and then set both ETNA_DIRTY_TS and ETNA_DIRTY_DERIVE_TS

19:30 <lynxeye> the state dirty will make sure the framebuffer TS state is correctly emitted next time it is used

19:31 <lynxeye> scratch that, you only need the DIRTY_TS

19:31 <marex> ahhh

19:32 <lynxeye> DERIVE_TS would only be needed if the RS operation changed the validity of the destination surface TS

19:33 <marex> hah

19:35 <marex> so yeah, setting dirty DERIVE_TS and emitting TS_MEM_CONFIG 0 did the trick, thanks

19:53 <marex> lynxeye: I dumped the patch into the MR so others can use it

19:55 <austriancoder> marex: why not just update the MR with your latest version?

19:56 <marex> austriancoder: isnt it pushed from your repo ?

19:56 <marex> austriancoder: it is backed by your repo on fdo gitlab that is

19:57 <austriancoder> marex: you should be able to push -f to it. But I can do it in some minutes.

19:57 <marex> austriancoder: better review it so it isn't utter garbage full of bugs