00:28KungFuJesus: karolherbst: interestingly my build just failed with -O1, that's very strange
00:33karolherbst: KungFuJesus: well.. why is it strange? undefined behavior is undefined behavior.. and with big endian you will run into out of bound situation, which will cause different issues depending on the codegen
00:35KungFuJesus: ../mesa-9999/src/compiler/nir/nir_opt_move.c:55:1: error: inlining failed in call to ‘always_inline’ ‘src_is_ssa’: indirect function call with a yet undetermined callee
00:36KungFuJesus: no like, it won't compile with -O1
00:36KungFuJesus: I don't think the situation is unique to big endian
00:37KungFuJesus: ugh, well that throws a wrench in my testing, I was hoping to see the minimal optimization level this problem occurs with and one by one disable each optimization turned on from that level until I had a narrower scope
00:38karolherbst: I thought libasan/valgrind already pointed out the out of bound reads/writes?
00:38karolherbst: thing is
00:38KungFuJesus: yes, but, it's not the culprit
00:38karolherbst: the cause isn't really a programming mistake, it's more of a logic issue and how big endian is "supported"
00:39KungFuJesus: I verified this last night by printing the bytes before and after the format swizzle. The results were identical between working and not working
00:39karolherbst: yeah, it's wrong in either case probably
00:40KungFuJesus: yeah, I have that fix. The code itself is only called under the circumstance of big endian, and I was hoping to find the main root cause first
00:40KungFuJesus: are you able to compile main with -O1?
00:40karolherbst: the main root cause is, that big endian support in mesa is just broken on many levels.
00:41KungFuJesus: understood but I'd like to untangle the many possible endianness bugs to at least get things to the state it had been pre TGSI->NIR translation
00:42karolherbst: it's odd that the shader compiler makes a difference here
00:42KungFuJesus: yeah, which kind of leads me to believe the GLSL compiler is where the poor behavior lives
00:43KungFuJesus: it goes GLSL->NIR or is it GLSL->TGSI?
00:43karolherbst: GLSL -> NIR -> TGSI
00:43karolherbst: and before it was just GLSL -> TGSI
00:43karolherbst: it can also be a bug inside the NIR to TGSI converted
00:44karolherbst: because that's kind of the new part
00:44KungFuJesus: so the GLSL to NIR compiler _likely_ has a bug. That's where a lot of the madness was being exhibited with asan/ubsan
00:44karolherbst: the main idea was to drop GLSL to TGSI alltogether
00:44karolherbst: mhhh would be strange, because GLSL to NIR is what every driver is using
00:45karolherbst: there might be some strictly undefined, but practically irrelevant things
00:45KungFuJesus: right, but, again I'm on big endian. I'm third class citizen with holes in the ground for toilets as far as testing goes
00:45karolherbst: yeah, right.. the compiler could behave differently on big endian/ppc for silly reasons
00:46karolherbst: you are on a big endian only platform, right?
00:46KungFuJesus: what had been particularly troubling was ubsan was certain a node_exec pointer being deref'd as an ir_variable was not _really_ an IR variable
00:46KungFuJesus: yes, Powermacs were not bi-endian except for some weird case to support virtualpc, I think
00:48KungFuJesus: another interesting tidbit about power is that I don't think you can always access things at improper alignments. I think certain sized variables it works but not all
00:49karolherbst: yeah, that could cause issues
00:49KungFuJesus: there actually is an alignment sanitizer in GCC
00:49karolherbst: that might be fun to try
00:51KungFuJesus: actually, it could be something even sillier. Like say, a hardcoded offset into a struct that isn't really packed
00:51KungFuJesus: according to this: https://developer.ibm.com/articles/pa-dalign/ PPC can do unaligned access, but very slowly
00:52KungFuJesus: but one would assume that a struct would be padded, even at -O0
00:52karolherbst: yeah well.. struct layouts are one of the few things actually defined
00:52KungFuJesus: I mean if that were the case offsetof(structname) is the obvious solution. I wouldn't think it'd be that insanely pedestrian though
00:52karolherbst: so they don't depend on the optimization
00:53karolherbst: and doesn't even depend on the arch
00:53karolherbst: normally fields are algined by their base type size
00:54karolherbst: (and biggest type for structs)
00:54karolherbst: or something
00:54KungFuJesus: right, the compiler is expected to do that. The only way this is really an issue is if somebody is computing an offset to a struct the dumbest way possible
00:55KungFuJesus: into a struct*
00:55karolherbst: which they shouldn't
00:55karolherbst: but yeah..
00:56karolherbst: could also be that that nir serializer/deserializer are doing cursed things
00:56karolherbst: ever tried with shader caching disabled?
00:56KungFuJesus: this bit here is particularly concerning: https://pastebin.com/euTGQhWT
00:57KungFuJesus: how do I disable shader caching? Is it an env var/
00:58karolherbst: " note: object has invalid vptr" yeah.. well.. that sounds bad
00:58karolherbst: which sanitizer is that?
01:02karolherbst: KungFuJesus: I know that libasan allows you to abort on the first error and dump the backtrace inside gdb and stuff... would be cool to get a proper backtrace for those errors
01:02karolherbst: because they do kind of look fishy
01:05KungFuJesus: Not 100% sure if it's asan or ubsan. Ubsan is what lets you abort
01:18fdobridge: <gfxstrand> What I mean by that is that we clearly need at least indirect draw to be implemented Differently on Turing+ from older GPUs unless we can figure out a nifty way to make Fermi MMEs load their own parameters somehow. This means some macros will exist on Turing but not older and we need to deal with that too.
01:19fdobridge: <gfxstrand> Fortunately, for a lot of the little stuff, we should be able to just build an MME and go for it most of the time. That's the goal, anyway. Especially as we start using MMEs for more state stuff which I expect we'll need to do to get full perf.
01:23KungFuJesus: if UB is the issue maybe we can get a better view of things by compiling with optimizations off and running with the sanitizer
01:23KungFuJesus: assuming it's the sort of UB that is detectable, anyway
01:32KungFuJesus: karolherbst: the fact that it seems to be interpretting bits of a syntax tree incorrectly kinda lends credence to the serializer/deserializer being an issue
01:39KungFuJesus: alright, trying this once again, both sanitizers, "debug" buildtype (supposedly turns off optimizations)
01:40KungFuJesus: going to run this in a debugger, hopefully I can get a detailed call stack when all of the alarm bells go off for pointer dereferencing
02:02KungFuJesus: Yeah, asan and ubsan find nothing with optimizations disabled. Go figure
02:06KungFuJesus: err nope, found something
02:06KungFuJesus: didn't have loader path setup fully
02:13KungFuJesus: ugh, the thing won't abort on errors for some reason
02:15KungFuJesus: ahhh, I think it's ubsan and I think I need to recompile if I want to be able to recover
02:19KungFuJesus: it's specifically node_b that it's certain is ir_dereference_variable and not ir_variable
02:21KungFuJesus: interesting - it's the vtable that's specifically indicating that it's really an ir_dereference_variable
02:22KungFuJesus: karolherbst: the callstack you were looking for: https://pastebin.com/ZzsWmXRC
02:25KungFuJesus: In this particular circumstance, the type offset is exactly the same. So, probably bad behavior if ir_dereference_variable is not a subclass of ir_variable but isn't the smoking gun in this case: https://pastebin.com/w3puiCSD
02:26KungFuJesus: if somebody reorders those member variables it could cause some real trouble, I think
02:30KungFuJesus: oh I can make UBSAN print my stack trace as well. Cool
02:40KungFuJesus: eh, there seems to be a lot of type confusion going on in ir_function.cpp. It just so happens that when compiled without optimizations, the only improperly dereferenced type was similar enough that they had the same offset
02:41KungFuJesus: so my guess is something is wrong when dealing with that node list?
03:05KungFuJesus: I think "type" at the very least needs to be defined in a base class common to everything derived from the node
03:06KungFuJesus: perhaps moved into the node struct itself
03:07KungFuJesus: it's quite possible optimizations are reordering these member variables and that's one place where it really matters to know how to compute the offset to compare that pointer to the pointer in the other node
03:09KungFuJesus: when you have a common base class it puts members in the same offset no matter the subclass but not everything here is derived from a common base (other than node, which is a struct and is not polymorphic)
03:13KungFuJesus: Man, compiling with optimizations + sanitizers takes a century. I'll run this once it's done compiling to see if I can find more shennanigans occuring but I think I might try moving that type pointer out to the exec_node struct
05:36KungFuJesus: Yeah so that fixed the UB there, tons more found, though. Man, this GLSL compiler is committing a lot of sins
05:43KungFuJesus: I mean I get that dynamic cast is slow but some introspection here could have really helped eliminate this class of bugs
05:47KungFuJesus: karolherbst: https://pastebin.com/AuXREgGE
05:49KungFuJesus: can we just embed some type info into the exec_node? Clearly this code expected the linked list to only be comprised of ir_instruction pointers
09:33karolherbst: it's very old code...
09:33karolherbst: but yeah...
09:33karolherbst: I wish people wouldn't do those thigns
09:34karolherbst: worse part it's even C++ code so you could just use std::list or something
09:35karolherbst: and maybe that's the solution? dunno...
15:12KungFuJesus: karolherbst: It's used by some C code elsewhere, I already tried making exec_node a class, instead
15:15KungFuJesus: The interesting part is that you are guaranteed that it will be at least the ir_instruction base class but I think casting from a a parent struct pointer to a base class pointer is still a far cry from telling the compiler you're casting from a base class. Clearly, I mean the vtable being all sorts of wrong is quasi-alarming here
17:27fdobridge: <gfxstrand> dEQP-VK.api.smoke.triangle passes on Maxwell. 😄
17:43fdobridge: <gfxstrand> Need to fix vertex buffers...
17:55fdobridge: <gfxstrand> Ok, doing a Maxwell run now. It's erroring a lot but it runs.
18:03fdobridge: <gfxstrand> @marysaka Happy to hand it back to you at this point. I just updated my nvk/mme-fermi-v2 branch.
18:04fdobridge: <gfxstrand> @marysaka We should probably rework the series a bit so we don't move fermi into its own folder and then back. Also, all my changes to unify the builders are a giant mega-patch called STUFF. That's not great.
18:08fdobridge: <marysaka> I see so if I understand correctly, you want me to rework the patches to merge nvk/mme-fermi-v2 in to have a cleaner tree/diff?
18:09fdobridge: <marysaka> I can start to look into that a bit tonight 😄
18:17fdobridge: <gfxstrand> Yes, please. Then I think we're good to land it and we can start the long bugfix crawl on pre-Turing. 😄
18:18fdobridge: <gfxstrand> I'm probably going to push my branch one more time. I just got RBs on my public isaspec MR so I'll rebase nvk/main on that as soon as it lands and rebase nvk/mme-fermi-v2 on nvk/main.
18:18fdobridge: <gfxstrand> I'll post here once that's all done.
18:23fdobridge: <marysaka> that remind me that I need to do an MR for the isaspec changes I have around
18:23fdobridge: <gfxstrand> Yes, please.
18:24fdobridge: <gfxstrand> I'm a tiny bit less concerned about that one because I don't have to go back through and fix up NVK history for it.
18:24fdobridge: <gfxstrand> I do for mine because it changes the calling convention of `isaspec/decode.py` and `isaspec/encode.py` 😢
18:32fdobridge: <Esdras Tarsis> I know this is a dev channel but I was testing some games and Street of Rage 4 looks playable on NVK (Terraria is ingame and The Talos Principle boots)
18:32fdobridge: <Esdras Tarsis> https://cdn.discordapp.com/attachments/1034184951790305330/1060626745142824980/Screenshot_from_2023-01-05_15-03-41.png
18:34fdobridge: <gfxstrand> Neat!
18:35fdobridge: <gfxstrand> We're still a ways out from "try to get all the apps to work" but it's cool to see that some stuff is already playing well.
18:36fdobridge: <gfxstrand> Feel free to test more stuff and post screenshots. That's really exciting. 😄
18:39fdobridge: <gfxstrand> First Maxwell run complete:
18:39fdobridge: <gfxstrand> `Pass: 145120, Fail: 79189, Crash: 5881, Warn: 4, Skip: 1329686, Missing: 498, Flake: 185, Duration: 45:11, Remaining: 0`
18:40fdobridge: <gfxstrand> Passing 60% isn't bad
18:40fdobridge: <marysaka> not that bad :linaalert:
18:47fdobridge: <gfxstrand> Let's see if I can figure out why my blit shader is trapping...
18:59fdobridge: <gfxstrand> This texture op looks bogus...
19:04fdobridge: <gfxstrand> Not the texture op
19:05fdobridge: <karolherbst🐧🦀> dmesg throwing errors?
19:05fdobridge: <karolherbst🐧🦀> could always be missing init stuff or something
19:05fdobridge: <karolherbst🐧🦀> but the value is quite close to what I had when running it (way back)
19:05fdobridge: <karolherbst🐧🦀> (just more skips and less fails)
19:05fdobridge: <gfxstrand> Oh, yeah, dmesg is blowing up. 🙂
19:05fdobridge: <karolherbst🐧🦀> 🙂
19:06fdobridge: <gfxstrand> Why is my VS reading `SV_POSITION`?
19:06fdobridge: <gfxstrand> NVM. It's not.
19:07fdobridge: <gfxstrand> It is writing `gl_Layer`, though.
19:07fdobridge: <gfxstrand> I could see hardware getting grumpy about that. 😅
19:08jekstrand: That seems to have been it. Now to figure out why....
19:29fdobridge: <gfxstrand> I guess Maxwell doesn't support writing `gl_Layer` from the VS. 😦
19:31fdobridge: <karolherbst🐧🦀> what is nvc0 doing?
19:31fdobridge: <karolherbst🐧🦀> Also.. is it 1st or 2nd gen maxwell?
19:31fdobridge: <karolherbst🐧🦀> 2nd gen got a couple of new features
19:32fdobridge: <gfxstrand> 1st gen. This is a 750 TI.
19:32fdobridge: <gfxstrand> nvc0 is saying it doesn't support gl_Layer from anything but GS in nvc0_screen
19:32fdobridge: <karolherbst🐧🦀> heh
19:32fdobridge: <gfxstrand> It's my meta shaders that rely on it
19:32fdobridge: <gfxstrand> There's a Vulkan feature bit
19:32fdobridge: <karolherbst🐧🦀> sounds like something 2nd gen maxwel can do
19:32fdobridge: <gfxstrand> I guess I can add a GS
19:33fdobridge: <karolherbst🐧🦀> what's the GL cap to check it?
19:33fdobridge: <gfxstrand> `PIPE_CAP_VS_LAYER_VIEWPORT`
19:34fdobridge: <karolherbst🐧🦀> I meant the GL one, so I can check what nvidia exposes
19:34fdobridge: <gfxstrand> IDK
19:34fdobridge: <karolherbst🐧🦀> AMD_vertex_shader_layer
19:34fdobridge: <gfxstrand> Sounds right
19:35fdobridge: <karolherbst🐧🦀> yep
19:35fdobridge: <karolherbst🐧🦀> 2nd gen maxwell+ 🙂
19:36jekstrand: I'll add a GS
19:37jekstrand: Or I could disable using layered rendering
19:37jekstrand: Eh, that sounds like a mess.
19:37fdobridge: <karolherbst🐧🦀> using GS or disabling layered rendering?
19:38fdobridge: <gfxstrand> both but I think not using layered rendering is probably more of a mess.
19:38fdobridge: <gfxstrand> IDK
19:38fdobridge: <karolherbst🐧🦀> heh
19:38fdobridge: <gfxstrand> And it's literally drawing a quad. I don't care about the cost of running a GS.
19:41jekstrand: Actually... I think NVK needs to be able to insert a dummy GS itself for multi-view anyway
19:42jekstrand: Good thing there's this nifty nir_passthrough_gs helper. :D
19:46fdobridge: <karolherbst🐧🦀> nice
19:49KungFuJesus: given the custom allocator with ralloc here I'd be hard pressed to stomp out all the UB and marginally unsafe access going on in the GLSL compiler. I'm actually a little bit surprised this doesn't cause more grief on SPARC which is known to be particularly staunch about requiring natural alignments or forcing you to take the SIGBUS
19:51karolherbst: not sure anybody even uses mesa on sprac
19:51karolherbst: there are more or less four main targets: x86/aarch64/s390x/ppc64le, everything else doesn't really exist and doesn't really get any testing whatsoever
19:52karolherbst: well.. I guess 32 bit arm is also a thing
19:52karolherbst: (and 32 bit x64)
19:53fdobridge: <gfxstrand> Even there, though. It has been used on ppc64be and I think SPARC in times past and it worked fine. ralloc has been around for a LONG time.
19:53fdobridge: <karolherbst🐧🦀> ohh the point isn't ralloc not working, just everything else isn't 😛
19:54fdobridge: <karolherbst🐧🦀> @gfxstrand stuff like that e.g.
19:57KungFuJesus: The few big reports I've never looked at while trying to find/fix/assess big endian have been SPARC, hah. So that corner is a bit more visible to me lately
19:57KungFuJesus: the guy that has the endian texture MR actually was patching things for SPARC
19:57KungFuJesus: on an ATI chipset, but still
20:01KungFuJesus: Now, I guess I can more or less ignore the UB for misaligned bits since those are at worst suboptimal. From what I've read, I think powerpc handles scalar unaligned access to variables mostly ok, particularly if serviced from cache. At least for 32 bit variables, anyway. Which probably means I can revector my search to either goofy things happening in the C++, which may be mostly innocuous but
20:01KungFuJesus: they definitely aren't well defined pathologies (having a base class inherit from a struct, then having code that accesses the sub classes from that base class dereference a pointer to the base struct as the base class)
20:03KungFuJesus: this may make the vptr calculus ambiguous (or maybe just severely confuse ubsan)
20:03KungFuJesus: or other things that I won't see until I compile with all -O2 optimizations enabled
20:04KungFuJesus: it's interesting that I can't compile with O1. I'm guessing that makes always_inline actually do something and there's a case where it may be called via some external linkage that maybe gets optimized away? I've seen the optimizer in GCC do that once or twice
20:07KungFuJesus: gfxstrand: yeah, it just so happens to be tripping some alarms in ubsan, some of which might be innocuous. I think it's pretty apparent that an optimization somewhere is changing things enough or shortcircuiting something that causes a bunch of bad access or values in setting up the fragment shader programs
20:09KungFuJesus: with optimizations enabled and valgrind injected, it finds a ton of uninitialized memory utilization all over. It just so happens that these shader programs are also what renders the UI in mythtv, so that's not likely a coinicidence
20:11fdobridge: <gfxstrand> Ugh... passthrough GS is going to be more of a pain than I was hoping for. There are N different ways to do this and they all suck. 😦
20:12fdobridge: <gfxstrand> I think I may just fall back to not doing layered rendering at all.
20:13KungFuJesus: gfxstrand: The reason I was bringing up alignment issues from ralloc: https://pastebin.com/AuXREgGE
20:13KungFuJesus: see line 147, et al
20:14jekstrand: Oh, yeah, slab is new. I could believe there's a bug in there.
20:14jekstrand: Still seems a bit odd
20:14jekstrand: Wait, why does slab require a 16B alignment? That makes no sense.
20:14fdobridge: <karolherbst🐧🦀> @gfxstrand I think there was a special "fast" GS type, but I have no idea what that one is doing
20:15fdobridge: <karolherbst🐧🦀> doesn't matter anyway as it's GP102+
20:15fdobridge: <gfxstrand> Yeah, the problem is that I need to smash layer to another varying because I can't even use it as a pass-through.
20:15fdobridge: <gfxstrand> It's a mess
20:16fdobridge: <karolherbst🐧🦀> uhh
20:16KungFuJesus: I'd have to see the members. I'd guess that that is probably the LCM such that a heap allocation makes all the members properly align
20:17KungFuJesus: that was with no optimizations enabled, interestingly. Which of course doesn't exhibit the bug
20:18KungFuJesus: it's one of those things where it's considered UB in C but is _typically_ safe to do on a lot of architectures. Power included, I think
20:18KungFuJesus: You can memcpy things into a stack variable, operate on it, and write it back and most of the time GCC can optimize that away on architectures. Well, at least for reads
20:22KungFuJesus: I gotta wonder, though, are things like custom allocators still beneficial in the days of mimalloc, jemalloc, and even glibc?
20:27HdkR: Domain specific allocators can still crush generic allocators in very specific tasks
20:29KungFuJesus: Sure, but there are a lot out there that try to do things like pooled allocations for specific types and other similar tricks you see in things like the JVM where heap gets pervasively reused
20:29HdkR: Example, a monotonic allocator that is handling a pool of container objects and maps. You can allocate quickly since it is just an incrementing pointer, and you can teardown quickly since you just set pointer offset to zero, or munmap
20:31KungFuJesus: I just wonder if the claims about ralloc being faster in comments are made against an allocator from 15 years ago or from today's glibc
20:32HdkR: That's definitely harder to quantify :D
20:32anholt: ralloc is not about being faster. it uses malloc underneath. it's about hierarchical pooling for lifetime management.
20:32KungFuJesus: it just seems a lot easier for a platform specific bug to hide in a custom allocator. I have no direct proof it's even an issue yet, but it certainly can subvert a lot of the safety checks memory poisoning provide ala the sanitizers
20:33anholt: I would bet money that you're way off in the weeds here as far as fixing any bug affecting you.
20:33KungFuJesus: I hope so
23:03fdobridge: <marysaka> @gfxstrand any reasons mme_tu104_builder.h isn't listed in libnouveau_mme_files in the meson buildscript?
23:04fdobridge: <gfxstrand> I don't think you need to list header files anymore in Meson
23:05fdobridge: <marysaka> okay, was just wondering as tu104 simulator and mme_builder.h are defined in it
23:06fdobridge: <gfxstrand> 🤷
23:06fdobridge: <gfxstrand> We're not consistent.
23:06fdobridge: <gfxstrand> Should probably pick a convention and go with it.
23:08fdobridge: <marysaka> I mean it's nothing was just looking diff and questioning myself a bit too much :AkkoDerp:
23:09fdobridge: <marysaka> Currently remaking my commits a bit basing myself on nvk/mme-fermi-v2 right before the first commit of my branch
23:10fdobridge: <marysaka> Also made the MR for isaspec (hopefully I did it properly)
23:12jekstrand: Ok, cool. Let me take a look.
23:16fdobridge: <phomes> for VK_KHR_draw_indirect_count I don't see a way to get to 7 registers
23:16fdobridge: <gfxstrand> We're gonna have to get clever.
23:17fdobridge: <gfxstrand> We can spill to scratch state if we have to.
23:22fdobridge: <gfxstrand> @marysaka Ok, I've rebased on my upstream isaspec change. I'm going to go ahead and land some of the precursor NVK patches on nvk/main now too if they don't blow the CTS up.
23:22fdobridge: <phomes> @gfxstrand ok. I might need some help to get started on that at some point
23:23fdobridge: <gfxstrand> Once we get Fermi MME landed, we can start looking into making it fancier.
23:23fdobridge: <gfxstrand> I'm mentally debating if we want to have a 2-pass thing and do some light RA and spilling in `mme_fermi_builder_finish()`
23:24fdobridge: <gfxstrand> That might be more maintainable long-term.
23:25fdobridge: <gfxstrand> I had to add two manual `mme_free_reg()` calls just to get the basic non-indirect draw macros into 7 regs.
23:26fdobridge: <phomes> I saw that and wanted to try the same for VK_KHR_draw_indirect_count. But there I use 7 registers for the input alone
23:28fdobridge: <gfxstrand> We'll need different indirect draw MMEs for Fermi anyway because it doesn't have
23:28fdobridge: <gfxstrand> We'll need different indirect draw MMEs for Fermi anyway because it doesn't have `READ_FIFOED` (edited)
23:29fdobridge: <phomes> I will wait and see what you do and try to keep my patches updated 🙂
23:35fdobridge: <gfxstrand> IDK if I'll be the one to do it. 😅
23:36fdobridge: <gfxstrand> I'm going to try and fix it up enough that I can reasonably run CTS with non-horrible results and probably let someone else fill in the cracks.
23:36fdobridge: <gfxstrand> Right now, Turing runs CTS in 15m and Maxwell takes 45m because it crashes and hangs so much. 😦
23:46fdobridge: <gfxstrand> @marysaka I'm done rebasing for a while now. Anything you've done should rebase pretty cleanly on nvk/main. Just need to drop my isaspec changes and the "BUILD FIX" patch.
23:48fdobridge: <marysaka> Okay thanks 👍, will do after I finish remaking my commits
23:49fdobridge: <gfxstrand> @marysaka Also, IDK if this is intentional but your commits all say "Mary" with no surname. Mesa doesn't require surnames but most people use them so I just thought I'd double-check.
23:50fdobridge: <marysaka> Yeah I don't put my surname yet, I should probably fix that :painpeko:
23:52fdobridge: <gfxstrand> Yeah, git defaults to whatever your login name is, I think.
23:54fdobridge: <marysaka> I did that on purpose to avoid doxing and stuffs mainly
23:54jekstrand: Ah, yeah.
23:55fdobridge: <marysaka> Also a bit sorry about the coding style and haven't run any formatting check 😅
23:56fdobridge: <gfxstrand> We don't have a clang-format thing.
23:56fdobridge: <gfxstrand> I should probably set that up. It'd make things easier for new contributors.
23:56fdobridge: <gfxstrand> I'm just used to doing everything manually and have learned to be really damn consistent.
23:57fdobridge: <gfxstrand> For all my rust stuff, though, I've stuck strictly to rustfmt