09:07fdobridge: <karolherbst🐧🦀> if you thought supporting nv30 is absurd, today we got a bug against nv10 from a user still using the hardware :ferrisUpsideDown:
09:13fdobridge: <karolherbst🐧🦀> but they also submitted the fix, so I guess that's good 😄
09:20fdobridge: <pac85> I've got this thing not sure what it is
09:20fdobridge: <pac85> https://cdn.discordapp.com/attachments/1034184951790305330/1165942747706970122/IMG_20231023_111941.jpg?ex=6548afcd&is=65363acd&hm=0f5082e1246c8c55bd67baccdad6e60deb8efbb238bb75617428162e042a1bb1&
09:20fdobridge: <karolherbst🐧🦀> probably fx 5200 or something
09:20fdobridge: <karolherbst🐧🦀> that's nv30 anyway
09:21fdobridge: <pac85> Uh I see thx
09:21fdobridge: <karolherbst🐧🦀> I have the exact same one 😄
09:21fdobridge: <karolherbst🐧🦀> it has a nv35 label on it
09:22fdobridge: <pac85> Is there something interesting it can do? Seems like it can only support gl 2.1
09:22fdobridge: <karolherbst🐧🦀> running gnome
09:23fdobridge: <pac85> That's something
09:26fdobridge: <karolherbst🐧🦀> yeah.. we fixed it like this and last year as it was broken since forever 😄
09:27fdobridge: <karolherbst🐧🦀> https://gitlab.freedesktop.org/mesa/mesa/-/commit/7908cb895e2dea8cff91cecb53457a099dc96b07
09:27fdobridge: <pac85> Oh wow, wouldn't have thought there would be interest in such old hw
09:28fdobridge: <pac85> Oh wow, wouldn't have thought there would be some interest in such old hw (edited)
09:28fdobridge: <karolherbst🐧🦀> and the most embarassing fix https://gitlab.freedesktop.org/mesa/mesa/-/commit/1387d1d41103b3120d40f93f66a7cfe00304bfd7
09:29fdobridge: <pac85> Uh lol
09:29fdobridge: <karolherbst🐧🦀> it was broken since the initial code drop 😄
09:36fdobridge: <conan_kudo> :facepalmsonic:
09:36fdobridge: <pac85> Whoooops
09:37fdobridge: <pac85> Well, nv30 users can finally take advantage of the full potential of their hw
09:48fdobridge: <karolherbst🐧🦀> yeah.. the main reason it wasn't found earlier was that desktops weren't hitting that code path before
09:49fdobridge: <pac85> Uhm I see
12:21fdobridge: <dwlsalmeida> @vdpafaor I am working on a refactor of sm50 to eliminate encode_alu() and friends, maybe wait for this if you want to contribute on top?
13:00fdobridge: <gfxstrand> I should probably take a look at the sm50 branch soon. It looks like we're having to add a bunch of new versions of things and I'd like to have a more unified plan for how we're going to do that.
13:01fdobridge: <gfxstrand> I think OpLd and OpSt should be fine but I know a bunch of the ALU is different.
13:10fdobridge: <karolherbst🐧🦀> yeah.. probably a good idea
13:11fdobridge: <karolherbst🐧🦀> some instructions get a new name, but sometimes you get added/removed support for some bit sizes or flags or other funky details
13:11fdobridge: <gfxstrand> Yeah
13:11fdobridge: <karolherbst🐧🦀> it's one of the biggest pain points of codegen and I'd like to not run into the same mistakes
13:11fdobridge: <gfxstrand> Yup
13:11fdobridge: <gfxstrand> And that's why I want to apply my editorial voice a bit
13:12fdobridge: <gfxstrand> I think the best thing to do at the moment is for the folks working on nv50 to just liberally insert SM checks in nak_from_nir.rs and plan to figure out how to unify later.
13:13fdobridge: <karolherbst🐧🦀> NAK could also work in two stages... first to do passes which work on all gens, and then lower/convert to arch specific.. but that could add a lot of code and complexity, but might be better than trying to force all ISAs into a common IR
13:14fdobridge: <karolherbst🐧🦀> like most of hte UBO pulls can just be moved into registers across all gens, might just require some callbacks to check if it's allowed for specific archs (or they get unpulled later) but yeah.. not sure what would be the best approach overall
13:17fdobridge: <gfxstrand> Yeah, I want to see it all in front of me before trying to come up with a grand unified plan that turns out to be busted.
13:17fdobridge: <gfxstrand> Yeah... I want to see it all in front of me before trying to come up with a grand unified plan that turns out to be busted. (edited)
13:18fdobridge: <gfxstrand> Premature unification is about as useful as premature optimization
13:18fdobridge: <karolherbst🐧🦀> yeah
13:24fdobridge: <gfxstrand> My original plan was to "unify" on Turing but Turing is enough more clever than some of the older generations that IDK that we really want to do that, at least for integer ops.
13:24fdobridge: <karolherbst🐧🦀> Turing is kinda weird, because it's like the same ISA compared to Volta, just with more stuff
13:24fdobridge:<karolherbst🐧🦀> but
13:24fdobridge: <gfxstrand> Float should be fine. There's not a lot of clever there.
13:25fdobridge: <karolherbst🐧🦀> Volta is different enough compared to the previous stuff
13:25fdobridge: <karolherbst🐧🦀> it probably makes sense to have some ISA groups
13:25fdobridge: <karolherbst🐧🦀> like SM1x, SM2x + SM30, SM35, SM5x + SM6x, SM7x+
13:26fdobridge: <dwlsalmeida> @gfxstrand I am merely removing encode_alu in favor of set_field() and friends, a-la sm75, I thought we had agreed on that?
13:26fdobridge: <dwlsalmeida> i.e. that it was more typing, but more clear in the end?
13:26fdobridge: <karolherbst🐧🦀> no sure how much hooper is different with its SM90
13:28fdobridge: <gfxstrand> Yeah, that's all fine
13:28fdobridge: <gfxstrand> I'm more concerned with things like where Maxwell doesn't have LOP3 and we have to do something else.
13:29fdobridge: <gfxstrand> Shifts are another strange one
13:29fdobridge: <gfxstrand> Really, all the integer stuff gets funky
13:29fdobridge: <karolherbst🐧🦀> yeah...
13:29fdobridge: <gfxstrand> All the core ones, anyway
13:29fdobridge: <karolherbst🐧🦀> and then you have funky exceptions like fma with an imm32 as this affects RA
13:29fdobridge: <gfxstrand> On Turing, they got really clever with ways to make int64 fast(ish) and they're all a bit clever.
13:31fdobridge: <marysaka> Kind of tried to make all the SM5x/SM6x related changes to common code separate to the actual encoder stuffs so hopefully it's not too much of a mess for you to review 😅
13:46fdobridge: <gfxstrand> @karolherbst I just learned who is to blame for the global load/store helpers bit. 😂
13:46fdobridge: <karolherbst🐧🦀> I hope it's me
13:48fdobridge: <gfxstrand> Oh, I mean who at NVIDIA added the bit.
13:48fdobridge: <karolherbst🐧🦀> ahhh
13:48fdobridge: <karolherbst🐧🦀> I see
13:49fdobridge: <karolherbst🐧🦀> ohh that helper invoc stuff?
13:49fdobridge: <gfxstrand> Yup
13:49fdobridge: <gfxstrand> I'm at a Khronos F2F and was chatting w/ folks and someone admitted to adding that bit. 😂
13:50fdobridge: <karolherbst🐧🦀> 😄
13:50fdobridge: <karolherbst🐧🦀> I hope they had a good reason?
13:51fdobridge: <gfxstrand> Mostly that they weren't sure where stuff was going to fall with the spec so they left themselves options.
13:51fdobridge: <karolherbst🐧🦀> ahh
13:51fdobridge: <karolherbst🐧🦀> that's pretty reasonable actually
14:01fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> What SMs can support D3D SM6 shaders? 😅
14:02fdobridge: <karolherbst🐧🦀> I have no idea
14:02fdobridge: <karolherbst🐧🦀> what's D3D SM6 anyway?
14:02fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/hlsl-shader-model-6-0-features-for-direct3d-12
14:03fdobridge: <karolherbst🐧🦀> SM35 I'd guess?
14:03fdobridge: <karolherbst🐧🦀> SM35 added shuffle
14:03fdobridge: <karolherbst🐧🦀> but no half stuff.. uhh
14:03fdobridge: <karolherbst🐧🦀> mhh
14:03fdobridge: <karolherbst🐧🦀> yeah dunno
14:06fdobridge: <gfxstrand> Ugh... No JOINAT on Turing+
14:07fdobridge: <karolherbst🐧🦀> welll
14:07fdobridge: <karolherbst🐧🦀> there is
14:08fdobridge: <karolherbst🐧🦀> @gfxstrand `BSSY` and `BSYNC`
14:08fdobridge: <karolherbst🐧🦀> it uses barriers starting with Volta
14:09fdobridge: <karolherbst🐧🦀> it kinda works the same even
14:16fdobridge: <gfxstrand> Yeah
14:16fdobridge: <gfxstrand> I need to figure out how that stuff works for realz
14:16fdobridge: <karolherbst🐧🦀> well.. it's simple 😛
14:16fdobridge: <gfxstrand> It's "simple" until you realize we only have 15 barrier registers
14:16fdobridge: <karolherbst🐧🦀> just do it around the outer most cfg
14:17fdobridge: <gfxstrand> Well, sure, I could do that
14:17fdobridge: <karolherbst🐧🦀> but you can also spill barriers to regs
14:17fdobridge: <karolherbst🐧🦀> `B2R` and `R2B`
14:17fdobridge: <gfxstrand> For that matter, I could put a WARPSYNC at any point where we re-converge back to uniform control-flow
14:18fdobridge: <karolherbst🐧🦀> right...
14:18fdobridge: <karolherbst🐧🦀> I think in codegen we've done it like two levels into the loop or something
14:18fdobridge: <karolherbst🐧🦀> it kinda makes sense to converge on loop iterations so
15:34fdobridge: <mhenning> iirc, codegen always reconverges loops before gv100 because it's fundamental to how the control flow works
15:35fdobridge: <mhenning> it has a limit on how deep we nest reconvergence for if statements because we don't size the hardware stack correctly (also pre-gv100)
15:35fdobridge: <karolherbst🐧🦀> it's broken though :ferrisUpsideDown:
15:35fdobridge: <mhenning> post gv100, I'm pretty sure there's just no reconvergence at all
15:36fdobridge: <karolherbst🐧🦀> we execute `warpsync` which kinda does the same, just in a different way or something
15:37fdobridge: <mhenning> right, but not on control flow - only when some other operator needs it
15:37fdobridge: <karolherbst🐧🦀> yeah
15:37fdobridge: <karolherbst🐧🦀> doing it in control flow is mostly a perf optimization
15:37fdobridge: <karolherbst🐧🦀> I have code to actually support it for volta+, just it never fixed anything
15:37fdobridge: <karolherbst🐧🦀> and doing benchmarks is kinda.. uhh.. hard
15:38fdobridge: <karolherbst🐧🦀> but the infra is mostly there. I've added the barrier stuff for quadop operations for 3d texgrad lowering
15:50fdobridge: <mhenning> at any rate, I think a reasonable design here would be to have two different passes to insert control flow pre-gv100 and post-gv100
15:50fdobridge: <mhenning> the control flow models are different enough that I think it's cleanest to convert to one or the other starting at nir's structured control flow
15:50fdobridge: <mhenning> which would probably mean splitting the conversion from nir into two stages: 1) convert basic blocks 2) insert control flow
15:51fdobridge: <karolherbst🐧🦀> yeah... potentially. Though you can map the pre volta thing pretty easily to the volta thing _if_ you make them use barriers and just throw them away pre volta
15:51fdobridge: <karolherbst🐧🦀> or something
15:52fdobridge: <mhenning> Oh, you mean insert both and discard the one you don't need?
15:52fdobridge: <karolherbst🐧🦀> yeah
15:52fdobridge: <karolherbst🐧🦀> that's how I kinda did it in codegen
15:52fdobridge: <karolherbst🐧🦀> `popon`/`popoff` always emits a barrier and I just handle it arch specific later
15:53fdobridge: <karolherbst🐧🦀> ehh
15:53fdobridge: <karolherbst🐧🦀> `quadon` and `quadpop`?
15:54fdobridge: <karolherbst🐧🦀> though I think I only insert the barrier for gm107+
15:54fdobridge: <karolherbst🐧🦀> was kinda the easiest way to deal with it 😄
16:10benjaminl: marysaka: do you want me to MR the sm50 stuff I was working on over the weekend to your branch? I know there was some discussion about making a branch on mesa/mesa earlier, but don't remember how that landed
16:20fdobridge: <marysaka> you mean on nouveau/mesa?
16:21fdobridge: <marysaka> but sure you can MR that on my branch 👍
16:32benjaminl: for commit organization, I know https://docs.mesa3d.org/submittingpatches.html says that commits should be bisectable. In this case, we're implementing a thing that didn't previously work, so I'm assuming that just means "don't have a commit that breaks the build or regresses non-sm50 stuff"?
16:42fdobridge: <orowith2os> @karolherbst got something to fact check with you
16:42fdobridge: <orowith2os> > fun fact: NVK actually uses repr(C) to be able to get slices of side-by-side fields
16:42fdobridge: <orowith2os> > (or *used*; I dunno if that stuck around)
16:42fdobridge: <orowith2os> courtest of Refi
16:43fdobridge: <karolherbst🐧🦀> yeah, that's required
16:43fdobridge: <karolherbst🐧🦀> rust repr can reorder fields
16:43fdobridge: <karolherbst🐧🦀> I actually ran into that issue in rusticl, because I forgot it on one type
16:43fdobridge: <karolherbst🐧🦀> and the offset of the first field became non 0 with a rustc update
16:44fdobridge: <karolherbst🐧🦀> but these days I don't use repr(C) anymore unless for things C code interacts with
16:44fdobridge: <karolherbst🐧🦀> @gfxstrand even talked about it on the NAK XDC talk on why that is
16:45fdobridge: <karolherbst🐧🦀> tldr: being able to declare dests/src in a struct with names without using arrays, but still being able to get slices over all of them
16:46fdobridge: <karolherbst🐧🦀> so e.g.
16:46fdobridge: <karolherbst🐧🦀> ```rust
16:46fdobridge: <karolherbst🐧🦀> #[repr(C)]
16:46fdobridge: <karolherbst🐧🦀> struct R {
16:46fdobridge: <karolherbst🐧🦀> a: Src,
16:46fdobridge: <karolherbst🐧🦀> b: Src,
16:46fdobridge: <karolherbst🐧🦀> }
16:46fdobridge: <karolherbst🐧🦀> ```
16:46fdobridge: <karolherbst🐧🦀> and then some proc macro magic adds a `R::srcs_as_slice` method which returns `&[Src]`
16:46fdobridge: <karolherbst🐧🦀> names might be different
16:59benjaminl: https://gitlab.freedesktop.org/benjaminl/envyfuzz also wrote this for REing instruction encodings, possible it would be useful to other people
17:14fdobridge: <marysaka> benjaminl: you might want to set SM53 instead of SM52 for fp16 stuffs
17:15fdobridge: <marysaka> but nice thing!
17:21benjaminl: thanks!
17:23benjaminl: good catch with SM53. I forgot that I had changed the sm50 input to map to SM52 in the first place. *probably* the thing that makes the most sense here is to just allow arbitrary sm[57][0-9] on the CLI and parse it internally
17:25fdobridge: <gfxstrand> Yup and the `DstsAsSlice` and `SrcsAsSlice` implementation macros assert that it's `repr(C)`
17:26benjaminl: are sm70 and sm75 mostly the same encoding?
17:27fdobridge: <karolherbst🐧🦀> yes
17:27fdobridge: <karolherbst🐧🦀> sm75 added uniform regs/preds
17:27fdobridge: <karolherbst🐧🦀> probably the biggest change
19:45fdobridge: <gfxstrand> Ugh... `gl_SubgroupId`...
19:47fdobridge: <karolherbst🐧🦀> what about it?
19:47fdobridge: <gfxstrand> It requires us to understand the mapping from `gl_InvocationIndex` to subgroups
19:48fdobridge: <gfxstrand> Looking at dumps out of the blob, they seem to change the calculation entirely depending on workgroup size. I'm still trying to figure out the details
19:48fdobridge: <karolherbst🐧🦀> huh?
19:48fdobridge: <gfxstrand> I really wish it were just a sysval
19:48fdobridge: <karolherbst🐧🦀> there are sys vals for those tho
19:49fdobridge: <gfxstrand> for `gl_SubgroupId`? I don't think so
19:49fdobridge: <karolherbst🐧🦀> 0 bits 4:0
19:49fdobridge: <karolherbst🐧🦀> ohh wait, that's thread id withing a subgroup
19:49fdobridge: <gfxstrand> Yeah
19:49fdobridge: <karolherbst🐧🦀> warp id is what you want.. right
19:50fdobridge: <karolherbst🐧🦀> Sr3 bits 14:8
19:50fdobridge: <gfxstrand> sr3?
19:50fdobridge: <karolherbst🐧🦀> yeah.. system value 3
19:50fdobridge: <karolherbst🐧🦀> the r stands for register
19:50fdobridge: <gfxstrand> right
19:51fdobridge: <karolherbst🐧🦀> but not sure how that all works out in detail, because there is some "virtual" thing going on
19:51fdobridge: <karolherbst🐧🦀> so 14:8 is the virtual warp id whatever that means
19:51fdobridge: <karolherbst🐧🦀> fun fact
19:51fdobridge: <karolherbst🐧🦀> SR0 and SR3 both have the lane id at 4:0
19:52fdobridge: <karolherbst🐧🦀> SR3 19:16 is the CTA id
19:52fdobridge: <karolherbst🐧🦀> and then 28:20 has the SM id
19:53fdobridge: <karolherbst🐧🦀> ohh there are two more bits for the CTA id at 30:29
19:53fdobridge: <karolherbst🐧🦀> hope that helps :ferrisUpsideDown:
19:53fdobridge: <karolherbst🐧🦀> there is also like the actual thread id at SR32+
19:53fdobridge: <karolherbst🐧🦀> but those you should already know about
19:54fdobridge: <karolherbst🐧🦀> SR3 just is very nvidia specific stuff
19:57fdobridge: <gfxstrand> So, SR32 is TID and SR33..36 appear to be `gl_LocalInvocationId` which isn't quite what I want
19:58fdobridge: <karolherbst🐧🦀> not quite
19:58fdobridge: <karolherbst🐧🦀> SR32 and SR33.35 are the same
19:58fdobridge: <karolherbst🐧🦀> just
19:59fdobridge: <karolherbst🐧🦀> SR32 packs all dimensions
19:59fdobridge: <gfxstrand> Right
19:59fdobridge: <karolherbst🐧🦀> SR32.35 is just the thread id within a block
19:59fdobridge: <karolherbst🐧🦀> a.k.a. CTA
19:59fdobridge: <karolherbst🐧🦀> and CTA id is at SR37..39 a.k.a grid
20:00fdobridge: <karolherbst🐧🦀> Warps == subgroups is at SR3
20:00fdobridge: <karolherbst🐧🦀> nvidia even has a system value for the warp size
20:00fdobridge: <karolherbst🐧🦀> it's just always 32
20:00fdobridge: <gfxstrand> hehe
20:00fdobridge: <karolherbst🐧🦀> at SR2 5:0
20:00fdobridge: <karolherbst🐧🦀> SR2 15:8 is the number of warps per SM
20:00fdobridge: <gfxstrand> What exactly is in SR3?
20:01fdobridge: <karolherbst🐧🦀> a couple of things
20:01fdobridge: <karolherbst🐧🦀> 4:0 subgroup thread id (probably)
20:01fdobridge: <karolherbst🐧🦀> 14:8 subgroup id (warp id)
20:02fdobridge: <karolherbst🐧🦀> 30:29 + 19:16 is the virtual CTA id
20:02fdobridge: <karolherbst🐧🦀> but that's not within the 3D grid and per SM
20:02fdobridge: <karolherbst🐧🦀> so more like the id if each virtual CTA running within the SM
20:02fdobridge: <karolherbst🐧🦀> 28:20 the SM id
20:02fdobridge: <karolherbst🐧🦀> nvidia has an extension for that stuff...
20:02fdobridge: <karolherbst🐧🦀> let me find it
20:03fdobridge: <karolherbst🐧🦀> `GL_NV_shader_thread_group`?
20:03fdobridge: <karolherbst🐧🦀> sounds about right..
20:04fdobridge: <karolherbst🐧🦀> there had this cool demo where you can see on which SM/warp each pixel gets rendered on
20:05fdobridge: <gfxstrand> So warp ID is relative to the current workgroup, not a physical warpID within the hardware, right?
20:05fdobridge: <karolherbst🐧🦀> ohh.. there is also `GL_NV_shader_sm_builtins`
20:05fdobridge: <karolherbst🐧🦀> I think so
20:06fdobridge: <gfxstrand> Yeah, no.
20:06fdobridge: <gfxstrand> If this maps to GL_NV_shader_thread_group, it's physical IDs
20:07fdobridge: <karolherbst🐧🦀> it's per SM as far as I can tell
20:07fdobridge: <gfxstrand> Yeah
20:07fdobridge: <gfxstrand> That's not `gl_SubgroupId`
20:07fdobridge: <karolherbst🐧🦀> multiply it with the SM id
20:07fdobridge: <karolherbst🐧🦀> ehh
20:07fdobridge: <karolherbst🐧🦀> or something
20:08fdobridge: <gfxstrand> No
20:08fdobridge: <karolherbst🐧🦀> you have the number of warps per SM
20:08fdobridge: <gfxstrand> `gl_SubgroupId` is a linear subgroup index within the workgroup.
20:08fdobridge: <karolherbst🐧🦀> right
20:08fdobridge: <karolherbst🐧🦀> mhhh
20:08fdobridge: <gfxstrand> It's entirely a logical thing, physical SM numbers don't help me
20:10fdobridge: <karolherbst🐧🦀> but for the subgroup_invocation nvidia also uses SR0/SR3 4:0, right?
20:11fdobridge: <gfxstrand> Nope
20:11fdobridge: <karolherbst🐧🦀> what are they doing instead then?
20:11fdobridge: <gfxstrand> The only sysvals I see are TID.XYZ, CTAID.XYZ, and LANEID
20:12fdobridge: <karolherbst🐧🦀> yeah, LANEID is SR0
20:12fdobridge: <karolherbst🐧🦀> 31:5 are zero
20:12fdobridge: <karolherbst🐧🦀> TID.XYZ is SR33..35
20:12fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1166106953110532187/blob-shader.txt?ex=654948ba&is=6536d3ba&hm=141c0b7661fd91b4a07852099919e43d15c40ecc194f48029cf75117771cb1b4&
20:12fdobridge: <karolherbst🐧🦀> CTAID.XYZ is SR37..39
20:13fdobridge: <karolherbst🐧🦀> mhhhh
20:13fdobridge: <karolherbst🐧🦀> what's in the uniform?
20:14fdobridge: <gfxstrand> The `STG` at the end writes `uvec4(gl_SubgroupSize, gl_SubgroupInvocationID, gl_NumSubgroups, gl_SubgroupID)`
20:14fdobridge: <gfxstrand> No clue!
20:14fdobridge: <karolherbst🐧🦀> okay.. let's see...
20:14fdobridge: <gfxstrand> I also have no idea why there's an LEA in there
20:14fdobridge: <karolherbst🐧🦀> could hack the test and only write one of those values
20:15fdobridge: <gfxstrand> I guess the `LEA` is a hack to avoid 64-bit arithmetic
20:15fdobridge: <gfxstrand> But, yeah, no idea what the magic uniforms are
20:17fdobridge: <gfxstrand> I suspect `c[0x0][0x20..0x2c]` is `baseGroupX/Y/Z`
20:18fdobridge: <karolherbst🐧🦀> `LEA R4, P0, R3, c[0x0][0x30], 0x4 ; ` -> `R4 = R3 << 0x4 + c[0x0][0x30]` I think
20:19fdobridge: <karolherbst🐧🦀> yeah.. wouldn't surprise me
20:20fdobridge: <karolherbst🐧🦀> so `gl_SubgroupSize` is just constant 0x20, which totally makes sense
20:20fdobridge: <karolherbst🐧🦀> `gl_SubgroupInvocationID` is `SR_LANEID` also makes sense
20:21fdobridge: <karolherbst🐧🦀> `gl_NumSubgroups` is `0x4`... okay?
20:21fdobridge: <karolherbst🐧🦀> `gl_SubgroupID` is weird math
20:21fdobridge: <gfxstrand> Yeah
20:22fdobridge: <gfxstrand> We need weird math
20:23fdobridge: <karolherbst🐧🦀> `R3 = R0 * (c[0x0][0x0] * 0x3) + (SR_CTAID.X + c[0x0][0x20]) * 0x3 + SR_TID.X`?
20:24fdobridge: <karolherbst🐧🦀> and whatever R0 is
20:24fdobridge: <karolherbst🐧🦀> mhhh
20:24fdobridge: <karolherbst🐧🦀> that kinda doesn't feel like `gl_SubgroupID`...
20:24fdobridge: <karolherbst🐧🦀> ohhh wait
20:25fdobridge: <karolherbst🐧🦀> `gl_SubgroupID` is across _all_ subgroups over _all_ blocks?
20:25fdobridge: <karolherbst🐧🦀> also all grids?
20:25fdobridge: <karolherbst🐧🦀> if it's across the entire thing, then it makes sense they pull in the block size/id
20:28fdobridge: <karolherbst🐧🦀> ehh.. should be within the block
20:28fdobridge: <karolherbst🐧🦀> weird...
20:28fdobridge: <karolherbst🐧🦀> it makes no sense
21:06fdobridge: <karolherbst🐧🦀> the code is clearly mapping a 3D space to 1D, but uhhh....
21:23fdobridge: <caitcatdev> Okay so atm I am using EGL I want to know how it works internally
21:23fdobridge: <caitcatdev> so I guess it's time
21:24fdobridge: <caitcatdev> to peak at mesa