02:12 dcbaker[m]: pendingchaos it looks like you have the last open MR for the 20.2 branch.
06:24 Yuti: include/linux/atomic-arch-fallback.h:84:16: error: typename in expression getting this error while running sparse tool for drm bridge drivers
07:04 danvet: airlied, reply in random thread, but someone else spotted the vmwgfx oops on boot
07:28 airlied: danvet: they didn't bisect then
07:29 airlied: I suppose I could do a bit of bisecting tomorrow or next week if nobody shows up
07:31 danvet: yeah I asked them too, maybe you get lucky
07:32 danvet: airlied, oh also have you seen sfr being unhappy with us
07:43 pq: danvet, Should userspace prepare for dynamically appearing and disappearing writeback connectors, just like it has to prepare for normal connectors?
07:45 danvet: thus far it's only mst connectors that pop up and disappear
07:48 airlied: danvet: the nouveau one or the dt one?
07:48 danvet: airlied, ?
07:48 danvet: oh the sfr
07:49 danvet: Subject: Re: [PATCH] drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
07:49 danvet: airlied, the amdgpu one :-)
07:50 pq: danvet, I suppose so. So is it so that the kernel is already beyond the point of making any other kind of connector appear/disappear?
07:51 airlied: danvet: oops fial :-p
07:52 airlied: fali even
07:52 pq: the connector handling code in Weston does handle all kinds of connectors appearing/disappearing the same, but that we are adding writeback support, the code paths will diverge, and in the current MR the writeback connectors cannot appear/disappear
07:52 airlied: yeah i probs resolved that wrong, it doesnt ring any bells
08:01 danvet: pq, currently all connectors can be hotplugged in theory
08:01 danvet: pq, I think for writeback maybe good if we add explicit kerneldoc that these cannot disappear/appear at runtime?
08:01 danvet: feels like reasonable limitation
08:02 danvet: at least until someone comes around and implement hotplug for plane/crtc and everything else :-)
08:44 pq: danvet, sure - I wonder if anyone has writeback connectors implemented purely in software constructs, meaning there could be a variable number of them depending on resource usage.
08:44 pq:looks at rpi
08:45 danvet: we'll do the same as for plane
08:45 pq: heh
08:45 danvet: we just instantiate enough for everyone
08:45 danvet: and then you might get an EINVAL if you use too many
08:46 pq: ok, thanks, I'll let the "writeback connectors cannot come or go" code through then :-)
09:41 pendingchaos: dcbaker[m]: is there a question?
09:42 pendingchaos: it's fine to branch without it
09:51 bnieuwenhuizen: pendingchaos: then remove from the milestone probably?
09:52 pendingchaos: done
12:06 Caterpillar2: hi there, concerning my bugreport "[amdgpu] screen corrupted and no longer responsive when using ffmpeg with vaapi acceleration" I have just uploaded a sample file so you can run your tests https://gitlab.freedesktop.org/mesa/mesa/-/issues/3332#note_590903
12:56 dviola: hi, I'm curious to know if this will go into 4.9: https://patchwork.kernel.org/patch/11601533/
14:53 dcbaker[m]: pendingchaos: sorry for the incomplete question, I got interpreted I'm the middle of that and never got back to it 🙄
14:53 dcbaker[m]: I'll branch 20.2 later today then
16:41 dcbaker[m]: I've started the 20.2 branch process.
20:18 austriancoder: tomeu: I saw 76330374413ee8ab857aa35f249652867be8981e but no docs on how to setup "a caching MinIO instance local to the DUT" - could you add one somewhere under docs/ci/ ?
20:45 curro:needs some sort of branch divergence analysis in the back-end
20:46 curro: does anyone have something close to working or shall i put something together?
20:46 HdkR: LLVM's radeon backend has one, and I presume ACO has something as well
20:47 HdkR: Or maybe I'm misremembering from sleep deprived
20:48 jekstrand: nir_divergence_analysis
20:50 curro: jekstrand: yes seen that one, but unfortunately it only produces divergence data for values not for control flow constructs which is what i need AFAICT
20:50 jekstrand: Yeah, I think Daniel was going to extend it but that turned out to be very painful.
20:51 jekstrand: Especially "divergent" is harder to define universally for control-flow than it is for values.
20:51 curro: oh? what's the problem? i could guess it's a good place to put the calculations i need since there is quite some overlap with value divergence analysis
20:51 jekstrand: I don't remember off-hand
20:52 curro: is Daniel on IRC?
20:52 jekstrand: Not today
20:52 jekstrand: dschurmann
20:52 airlied: dschuermann: ^
20:52 dschuermann: curro: I have somewhere a branch where I defined divergent cf with increasing numbers
20:53 jekstrand: Oh, I guess he is here.
20:53 jekstrand: IRSSI auto-complete failed me. :-(
20:53 dschuermann: :P
20:54 curro: dschuermann: hmm.... what do you mean by increasing numbers?
20:54 dschuermann: that on nested divergent cf a higher number means more divergence
20:56 dschuermann: so, a per cf_node divergence. it doesn't tell too much but you quickly know if divergence increases or decreases between blocks
20:57 curro: dschuermann: ahh. i don't really need to know how divergent the branches are (since it's kind of hard to know that in the first place without runtime information). a binary computation (is this control flow construct guaranteed to be executed uniformly?) would be sufficient for me
20:57 dschuermann: for our backend, we currently just keep track weather we are in divergent cf or not
20:58 curro: dschuermann: right. would be nice to avoid duplicating that logic in our back-end too
20:58 dschuermann: curro, you can do that easily: just keep track on all if-conditions if these are uniform or divergent
20:59 dschuermann: with a short extra iteration over loops for continue/break
20:59 HdkR: curro: Is this divergence analysis for Turing?
21:01 dschuermann: curro: ping me next Monday if you need help. I can try to find my old branch or explain the logic, but won't be back before Monday
21:02 curro: dschuermann: yeah, branches are easy, but loops are non-trivial enough that it would be nice to put the code in some central place, particularly because nir_divergence_analysis kind of needs to know that already in order to know whether some value is uniform...
21:02 curro: dschuermann: oh, would be nice if you point me at your branch
21:13 curro: HdkR: nope, it's for the intel back-end IR performance model, together with other changes I'm working on it will allow me to enable SIMD32 in more cases than we do now, since branch uniformity can have quite an impact on the performance of SIMD32 relative to SIMD16
21:15 dschuermann: curro: seems I have it only locally somewhere, currently. the quick and dirty solution for loops is to check if there are divergent breaks/continues somewhere. it covers probably the 99% correctly
21:17 dschuermann: then, it depends what divergence means for you: do all invocations have to participate on this path or do the active invocations have to continue on the same path, i.e. what is a uniform continue statement after a divergent break?
21:22 curro: dschuermann: i care about the divergence of control flow constructs as a whole, therefore a loop would have to be considered divergent if it has any divergent break, whether or not there is a continue afterwards
21:22 HdkR: ah
21:23 curro: dschuermann: hm, if i have to type this in i'm kind of leaning towards modifying nir_divergence_analysis, though i guess i could write a pass for the intel back-end instead
21:28 dschuermann: curro: okay that would fit quiet nicely for what I already wrote. I'll try to find it. maybe gitlab MR history gives us something
21:32 dschuermann: curro: here you go, although a bit outdated: https://gitlab.freedesktop.org/daniel-schuermann/mesa/-/commits/nir_fix_derivs/
21:33 dschuermann: just the nir_divergence_analysis patches
21:33 curro: dschuermann: thanks!
23:29 Vanfanel: Hi! Is there a way to know if an EGLSyncKHR has already been destroyed? I need to wait for the same fence and destroy it in different points in my code (no different threads involved), but doing eglClientWaitSyncKHR(EGL_FOREVER_KHR) on a destroyed EGLSyncKHR will never return...
23:30 Vanfanel: So I guess the only wait to do this is to know beforehand if the EGLSyncKHR is already destroyed before doing an eglClientWaitSyncKHR(EGL_FOREVER_KHR) on it