10:09 <adavy> 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:09 <adavy> the cnd_signal.

10:10 <adavy> 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:12 <adavy> 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:42 <adavy> according to the docs I read, this seems to be legal

11:39 <emersion> swick[m]: displayid 2.1 has an adaptive sync with flags and values for flickering and rate changes

11:39 <emersion> section 4.9

11:39 <emersion> an adaptive sync block*

11:41 <emersion> it's new in 2.1, can't find it in either 1.x nor 2.0

12:21 <MrCooper> nice, here's hoping the values in there will be accurate

12:23 <emersion> the VESA CTS requires these to be accurate

12:23 <emersion> so there's at least _some_ hope

12:23 <emersion> also an issue is that we still can't read displayid

12:24 <emersion> kernel doesn't expose it, so we don't even know what's in there

15:47 <ishitatsuyuki> 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:48 <ishitatsuyuki> 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:18 <saikat> Hello Sir! Help wanted.. about freedreno gallium driver modification.. anyone can help?

17:37 <DavidHeidelberg[m]> saikat: try #freedreno channel

17:41 <saikat> Okay thank you.. will try..

20:32 <HdkR> Is it just me or is it when an application uses EXT_swap_control_tear, it overrides `vblank_mode`?

20:46 <HdkR> Looks like if `GLX_LATE_SWAPS_TEAR_EXT` is used then it overrides vblank_mode=0

20:47 <HdkR> Or just this game is /really/ good at timing to 60

20:48 <HdkR> Seems to be the case

20:53 <graphitemaster> 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:54 <graphitemaster> Sitting here polyfilling most of the arithmetic with loops and readInvocationARB

20:56 <HdkR> You get GL_ARB_shader_ballot right?

20:59 <graphitemaster> Yeah, but no GL_AMD_shader_ballot or GL_KHR_shader_subgroup_arithmetic which is useful for doing prefix sums

21:00 <graphitemaster> 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:01 <HdkR> Oh it is just missing

21:01 <graphitemaster> The GPU definitely supports it. It's there in Vulkan. It's just not exposed in GL on mesa for some reason.

21:03 <airlied> just nobody bothered most likely

21:03 <HdkR> Seems to be the case, can't even find a discussion about it

21:04 <graphitemaster> I found this https://gitlab.freedesktop.org/mesa/mesa/-/issues/6545

21:04 <graphitemaster> But that one does not mention AMD_shader_ballot which is basically the same deal.

21:39 <jenatali> Oof. nir_lower_returns is giving me invalid nir because it's adding a predecessor to a block which already had a phi

21:46 <jenatali> Of course it did, except nir_jump removed the block as a predecessor... that's fun