07:02 <TheVibeCoder> 06:27 < TheVibeCoder> fixed very very very old adpcm thp decoding bug

08:01 <CounterPillow> you sicko, it was one day before its retirement!

12:41 <Lynne> ePirat: ping

12:54 <ePirat> Lynne, can you send me the links again? Couldnt find them in my backlog

12:54 <Lynne> ePirat: sure, https://files.lynne.ee/P1000520.MOV and https://files.lynne.ee/P1000521.MOV

12:57 <ePirat> Thanks

13:03 <ePirat> Lynne, will take a while as the output file sizes are huge

13:03 <Lynne> sure

15:37 <jamrial> michaelni, BtbN: sent a patch for the schannel compilation failure

15:40 <BtbN> jamrial: those structs and defined should not need any such checks

15:40 <BtbN> they are always defined, provided mingw is recent enough

15:40 <jamrial> BtbN: that's the problem, michaelni's is not recent enough :p

15:40 <jamrial> it's a mingw64 package from a distro

15:41 <BtbN> But then defining a higher _WIN32_WINNT doesn't help either :D

15:41 <jamrial> no, but it feels correct

15:41 <jamrial> i can remove it, that said

15:41 <BtbN> Also, disabling the dtls protocol does nothing for this

15:41 <jamrial> or add it only if dtls_protocol is enablef

15:41 <BtbN> the dtls protocol does not need this

15:41 <BtbN> whip needs this, from that one ff_ function defined in the respective dtls handler

15:41 <jamrial> there's also a bunch of enum values

15:41 <BtbN> and that function is there even when the dtls protocol is disabled

15:42 <jamrial> outside of the whip functions

15:42 <jamrial> look at the patch

15:42 <BtbN> yes, I did

15:42 <BtbN> and it's not correct. The DTLS protocol can stay

15:42 <BtbN> it's really just ff_dtls_export_materials

15:42 <BtbN> the dtls protocol does not need this function

15:43 <BtbN> whip.c does

15:43 <jamrial> so how do i go around wrapping the SEC_I_MESSAGE_* enum values?

15:43 <BtbN> They're much older than the keying material export

15:44 <BtbN> so they shouldn't need any protections

15:44 <jamrial> well, they do, seeing michael's error log

15:44 <BtbN> Then they need a separate configure check, which then toggle of the DTLS protocol

15:45 <BtbN> Or we just bump the minimum mingw version?

15:45 <BtbN> They're there for almost a decade at this point

15:45 <jamrial> i have no idea what distro is michael using, but if it's a supported one, then i don't think we should make their mingw64 package unsupported

15:46 <BtbN> https://github.com/mingw-w64/mingw-w64/commit/f6bb0f7b5ecda1f6617fbf1ae952abbbed37df78 it's there since mingw 8.0.0

15:47 <BtbN> I think the main issue is that Ubuntu neglected updating mingw for a really long time

15:47 <BtbN> so even 22.04 is on mingw 7 or something

15:48 <BtbN> If it's just the SEC_I_MESSAGE_FRAGMENT one, we could also just do an #ifndef for it

15:49 <jamrial> BtbN: https://packages.debian.org/bullseye/mingw-w64-x86-64-dev debian at least in its oldest supported release has mingw-w64 8.0.0

15:49 <BtbN> Yeah, that has it

15:50 <BtbN> https://launchpad.net/ubuntu/+source/mingw-w64

15:50 <BtbN> Ubuntu has it since 22.04, 20.04 does not have it, and is EOL since May

15:52 <BtbN> The easy way out of this would be to just disable the entirety of schannel on mingw that old

15:52 <BtbN> that at least keeps the code clean of a lot of ifdefery

15:53 <jamrial> i don't know, this is only an issue since the recent patches to support dtls

15:54 <BtbN> But uglyfying the code on master to support something no supported distro ships anymore?

15:55 <BtbN> The patch is of course fine, though it restricts the dtls protocol a bit more than neccesary

15:55 <jamrial> i'm trying something cleaner

16:16 <BtbN> man, the tls_openssl.c code is driving me crazy

16:16 <BtbN> Primarily because every function names its helper variables differently, and sometimes even opposite

16:16 <BtbN> c, s, p, ...

16:16 <BtbN> everything is everything, depending on the function

16:16 <jamrial> ai output?

16:17 <BtbN> No, historical code written by different people I guess

16:17 <BtbN> Once work on it has calmed down, I'm gonna make a patch that unifies the variable names and cleans stuff up a bit in general

17:22 <Yalda> all, I will start transitioning to use my name. nice to meet you again

19:00 <indecisiveturtle> Lynne: Have some questions optimization related, would like your opinion on. It's a pretty long text, is it okay to type it here?

19:01 <Lynne> indecisiveturtle: sure, its quiet anyway

19:03 <ePirat> make sure to break it up into smaller messages

19:03 <ePirat> depending on your client else the rest is lost

19:04 <indecisiveturtle> I think my client doesn't allow sending messages over some limit, it wont allow it

19:05 <indecisiveturtle> Ok so, this related to the step of finding best quantizer for each slice. The cpu prores ks encoder will estimate bits initially for [min_quant, max_quant] and if bits with max_quant are over a set limit, it will do a second loop of 128 iterations until it gets something that fits. At the moment I just handle the first part with 3 dispatches, one per plane, with a buffer barrier in between where each accumulates bit

19:05 <indecisiveturtle> Oh shoot it sent twice why

19:06 <indecisiveturtle> Anyway

19:06 <indecisiveturtle> First question would be if the dispatches could be merged somehow to reduce the number of needed barriers. Merging them into 1 is certainly possible but requires an expensive atomic add to ensure proper sync. Could avoid that, possibly, by writing all bits into a buffer and using subgroupClusteredAdd in a separate dispatch to combine these, so we only need 1 barrier for everything.

19:06 <indecisiveturtle> There is also the question of how to handle the case where we need to find the overquant. Would making the initial dispatch run over all 128 max results and the thread return early be fine? Mostly a question of if we would be wasting GPU threads idling in that case. Maybe it would be better to mimic the original code, where the initial dispatch is limited to max_quant and in the clustured add step we write an append

19:06 <indecisiveturtle> buffer and do an indirect dispatch on only the slices that need it.

19:08 <indecisiveturtle> These are my thoughts atm, not sure if they are worth it, but I do want to make the encoder as fast as possible

19:36 <Lynne> indecisiveturtle: for now, can you allow the overshoot?

19:40 <BtbN> How is the ML working these last couple days? It should be much better in regards to mangling mail addresses.

19:42 <indecisiveturtle> Lynne: You mean to implement it in the quick way? Don't quite understand

19:42 <Lynne> yeah, for now

19:47 <indecisiveturtle> Sure

22:05 <BtbN> I hate when I can't send mail because spammers tried to hard to log into my account that it got locked for half an hour...

22:24 <ePirat> whoops ended up writing a bit of a lengthy email about my unhappiness with gitlab

22:47 <ePirat> "Something went wrong while fetching work item award emojis. Please try again." Thanks GitLab