austriancoder changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs
cyrozap has joined #etnaviv
_whitelogger has joined #etnaviv
lynxeye has joined #etnaviv
_whitelogger has joined #etnaviv
berton has joined #etnaviv
T_UNIX has quit [Quit: Connection closed for inactivity]
T_UNIX has joined #etnaviv
pcercuei has joined #etnaviv
<mntmn> btw TFA might be the culprit for sleep/wake problems on iMX8M, right? are there any mainline experiences with that?
<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
<marex> lynxeye: where they bury the dead bodies
<lynxeye> so local IRQs that aren't routed through the GPC secondary controller aren't able to wake the cores
<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.
<marex> heh
<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
<sravn> I hope the image converter in the IPU can do the trick but it supports 1024x1024 as maximum.
<sravn> And the drm/imx driver seems not to support the image converter in upstream
<cphealy> Buffers larger than 1024x1024 can be supported. The IPU's image converter just needs to do it in multiple passes.
<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?
<lynxeye> and multi-pass is fundamentally incompatible with the DRM model (at least if you don't count writeback connectors)
<lynxeye> so we never supported this in imx-drm
mth has quit [Remote host closed the connection]
<mntmn> lynxeye: ah yeah, understood. i even saw this patch
mth has joined #etnaviv
<pcercuei> < cphealy> Buffers larger than 1024x1024 can be supported. The IPU's image converter just needs to do it in multiple passes.
<pcercuei> can't you do mem-to-mem, and pass the result to the DRM driver using prime?
<sravn> the quadcore has a GPU and we are running chromium on top of the open source etnaviv in the normal case
<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
<sravn> pcercuei: no idea about the mem-to-mem case
<sravn> lynxeye: maybe multi-pass is not fully drm compliant, but as a local hack it may be used then?
<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
<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
<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
Chewi_ has joined #etnaviv
Chewi has quit [Ping timeout: 265 seconds]
Chewi_ is now known as Chewi
T_UNIX has quit [Quit: Connection closed for inactivity]
berton has quit [Quit: Leaving]
lynxeye has quit [Quit: lynxeye]
Surkow|laptop has quit [Quit: Bye bye - Laptop goes to sleep - NOP NOP NOP]
Surkow|laptop has joined #etnaviv
eightdot has quit [Ping timeout: 240 seconds]
tlwoerner has quit [Quit: Leaving]
pcercuei has quit [Quit: dodo]
<mntmn> dos1: sorry i don't have gitlab acc on my phone atm. so you figured already you need the env var
<mntmn> dos1: automatic detection on when to disable earlyz is not a part of this MR. that would be a different patch/MR.
<dos1> yeah, of course figured that out right after sending the comment :D
<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
<dos1> sure, makes perfect sense
<mntmn> ok
<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