06:56 <HdkR> https://www.cnx-software.com/2023/01/05/nxp-i-mx-95-processor-arm-cortex-a55-cortex-m33-and-cortex-m7-cores-eiq-neutron-npu/

06:56 <HdkR> Looks like a new platform for long-term Panfrost support \o/

08:40 <daniels> yep, just a shame about the A55

09:23 <mntirc> just wanted to post this :D

09:28 <HdkR> daniels: They could have at least given us A510 :P

09:32 <mntirc> there must be some successor to that rare c72 imx8 under wraps?

09:33 <HdkR> Has to be

09:34 <HdkR> Swap the cores with A710/A715, would be pretty nifty

14:13 <alyssa> "Unnamed Arm Mali 3D GPU"

14:13 <alyssa> Mm, that's my favourite

15:17 <HdkR> alyssa: Just think, it could be a brand new uarch to RE

15:18 <HdkR> So mysterious, much allure

15:25 <CounterPillow> G52 but cut down to 0 EE

15:25 <CounterPillow> (you have to calculate the bits on pen and paper)

16:17 <alyssa> HdkR: I'm cautiously optimistic Arm won't scrap Valhall+CSF

16:17 <alyssa> for at least 12 months

16:23 <HdkR> I'm hoping Mali-G is to the point that it'll just end up being subtle differences to cause minor annoyances now

16:23 <daniels> that’s cute

16:24 <alyssa> ++

16:24 <alyssa> we might even get another year and a half before Arm decides that actually data flow architectures are in and resurrects the mali-400 GP

16:30 <HdkR> Maybe it'll be fine when GPU's just switch to BVH intersection testing engines :P

16:32 <alyssa> don't even joke about that

16:34 <HdkR> Oh sorry, they need to intersect with triangles as well

16:45 <robmur01> heh, despite the conspicuous lack of detail everywhere else, the PDF factsheet hotlinks "Arm Mali GPU" to https://developer.arm.com/Processors/Mali-G310 :D

16:46 <robmur01> 15 years of weeny little Valhall to look forward to!

16:50 <HdkR> oh hah

16:51 <HdkR> At least it supports 16x MSAA, so inevitably some game won't know what it is, and it maxes out the AA because it must be a powerful future GPU

16:52 <robmur01> best not run games on your industrial HMI anyway :P

16:55 <q4a> alyssa: I experimenting with lowering constants. But currently got error: Invalid type of source 0: r2 = MOV.i32 #0x20001800

16:56 <q4a> What's wrong?(

16:56 <HdkR> robmur01: The only thing that can stop me is a lack of a vulkan driver

17:14 <q4a> I'm trying to add a rule: if the simple ways of lowering constant didn't work and fau isn't full, then don't change the constant with `va_mov_imm(&b, const_value)`

17:14 <q4a> It should help in 1-18.shader_test

17:15 <q4a> IADD_IMM.i32 r1, 0x0, #0x32683800

17:15 <q4a> IADD_IMM.i32 r2, 0x0, #0x3A663800

17:15 <q4a> FMA.v2f16 r1, r0.h00, ^r1, ^r2

17:16 <q4a> Instead of 3 current ^ inst, I hope to see: FMA.v2f16 r1, r0.h00, #0x32683800, #0x3A663800

17:28 <q4a> ok, based on `va_pack_src` I need to push constant to fau and get BI_INDEX_FAU

17:32 <alyssa> right

17:33 <alyssa> You'll need to add a mechanism to tell the driver "upload these constants to these FAU slots" -- just like we already have a mechanism that says "upload these UBO words to these FAU slots" -- and then patch the driver to do that upload

17:39 <q4a> FAU slots is 16-bit size, but constant is 32-bit size, so I need ti use 2 FAU slots, right?

17:40 <q4a> hmm.. looks like I saw UBO words and this words are 16-bit size

17:59 <alyssa> FAU slots 64-bit double words

17:59 <alyssa> typically accessed as 32-bit low or high halves