03:40 <alyssa> 16: 9e138c0202840100 imadd r4_r5.cache, r6.cache, 32, u2

03:40 <alyssa> I *think* the u2 should be u2_u3..

03:41 <alyssa> from context of the shader I'm staring at

03:41 <alyssa> (Spoiler alert: bindless image writes are 100% a thing and it's a straightforward mechanism and I just need a bit more staring to get the details)

03:47 <alyssa> or not, uh

03:47 <alyssa> oh, no

03:47 <alyssa> I see what's happening. cute.

03:48 <alyssa> they implement (u32 * u32) + u64 in two instructions

03:48 <alyssa> lo_hi = mad(u32, u32, u64_lo)

03:48 <alyssa> hi = hi + u64_hi

03:49 <alyssa> i just mised the second add due to the scheduling

03:51 <alyssa> ok, so there's full bindless image_write, so what? well..

03:52 <alyssa> next question is whether there's proper bindless image load i missed

04:08 <alyssa> I still feel like I'm missing something

04:09 <alyssa> are these addresses 32-bits or not?!

04:11 <alyssa> maybe I just need to try to wire this stuff up and see what breaks.

04:47 <TellowKrinkle> I think the bindless register references are register pairs and we're not decompiling correctly

04:47 <TellowKrinkle> It usually sets up a valid pair before each of those calls

04:48 <TellowKrinkle> Actually maybe not

06:10 <i509vcb> hey ella-0, I recall hearing you have gotten vkcube to "work" on agxv. vkcube obviously requires WSI and agxv is probably some time away from working wsi so I imagine that showcase was probably from some fork of vkcube. I was wondering if you had the vkcube fork somewhere (if it even exists) to experiment with?

06:11 <i509vcb> I am interested in trying to see if I *could* help with agxv, but I guess I am a bit unfamiliar with the hardware and I imagine some stuff is probably blocking larger open contribution on that

21:32 <alyssa> an unknown ALU instruction? on M1?

21:32 <alyssa> likelier than you would think

21:35 <alyssa> er no it's a funny encoding of convert

21:38 <alyssa> this doesn't make any sense, why are they converting a float from uint to float

21:38 <alyssa> what kind of witchcraft is this

21:40 <alyssa> be91c8280000 is the spicy convert

21:40 <alyssa> for anyone following along at home

21:41 <alyssa> this is for alpha to coverage with msaa 4x

21:41 <alyssa> First, they calculate the alpha and clamp it to [0.0, 1.0]

21:41 <alyssa> Then, they multiply it with 255.0

21:41 <alyssa> So now they have a 32-bit float in the range of [0.0, 255.0]

21:42 <alyssa> Then they... reinterpret the float as a 32-bit integer and convert it to a float?

21:44 <alyssa> Range (0.0, 255.0] corresponds to an exponent of [-126, 7]

21:45 <alyssa> encoded as [1, 134]

21:45 <alyssa> sign bit is clear

21:45 <alyssa> and then adding back 0 we get an exponent range of [0, 134]

21:46 <alyssa> mantissa is free (save for denormals which have been flushed), so we end up encoding [0, 135 << 23)

21:47 <alyssa> so end up with a float in the range [0, 1132462080.0) i guess

21:47 <alyssa> this, this doesn't make sense to me why they would do that, which makes me think i'm missing something

21:56 <dottedmag> Ability of Apple engineers to make bugs?

21:57 <alyssa> dottedmag: No, I don't have any reason to think it's wrong

21:57 <alyssa> It just doesn't make sense what's happening

21:58 <alyssa> https://backtick.town/~bloom/alpha-to-coverage.txt

21:59 <alyssa> see https://developer.apple.com/documentation/metal/mtlrenderpipelinedescriptor?language=objc for the pseudo code, of course the actual expression is implementation-defined