15:59 <mntmn> btw TFA might be the culprit for sleep/wake problems on iMX8M, right? are there any mainline experiences with that?

16:02 <lynxeye> mntmn: TFA was the place where they tried to hide the workarounds for the fact that they just forgot to connect the wake request signal from the GIC (irq controller) to the CPU cores

16:04 <marex> lynxeye: where they bury the dead bodies

16:04 <lynxeye> so local IRQs that aren't routed through the GPC secondary controller aren't able to wake the cores

16:06 <lynxeye> marex: yea, the workaround for this specific issue was in fact so ugly, that I wouldn't call it dead body. It was more like a zombie.

16:08 <marex> heh

16:12 <sravn> Anyone that has upscaling workign with the imx? In my case a quad core imx with a LVDS panel connected with 1280x800 and an application that requires 800x480

16:13 <sravn> I hope the image converter in the IPU can do the trick but it supports 1024x1024 as maximum.

16:13 <sravn> And the drm/imx driver seems not to support the image converter in upstream

16:14 <cphealy> Buffers larger than 1024x1024 can be supported. The IPU's image converter just needs to do it in multiple passes.

16:15 <cphealy> I wonder though, if your application can be run on top of Weston, you could have Weston scale the window fullscreen using the 3D GPU. Is that an option?

16:15 <lynxeye> and multi-pass is fundamentally incompatible with the DRM model (at least if you don't count writeback connectors)

16:16 <lynxeye> so we never supported this in imx-drm

16:50 <mntmn> lynxeye: ah yeah, understood. i even saw this patch

17:00 <pcercuei> < cphealy> Buffers larger than 1024x1024 can be supported. The IPU's image converter just needs to do it in multiple passes.

17:00 <pcercuei> can't you do mem-to-mem, and pass the result to the DRM driver using prime?

17:01 <sravn> the quadcore has a GPU and we are running chromium on top of the open source etnaviv in the normal case

17:02 <sravn> In this case we are running a Qt application, IIRC correct using egl so almost like on a framebuffer, thus using the GPU may prove difficult I think

17:02 <sravn> pcercuei: no idea about the mem-to-mem case

17:04 <sravn> lynxeye: maybe multi-pass is not fully drm compliant, but as a local hack it may be used then?

17:19 <lynxeye> sravn: it's significant effort and will get in the way whenever you want to do a kernel update if you keep it as a local hack

17:20 <lynxeye> adding a wayland compositor to the picture between DRM and and the Qt app to let it handle the rescaling with the GPU seems like a better long term strategy

17:25 <sravn> lynxeye: so the quick conclusion is that there are possibilities - good. I will ask my day$ job to contact you guys on the subject

23:13 <mntmn> dos1: sorry i don't have gitlab acc on my phone atm. so you figured already you need the env var

23:13 <mntmn> dos1: automatic detection on when to disable earlyz is not a part of this MR. that would be a different patch/MR.

23:13 <mntmn> referring to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5456#note_597747

23:15 <dos1> yeah, of course figured that out right after sending the comment :D

23:16 <mntmn> dos1: i would prefer to get this MR in first and then experiment maybe together with others on how to get the detection right. i guess the shader needs to be checked (there is a uses_discard or similar flag somewhere), maybe other things

23:16 <dos1> sure, makes perfect sense

23:16 <mntmn> ok

23:19 <dos1> FYI: I've bisected hangs I've been seeing since mesa 20.1 (like neverball glitching and completely hanging the compositor) and it turned out that it's related to anisotropic filtering support - reverting that patch makes them go away https://gitlab.freedesktop.org/mesa/mesa/-/issues/3409