ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
pcercuei has quit [Quit: dodo]
mvlad has joined #etnaviv
lynxeye has joined #etnaviv
f_ has joined #etnaviv
pcercuei has joined #etnaviv
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
<bl4ckb0ne> austriancoder: are you around today or already on holiday?
<austriancoder> bl4ckb0ne: ManMower: I can reproduce you issues with mesa 24.2.0-devel and kernel 6.9-rc6 (Vivante GC7000 rev 6009).
<bl4ckb0ne> thats a good news
<austriancoder> bl4ckb0ne: I will do some hacking today and tomorrow night .. after that I might find an hour here or there
<bl4ckb0ne> we'll continue on this with ManMower, do you have any relevant docs/code we should read?
<austriancoder> bl4ckb0ne: sadly not.. I think that these XSVX GPUs might need some special handling in the kernel. But can you tell more the next hours
<ManMower> if there's anything we can investigate in parallel to reduce your load...
<ManMower> and we really appreciate your looking into this!
<ManMower> unsure if it's a useful datapoint, but while running the glmark2 desktop test, if I use ETNA_MESA_DEBUG=no_supertile then instead of a gpu hang the content eventually becomes completely corrupt (right at the time I'd normally see a hang)
f_ has joined #etnaviv
cphealy has joined #etnaviv
<ManMower> also, I think the XSVX requires the same clock gating fix as some other GC7000 series (noticed this in the gal kernel driver) - but enabling that didn't make these hangs go away.
<austriancoder> yeah.. that clock gating fix is in 6.9-rc6
<austriancoder> so from a quick look at the hwdb entries for both gc7000 variants I have I think it is fixable in the user space.
<austriancoder> will be away from the pc for the next 3-4 hours and continue later
sergi has quit [Quit: Client limit exceeded: 20000]
<lynxeye> bl4ckb0ne: As I just saw it in the backlog: address 0 is in fact special. The kernel driver keeps this address unmapped, as most of the internal state registers are 0 initialized after a GPU reset, so if the userspace forgets to set a address register, there's a good chance that it will fault on this unmapped range.
<bl4ckb0ne> that's for the MMU fault?
<lynxeye> bl4ckb0ne: yep
<bl4ckb0ne> thats good to know, thanks
lynxeye has quit [Quit: Leaving.]
f_ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]