10:09adavy: Would someone know if it is required to release a mutex after a cnd_signal and not before ? Basically I have a thread that waits a variable to be 1. check the variable with a mutex, and release the mutex with cnd_wait to wait the other thread changes it. The other thread locks the mutex, changes the variable, calls cnd_signal, and then unlocks the mutex. I want to know if I can unlock the mutex before
10:09adavy: the cnd_signal.
10:10adavy: With nine multithreading, I have a benchmark where I can see a lot of time is spent somehow in these mutexes, and if I move the signal after the unlock, that goes away. But I don't know whether this is legal.
10:12adavy: I can see why this hurts performance to not release it before the cnd_signal (the other threads wakes up, to find that the mutex is already held, which is heavy)
10:42adavy: according to the docs I read, this seems to be legal
11:39emersion: swick[m]: displayid 2.1 has an adaptive sync with flags and values for flickering and rate changes
11:39emersion: section 4.9
11:39emersion: an adaptive sync block*
11:41emersion: it's new in 2.1, can't find it in either 1.x nor 2.0
12:21MrCooper: nice, here's hoping the values in there will be accurate
12:23emersion: the VESA CTS requires these to be accurate
12:23emersion: so there's at least _some_ hope
12:23emersion: also an issue is that we still can't read displayid
12:24emersion: kernel doesn't expose it, so we don't even know what's in there
15:47ishitatsuyuki: adavy: yes, this is a well known problem, but it's well known enough that common pthread implementations specifically have mitigations for this case
15:48ishitatsuyuki: in short, when a condvar is signaled with the mutex locked, it should use FUTEX_CMP_REQUEUE to move the waiter from waiting on the condvar to wait on the mutex instead
16:18saikat: Hello Sir! Help wanted.. about freedreno gallium driver modification.. anyone can help?
17:37DavidHeidelberg[m]: saikat: try #freedreno channel
17:41saikat: Okay thank you.. will try..
20:32HdkR: Is it just me or is it when an application uses EXT_swap_control_tear, it overrides `vblank_mode`?
20:46HdkR: Looks like if `GLX_LATE_SWAPS_TEAR_EXT` is used then it overrides vblank_mode=0
20:47HdkR: Or just this game is /really/ good at timing to 60
20:48HdkR: Seems to be the case
20:53graphitemaster: Is there a reason AMD_shader_ballot and the KHR extensions are not supported in OpenGL on radeonsi. It's interesting that these GLSL extensions work fine on Windows on NV and AMD (I understand they're Vulkan/SPIRV primarily) but it's making it hard to port some stuff to Linux :(
20:54graphitemaster: Sitting here polyfilling most of the arithmetic with loops and readInvocationARB
20:56HdkR: You get GL_ARB_shader_ballot right?
20:59graphitemaster: Yeah, but no GL_AMD_shader_ballot or GL_KHR_shader_subgroup_arithmetic which is useful for doing prefix sums
21:00graphitemaster: So I have to do the polyfill method which I guess is fine. I hope the shader compiler is smart enough to turn it into a subgroup op XD
21:01HdkR: Oh it is just missing
21:01graphitemaster: The GPU definitely supports it. It's there in Vulkan. It's just not exposed in GL on mesa for some reason.
21:03airlied: just nobody bothered most likely
21:03HdkR: Seems to be the case, can't even find a discussion about it
21:04graphitemaster: I found this https://gitlab.freedesktop.org/mesa/mesa/-/issues/6545
21:04graphitemaster: But that one does not mention AMD_shader_ballot which is basically the same deal.
21:39jenatali: Oof. nir_lower_returns is giving me invalid nir because it's adding a predecessor to a block which already had a phi
21:46jenatali: Of course it did, except nir_jump removed the block as a predecessor... that's fun