00:04 fdobridge: <m​arysaka> oh hmm... the STUFF commit doesn't build as a standalone I see :painpeko:
00:05 fdobridge: <g​fxstrand> Yeah, it needs the CF fixes
00:05 fdobridge: <m​arysaka> well I will combine that I guess
00:05 fdobridge: <g​fxstrand> sure
00:42 fdobridge: <m​arysaka> MME tests still pass, time for rebase
00:43 fdobridge: <m​arysaka> https://gitlab.freedesktop.org/marysaka/mesa/-/commits/nvk/mme-fermi-v3
00:45 fdobridge: <m​arysaka> I think I should squash the MME builder integration with the commit that adds it but I think I will call it a day on this
00:45 jekstrand: kk
00:45 fdobridge: <k​arolherbst🐧🦀> IDEs want those files to be listed... at least some... I think... maybe, dunno 😄
00:46 fdobridge: <k​arolherbst🐧🦀> at least with cmake this was always important to add all header files as well, because otherwise the generator wouldn't include the header files in projects
00:46 fdobridge: <g​fxstrand> Ok, so for some reason on Maxwell, I'm getting different edge behavior on triangles.
00:47 fdobridge: <g​fxstrand> I'm drawing two triangles to make a quad and the diagonal is missing fragments.
00:47 fdobridge: <k​arolherbst🐧🦀> huh
00:47 fdobridge: <k​arolherbst🐧🦀> "strange"
00:48 fdobridge: <k​arolherbst🐧🦀> but you know.. since 2nd gen Maxwell we can actually draw quads anyway, so I'm surprised you use triangles in the first place
00:49 fdobridge: <k​arolherbst🐧🦀> also.. there is `NV_fill_rectangle` new since 2nd gen Maxwell as well, which might explain what you are hitting now
00:49 fdobridge: <g​fxstrand> Because I haven't hooked up magic paths
00:49 fdobridge: <g​fxstrand> Also, this is 1st gen maxwell
00:50 fdobridge: <k​arolherbst🐧🦀> ohh wait.. fill_rectangle is the quad feature
00:50 fdobridge: <k​arolherbst🐧🦀> yeah...
00:50 fdobridge: <k​arolherbst🐧🦀> my point was.. it might work as epxected on 2nd gen
00:50 fdobridge: <g​fxstrand> Also, drawing two triangles really should work....
00:50 fdobridge: <k​arolherbst🐧🦀> my point was.. it might work as expected on 2nd gen (edited)
00:51 fdobridge: <k​arolherbst🐧🦀> mhhh.. different defaults or something? stuff changed in weird ways around that time
00:52 fdobridge: <k​arolherbst🐧🦀> do you set `NV9097_SET_LINE_MODE_POLYGON_CLIP_GENERATED_EDGE`?
00:52 jekstrand: Yeah, looking at that
00:55 fdobridge: <k​arolherbst🐧🦀> or uhh... let me try to find something
00:55 jekstrand: Yeah, that doesn't do anything
00:56 jekstrand: SMOOTH_EDGE_TABLE, maybe?
00:56 fdobridge: <k​arolherbst🐧🦀> maybe?
00:56 jekstrand: Doesn't look like nouveau sets that either
00:59 fdobridge: <g​fxstrand> If we don't have watertight meshes, people are gonna get grumpy....
01:01 fdobridge: <k​arolherbst🐧🦀> might want to check `nvc0_blitctx_prepare_state`
01:02 fdobridge: <k​arolherbst🐧🦀> even calls two macros, interesting
01:06 jekstrand: Yeah, nothing interesting there.
01:07 fdobridge: <k​arolherbst🐧🦀> currently looking at `nvc0_blit_3d`, especially the `VIEW_VOLUME_CLIP_CTRL` a.k.a `NVA097_SET_VIEWPORT_CLIP_CONTROL`
01:07 fdobridge: <k​arolherbst🐧🦀> especially as we set a bit not documented? wtf
01:09 jekstrand: Viewports should be fine
01:09 fdobridge: <k​arolherbst🐧🦀> yeah..
01:10 fdobridge: <k​arolherbst🐧🦀> I think there was something to change "rounding" behavior or something like that on the edges, but I can't remember what it was...
01:10 jekstrand: SNAP_GRID_LINE_ROUNDING_MODE?
01:10 karolherbst: maybe?
01:11 fdobridge: <k​arolherbst🐧🦀> `NVC0_3D_UNK0318` in nvc0... "fun"
01:11 fdobridge: <k​arolherbst🐧🦀> at least doesn't seem like we ever set it
01:11 jekstrand: Yeah and it shouldn't matter
01:12 jekstrand: I'm also drawing them with the same orientation so we shouldn't have edge winding order problems.
01:12 fdobridge: <k​arolherbst🐧🦀> yeah.. I mean, the gallium blitter code also draws two triangles and it's not causing those issues
01:12 jekstrand: DRAW_CONTROL maybe?
01:13 karolherbst: too new
01:13 karolherbst: but maybe?
01:13 jekstrand: right
01:13 jekstrand: Yeah, doesn't exist on maxwell
01:14 karolherbst: could be that we just overlap a little in nvc0 to be super safe
01:14 jekstrand: If that's the solution, no apps will render properly
01:14 karolherbst: yeah...
01:17 jekstrand: it's possible I'm getting the guardband wrong.
01:17 jekstrand: But that shouldn't matter either
01:17 jekstrand: That shouldn't cause edges to separate
01:19 jekstrand: I'll poke at this tomorrow. My stomach is grumbling.
01:19 karolherbst: uhhh wait...
01:19 karolherbst: we don't draw two triangles for blits
01:19 karolherbst: we draw one....
01:20 karolherbst: uhhh
01:21 karolherbst: I know this topic came up...
01:26 fdobridge: <k​arolherbst🐧🦀> @gfxstrand `[Samstag, 21. April 2018] [16:47:35 CEST] <pendingchaos> I'm getting some poor msaa quality. it only seems to effect some of the edges of a triangle is this a know issue?` 🙃
01:26 fdobridge: <g​fxstrand> Oh boy...
01:27 fdobridge: <k​arolherbst🐧🦀> let me do some more digging and see what I can find
01:27 fdobridge: <k​arolherbst🐧🦀> `the idea of that code is that you draw a single triangle`, yes, but why
01:29 fdobridge: <k​arolherbst🐧🦀> but that discussion was mostly around msaa being funky and the edges having funky issues like that
01:29 fdobridge: <k​arolherbst🐧🦀> or are you doing msaa stuff?
01:30 fdobridge: <k​arolherbst🐧🦀> in which case... "don't do that?" 😄 dunno
01:34 fdobridge: <g​fxstrand> I suspect it's something to do with MSAA.
01:35 fdobridge: <g​fxstrand> That's what my gut is telling me.
01:35 fdobridge: <k​arolherbst🐧🦀> mhhh
01:35 fdobridge: <g​fxstrand> I'll play with it more tomorrow
01:35 fdobridge: <k​arolherbst🐧🦀> 2nd gen maxwell added custom sample locations
01:35 fdobridge: <k​arolherbst🐧🦀> just saying
01:36 fdobridge: <g​fxstrand> Yeah
01:41 karolherbst: HdkR: sooo... drawing two triangles to draw a rectangle, what do you say about that?
02:33 fdobridge: <k​arolherbst🐧🦀> @gfxstrand you won't believe what I just found
02:34 fdobridge: <k​arolherbst🐧🦀> @gfxstrand https://on-demand.gputechconf.com/siggraph/2016/presentation/sig1609-kilgard-jeffrey-keil-nvidia-opengl-in-2016.pdf slides 65+
02:41 fdobridge: <g​fxstrand> Makes sense
02:41 fdobridge: <g​fxstrand> I figured it was something like that. I need to poke about
02:41 fdobridge: <k​arolherbst🐧🦀> I just think that those artifacts are something we have to live with or we really have to understand how the GPU draws and how to prevent that from happening
02:42 fdobridge: <k​arolherbst🐧🦀> at least on GPU gens without that fine control of things
02:43 fdobridge: <k​arolherbst🐧🦀> I'm sure we did this single triangle approach in nvc0 for exactly that reason
02:43 fdobridge: <g​fxstrand> I think I know what's wrong. I'll play with it tomorrow.
02:43 fdobridge: <k​arolherbst🐧🦀> okay, cool
02:44 fdobridge: <k​arolherbst🐧🦀> hopefully you'll figure it out
05:29 HdkR: karolherbst: Screenspace or world space? :P
11:36 OftenTimeConsuming: karolherbst: Got a hang on an upgraded mesa version and no dmesg errors. I guess I need to turn on debug mode in kernel...
11:47 karolherbst: OftenTimeConsuming: yeah.. can also be a random mesa bug. Usually it helps to have a solid and reliable reproducer, or to know what the gpu/kernel is complaining about
11:48 OftenTimeConsuming: It's a shame I have neither.
16:11 fdobridge: <g​fxstrand> Wait, whaaaaaat?!? It's not that the triangles aren't covering some pixles it's that edge pixels are ending up black.
16:11 fdobridge: <g​fxstrand> They're not ending up clear color
16:12 fdobridge: <g​fxstrand> I wonder if it's a sampler issue. Maybe something with derivatives being wrong?
16:13 fdobridge: <g​fxstrand> Yup! That's it. No cracking when I use a constant color.
16:35 fdobridge: <k​arolherbst🐧🦀> heh
16:35 fdobridge: <k​arolherbst🐧🦀> "fun"
16:36 fdobridge: <k​arolherbst🐧🦀> maybe it's related to the helper invoc thing... which I highly doubt... that reminds me.. I still need to upstream those bits.. *sigh*
16:36 fdobridge: <E​sdras Tarsis> why is VK_KHR_maintenance2 labeled medium?
16:38 fdobridge: <E​sdras Tarsis> besides being important for zink this extension is important for d3d9 frontend of DXVK
16:43 fdobridge: <g​fxstrand> Because it's a grab-bag with a bunch of stuff. Each individual item is probably easy but there's a lot in there.
16:43 fdobridge: <g​fxstrand> And someone (probably me) needs to do very careful review when it lands to make sure we don't miss anything.
16:44 fdobridge: <g​fxstrand> Not *that* helper invoc thing but maybe helper invoc related.
16:44 fdobridge: <k​arolherbst🐧🦀> yeah...
16:44 fdobridge: <k​arolherbst🐧🦀> maybe a different bit in that magic reg 🙃
16:45 fdobridge: <g​fxstrand> The texture op shouldn't be doing derivatives it should be txl.
16:45 fdobridge: <g​fxstrand> But I'm wondering if the compiler is messing it up somehow
16:46 fdobridge: <k​arolherbst🐧🦀> could be
16:48 jekstrand: Yeah, I'm not getting TXL...
16:48 jekstrand: I'm getting TEX with levelZero set?!?
16:48 jekstrand: Makes sense, I guess.
16:52 karolherbst: yeah.. doesn't matter either way
16:53 karolherbst: it's all the same in the ISA anyway
16:54 jekstrand: Yeah, the question, then, is why do I have so many sources to this texture op?
16:54 jekstrand: It should be coords and a tex/samp handle pair
16:55 karolherbst: how many do you get after RA?
16:55 jekstrand: I've got at least two regs worth I don't need.
16:55 jekstrand: 19: tex 2D_ARRAY $r255 $s31 rgba f32 $r0q $r4t $r0t (8)
16:55 karolherbst: that's fine
16:55 karolherbst: $r4t contains the coords
16:55 karolherbst: and the handle goes into $r0t
16:56 karolherbst: not sure why it allocates a triple reg, but...
16:56 karolherbst: it has to be quad aligned either way
16:56 karolherbst: there are "scalar" modes to compress that all, but I'd rather not mess with that part of the code again
16:57 karolherbst: "scalar" actually just removes the gaps you need to fill
16:58 jekstrand: In any case, it is texturing when not on the edges so the handles are in the right place
16:58 karolherbst: yep
16:58 karolherbst: lod would be in src1.y
16:59 jekstrand: which is 0
17:00 karolherbst: it's not read if .LZ is set anyway
17:00 jekstrand: sure
17:01 karolherbst: ahh.. src1.z actually needs to be set in any case
17:01 karolherbst: those are offsets
17:01 jekstrand: ah
17:01 karolherbst: and I assume they are all 0
17:01 jekstrand: yeah
17:01 jekstrand: r2 is being set to garbage, though.
17:02 jekstrand: Well, it's being set to stuff but the stuff is nonsense
17:02 karolherbst: and src0.x is lod clamp in the high bits and array idx in the low bits
17:02 karolherbst: src0.yzw are str
17:02 karolherbst: lod clamp only if .LC is set obviously
17:02 jekstrand: 0: linterp pass f32 $r0 a[0x7c] (8)
17:02 jekstrand: 1: rcp f32 $r0 $r0 (8)
17:02 jekstrand: 2: pinterp mul u32 $r1 a[0x70] $r0 (8)
17:02 jekstrand: 3: pinterp mul u32 $r0 a[0x74] $r0 (8)
17:02 jekstrand: 4: mov u32 $r2 c1[0x20] (8)
17:02 jekstrand: 5: mov u32 $r3 c1[0x24] (8)
17:02 jekstrand: 6: fma ftz f32 $r5 $r1 c1[0x28] $r2 (8)
17:02 jekstrand: 7: fma ftz f32 $r6 $r0 c1[0x2c] $r3 (8)
17:02 jekstrand: 8: linterp flat u32 $r0 a[0x64] (8)
17:02 jekstrand: 9: add s32 $r0 $r0 c1[0x38] (8)
17:02 jekstrand: 10: cvt f32 $r4 u32 $r0 (8)
17:02 jekstrand: 11: mov u32 $r0 c1[0xa0] (8)
17:03 jekstrand: 12: mov u32 $r1 c1[0xa4] (8)
17:03 jekstrand: 13: ld u64 $r2d g[$r0d+0x0] (8)
17:03 jekstrand: 14: and u32 $r0 $r3 0x000fffff (8)
17:03 jekstrand: 15: and u32 $r1 $r2 0xfff00000 (8)
17:03 jekstrand: 16: or u32 $r0 $r0 $r1 (8)
17:03 jekstrand: 17: mov u32 $r1 0x00000000 (8)
17:03 jekstrand: 18: cvt ftz u16 $r4 f32 $r4 (8)
17:03 jekstrand: 19: tex 2D_ARRAY $r255 $s31 rgba f32 $r0q $r4t $r0t (8)
17:03 jekstrand: BB:1 (1 instructions) - idom = BB:0, df = { }
17:03 jekstrand: 20: exit - # (8)
17:03 karolherbst: ohh wait
17:04 karolherbst: for 2D the coords are in src0.xy
17:04 karolherbst: or are they...
17:04 karolherbst: it's 2D_ARRAY anyway
17:04 karolherbst: and the coords seem to be in $r5 and $r6, which is correct
17:05 karolherbst: so yeah.. the shader looks fine
17:05 karolherbst: we really should get the scalar packing working in NAK, because that actually helps with RA a lot
17:06 karolherbst: so if you only have a 2D access, you add two scalar sources and are done
17:06 karolherbst: anyway... I think the shader is fine
17:15 jekstrand: Yeah, I'll put it on the ToDo list
17:45 jekstrand: How are helper invocations controlled?
17:47 karolherbst: what do you mena?
17:48 karolherbst: afaik we have 0 knobs on those in the channel
18:32 jekstrand: karolherbst: I think it is our favorite bug. :-(
18:32 jekstrand: karolherbst: Where do I find your kernel patch?
18:33 jekstrand: I think the Mesa patch is in a draft MR somewhere.
18:36 jekstrand: Or not
18:40 jekstrand: Found the mesa patch
18:46 jekstrand: Found the kernel branch
18:46 jekstrand: Hooray for IRC logs.
19:01 jekstrand: Yup! That fixes it.
19:01 jekstrand: Time for some more micro-blogging.
19:03 jekstrand: Doing another CTS run now.
19:25 karolherbst: :)
19:25 karolherbst: I really should clean it up and make it possible to use it in a non messy way (a.k.a. always set that bit)
19:31 jekstrand: Yeah
19:37 jekstrand: Ok, deqp-runner says it'll be done in another 2 minutes.
19:37 jekstrand: This run is looking WAY better than yesterday's
19:38 karolherbst: figures, because I always did my runs with that helper invoc patch anyway
19:40 fdobridge: <g​fxstrand> `Pass: 218742, Fail: 10939, Crash: 1039, Warn: 4, Skip: 1328582, Flake: 1257, Duration: 36:13`
19:40 fdobridge: <g​fxstrand> Much better!
19:41 fdobridge: <g​fxstrand> That's 80-90% of the fails gone.
19:41 fdobridge: <k​arolherbst🐧🦀> how does it look on turing?
19:41 fdobridge: <g​fxstrand> Turing is at about 500 crash/fail
19:41 fdobridge: <k​arolherbst🐧🦀> ahh
19:55 fdobridge: <g​fxstrand> Ok, next: Something is wrong with 3D blits. No idea what yet.
20:23 fdobridge: <m​arysaka> nice!
21:18 fdobridge: <g​fxstrand> I wish the 3D blit tests didn't suck so much.
21:19 fdobridge: <g​fxstrand> They test well enough but the output they give, they do this weird projection thing to try and visualize the 3D image and it's impossible to see the individual layers. 😦
22:09 fdobridge: <g​fxstrand> It appears indexed rendering also doesn't work. I think I'm going to try and solve that one.
22:21 fdobridge: <g​fxstrand> Actually... the clear in this test appears to be failing.
22:27 fdobridge: <g​fxstrand> *grumble*
22:28 fdobridge: <g​fxstrand> Is my copy not happening?!?
22:30 fdobridge: <k​arolherbst🐧🦀> check dmesg 😛
22:31 fdobridge: <g​fxstrand> nothing in dmesg
22:31 fdobridge: <g​fxstrand> I've been watching it like a hawk
22:34 fdobridge: <k​arolherbst🐧🦀> mhh, weird
22:34 fdobridge: <k​arolherbst🐧🦀> maybe something in the macro?
22:34 fdobridge: <g​fxstrand> Shouldn't be.
22:34 fdobridge: <m​arysaka> I rebased and applied your suggestion on isaspec MR btw @gfxstrand, do I need to squash the changes?
22:35 fdobridge: <g​fxstrand> Yeah, it should just be one patch in the end.
22:35 fdobridge: <m​arysaka> okay all good then thanks 👍
22:38 fdobridge: <g​fxstrand> Left you one more comment. Sorry I didn't notice that yesterday.
22:39 fdobridge: <m​arysaka> No issue
22:40 fdobridge: <g​fxstrand> Hrm... multiple clear tests failing: `dEQP-VK.draw.renderpass.multiple_clears_within_render_pass.clear_clear_c_r8g8b8a8_snorm_d_d16_unorm_big_triangle`
22:44 fdobridge: <m​arysaka> should be all good now :AkkoYay:
22:44 fdobridge: <k​arolherbst🐧🦀> @gfxstrand what's the oldest you've got? maxwell 1st?
22:45 fdobridge: <g​fxstrand> Ok, I gave you an RB tag. Throw it on there and I'll assign marge.
22:45 fdobridge: <g​fxstrand> I think I got a Kepler.
22:46 fdobridge: <g​fxstrand> I don't have Pascal
22:47 fdobridge: <g​fxstrand> I don't have Pascal. They're not the cheapest yet and we'll likely never be able to reclock them so...
22:47 fdobridge: <k​arolherbst🐧🦀> odd that even the 1030 are still quite pricy
22:48 fdobridge: <k​arolherbst🐧🦀> odd that even the 1030 are still quite pricey (edited)
22:48 fdobridge: <k​arolherbst🐧🦀> ohh.. there are some cheap ones
22:49 fdobridge: <g​fxstrand> It was enough that I didn't want to bother. I'll probably pick one up at some point for completeness.
22:50 fdobridge: <m​arysaka> I have one around I think if you ever want me to test stuffs I guess
22:50 fdobridge: <g​fxstrand> Meh. We've got lots of hardware to play with for now.
22:50 fdobridge: <g​fxstrand> I doubt there will be a lot of Pascal-specific bugs.
22:50 fdobridge: <k​arolherbst🐧🦀> yeah.. there shouldn't be
22:51 fdobridge: <k​arolherbst🐧🦀> pascal is more or less like 2nd gen maxwell
22:51 fdobridge: <k​arolherbst🐧🦀> just compute launches are a bit different
22:51 fdobridge: <k​arolherbst🐧🦀> but they are like turing, soo...
22:51 fdobridge: <m​arysaka> In my brain it's 3rd gen maxwell :AkkoDerp:
22:51 fdobridge: <k​arolherbst🐧🦀> kepler is interesting because it uses the old texture headers
22:51 fdobridge: <k​arolherbst🐧🦀> yeah.. sounds about right 😄
22:52 fdobridge: <k​arolherbst🐧🦀> all that generation mess is quite fuzzy on nvidia anyway
22:52 fdobridge: <k​arolherbst🐧🦀> it's not like they redesign the entire GPU
23:03 fdobridge: <g​fxstrand> @marysaka I just remembered: We should add some sort of a `bitsize % 32 == 0` assert in the python too. I commented and Rob left a ➕ so I assume that's agreement.
23:03 fdobridge: <m​arysaka> ah right :painpeko:
23:04 fdobridge: <m​arysaka> the question is where should we put it as all the code seems to already assume 32 bits (there is division around by 32 for example)
23:04 fdobridge: <g​fxstrand> Something like this should do:
23:04 fdobridge: <g​fxstrand> ```python
23:04 fdobridge: <g​fxstrand> # We only support multiples of 32 bits for now
23:04 fdobridge: <g​fxstrand> assert isa.bitsize % 32 == 0
23:05 fdobridge: <g​fxstrand> ```
23:05 fdobridge: <g​fxstrand> Right after
23:05 fdobridge: <m​arysaka> Maybe in the ISA constructor...?
23:05 fdobridge: <g​fxstrand> Something like this should do:
23:05 fdobridge: <g​fxstrand> ```python
23:05 fdobridge: <g​fxstrand> # We only support multiples of 32 bits for now
23:05 fdobridge: <g​fxstrand> assert isa.bitsize % 32 == 0
23:05 fdobridge: <g​fxstrand> ```
23:05 fdobridge: <g​fxstrand> Right after
23:05 fdobridge: <g​fxstrand> ```python
23:05 fdobridge: <g​fxstrand> s = State(isa)
23:05 fdobridge: <g​fxstrand> ``` (edited)
23:05 fdobridge: <m​arysaka> or actually in validate_isa...
23:05 fdobridge: <g​fxstrand> I'd put it in the generator because that's where the problem is.
23:05 fdobridge: <g​fxstrand> I think the ISA constructor theoretically doesn't care.
23:06 fdobridge: <m​arysaka> format and value methods does divide by 32 though.
23:07 fdobridge: <g​fxstrand> Yeah, I guess they do.
23:07 fdobridge: <🌺​ ¿butterflies? 🌸> NV rolls out new blocks when they are ready
23:08 fdobridge: <m​arysaka> I don't mind anywhere tbh, I'm not too familiar with that code, I will just do as you want
23:08 fdobridge: <g​fxstrand> Ok, yeah, I think `validate_isa()` is the right place.
23:08 fdobridge: <k​arolherbst🐧🦀> sure, but rolling out new blocks and trashing the entire API to it are two separate things
23:12 fdobridge: <m​arysaka> Pushed the changes
23:13 fdobridge: <g​fxstrand> You still need to add my `Reviewed-by:` tag to the commit message. Yeah, that bit's annoying. We might be doing away with it in the not-too-distant future.
23:13 fdobridge: <g​fxstrand> But we still use them for common code.
23:13 fdobridge: <m​arysaka> oh I wasn't sure if that was fine as you asked another change here
23:13 fdobridge: <g​fxstrand> Yeah, it's good now.
23:14 fdobridge: <m​arysaka> ok then 👍
23:14 fdobridge: <m​arysaka> okay pushed that, thanks for help 😄
23:15 fdobridge: <m​arysaka> okay pushed that, thanks for your help 😄 (edited)
23:17 fdobridge: <g​fxstrand> There you go. Assuming CI doesn't fail for silly reasons, it should land in an hour or two. 😄
23:22 fdobridge: <m​arysaka> What would be the next steps after that btw? Like should my MR contains your MME builder structure change or is that going to be part of another MR? (or directly nvk/main)
23:23 fdobridge: <g​fxstrand> I'm happy for your MR to contain all the new MME stuff.
23:23 fdobridge: <g​fxstrand> No need to split it into multiple MRs by author.
23:23 fdobridge: <g​fxstrand> We just need something that makes some amount of sense and isn't going to build-break in the middle.
23:24 fdobridge: <m​arysaka> I see
23:31 fdobridge: <m​arysaka> Well I made sure that at least the last 8 commits are buildeable, not sure of the one before :AkkoDerp:
23:31 fdobridge: <m​arysaka> I guess I will test that a bit
23:35 fdobridge: <k​arolherbst🐧🦀> know that `git rebase -i origin/main --exec 'ninja -C build'` trick? It is a wonderful way of checking.
23:37 fdobridge: <m​arysaka> oh that's a nice one :linaalert:
23:46 fdobridge: <m​arysaka> well everything build already :linakira: