<DPA>
Could I get some feedback on the MR, please?
lynxeye has joined #etnaviv
<marex>
lynxeye: oh hey
<marex>
lynxeye: so apparently the GPU2D can be fixed, the device probes with the AHB bus in some swab32() mode, so if you whack the reset bit of the GPU at the swab32()ed position, the bus behaves again
<marex>
lynxeye: but I'm still seeing some AXI errors on the GPU3D
<lynxeye>
Oh, nice find!
<lynxeye>
What AXI errors are you seeing with the 3D GPU?
<marex>
lynxeye: the GPU indicates AXI errors and the dEQP hangs right on the first test
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #etnaviv
pcercuei has joined #etnaviv
<marex>
lynxeye: did you work on that PGC stuff yourself at all recently ?
<karolherbst>
mind somebody here up for some gnome testing? I am wondering if the kms-modifiers option improves user experience with etnaviv
<karolherbst>
to enable it (as the user running mutter): gsettings set org.gnome.mutter experimental-features '["kms-modifiers"]'
<karolherbst>
I talked with some mutter devs and they seem fine with enabling it for certain devices and was wondering if it would make sense to do that for etnaviv as well
<marex>
karolherbst: what does it do ?
<karolherbst>
enable full drm modifier support
<marex>
karolherbst: if the scanout engine supports the right format which the GPU can render, then it can display it efficiently too ?
<karolherbst>
yes
<karolherbst>
it essentially gets rid of the detiling blit
<karolherbst>
with tegra I noticed it does work much better than doing the blits
<karolherbst>
but that could be because the patches are not optimal or for some other reasons
<karolherbst>
so just wondering how that helps with etnaviv
<marex>
karolherbst: depends on the GPU and the scanout engine capabilities I'd say
<karolherbst>
sure, but afaik with etnaviv you can't render into linear depth buffers, can you?
<karolherbst>
well, except for those blits you do to support it
<marex>
austriancoder: ^
<marex>
lynxeye: I think I've got it all, whack the GPU reset in RPM resume and that puts the AXI back in order even on GPU3D
<marex>
and ... hang ... sigh
<marex>
why do I have a feeling there really is a hardware bug
<mntmn>
karolherbst: i can try it
<mntmn>
karolherbst: interesting, it introduces some bugs. some windows will turn black. seems random
<karolherbst>
okay
<karolherbst>
I saw some flickering as well
<mntmn>
karolherbst: (GC7000L)
<karolherbst>
wondering if that's a mutter or driver bug
<mntmn>
for example the background image went away, and when i change chromiums window size to half of the screen, it turns black
<karolherbst>
but I remember somebody saying somethign about some patches here
<mntmn>
could be synchronisation bug
<karolherbst>
yeah
<karolherbst>
feels like it
<mntmn>
similar to glamor
<mntmn>
with GTK2 and X11-based UIs you also get this flickery thing where draws are not correctly synchronized with etnaviv
<karolherbst>
yeah, that's probably what I am seeing
<mntmn>
but interesting that this has to do with modifiers
<karolherbst>
I am not surprised
<mntmn>
maybe additional blit path "fixes" it by forcing synchronisation
<karolherbst>
if you remove the implicit blit your rendering path is more direct
<karolherbst>
yeah
<mntmn>
yep
<mntmn>
daniels: cc ;)
<marex>
karolherbst: which SoC do you use for testing btw ?
<karolherbst>
jetson nano
<marex>
that's vivante GPU ?
<karolherbst>
no
<karolherbst>
nvidia
<daniels>
hmm, no idea about the Xwayland flickering tbh, but it's not going to be of any use on most etnaviv devices - it's only some of the i.MX8 and also on the i.MX6QP specifically that you can get direct scanout - you need a detiling blit for all other devices since the GPU can't render to linear, and the display engine can't scan out from supertiled
<karolherbst>
daniels: that was with kms-modifiers enabled in mutter
<daniels>
right
<karolherbst>
but yeah.. I guess you have to fight witha dditional restrictions
<marex>
lynxeye: hmmmm, seems like even if I can recover the GPUs sometimes, the system also does suffer AHB bus hangs
<marex>
so I would say, that SRC reset is hiding something
<lynxeye>
marex: I've been busy with other stuff, so couldn't get back to look at the power gating thing in the last few weeks
<lynxeye>
I guess the SRC reset is just able to reset more of the GPU (including the AHB interface)
<lynxeye>
you can't really reset the AHB stuff with a soft reset, as it's the logic you interact with to do the software reset
<marex>
lynxeye: I think it must be somehow wired into the ADB400, yeah
<marex>
lynxeye: I guess getting official statement from NXP that they messed up reset handling would be impossible
<marex>
lynxeye: why does it remind me of MX6Q PCIe ?
<lynxeye>
marex: It isn't messed up, it's just very, very special ;)
<marex>
lynxeye: uh-huh
<mntmn>
marex: so, would you recommend imx8mm for projects? ;)
<marex>
mntmn: about as much as mx6q I guess ?
<marex>
mntmn: I am hoping stm32mp2 would be 64bit
<lynxeye>
marex: mp2? You seem to love waiting...
<marex>
lynxeye: patience is a virtue , or something
lynxeye has quit [Quit: Leaving.]
<mntmn>
marex: mx6q or qp? ;)
BobB3 has joined #etnaviv
<marex>
mntmn: mx6q , that's where they forgot to connect PCIe PHY reset , apparently
<marex>
mntmn: I dont think there ever was any confirmation of it though