00:30 <bloom> Oh, and by properly splitting out unaligned/aligned portions, the M1 gets the job done in 0.33s while the RK3399 is at ~1.58s

00:31 <bloom> What's intriguing there is that the optimization helps only 4% on the Rockchip but 23% on the Apple.

00:32 <bloom> The optimization reducing ALU while keeping memory access constant. So it seems not only is the ALU on the Mac all around faster, the memory is _so_ much better.

00:32 <davidrysk[m]> https://lemire.me/blog/2021/01/06/memory-access-on-the-apple-m1-processor/

00:32 <davidrysk[m]> This was making the rounds the other day, but these tests are too elementary to really provide any interesting info

00:32 <bloom> I don't think that should come as a surprise to anyone, memory performance is critical to both CPU and GPU performance, and if you want to kick ass at both for an SoC, optimizing the hell out of the memory access is a 2 for 1 deal..

00:34 <icecream95> https://www.sevarg.net/generated/images/2021-qemu-m1/mbw-1200-b48fbb189.png

00:34 <davidrysk[m]> I wish we knew more about Apple's (CPU) microarchitecture. From what I can tell, they're still using the scheduler model that was intended for Cyclone (A7) in LLVM, and that chip had much less instruction level parallelism available.

00:35 <bloom> icecream95: Oh, hello there.

00:36 <bloom> If this is about your NEON routine, yes, you win, I'm over it, we both know you're better at writing tiling routines than me :P

00:39 <icecream95> bloom: IIRC My NEON tiling routine was "only" about 3x faster

01:01 <bloom> How could I forget?

02:19 <krbtgt> iirc wrt tiling: i think powervr/nvidia/apple are the biggestg users of it

02:22 <bloom> krbtgt: Everybody uses it as much as they can.

02:24 <krbtgt> huh, i thought other companies had different strategies, but it's been a while since i looked into it

02:25 <bloom> krbtgt: The specific tiling patterns vary, but everyone uses some form of tiling.

02:37 <davidrysk[m]> https://developer.amd.com/wordpress/media/2012/10/gdc2008_ribble_maurice_TileBasedGpus.pdf

02:37 <davidrysk[m]> found this with a quick google :)

02:37 <bloom> Mary_-: Sorry for forgetting to respond, but neat stuff! :) re: meallib

02:38 <bloom> tiling != tiling..

02:38 <bloom> Overloaded term :(

04:08 <bloom> Wat?

04:08 <bloom> Why is u64 load/stores more than 2x slower than u32 load/stores on a 64-bit machine?

04:09 <bloom> (the rockchip, mac is off)

05:41 <marcan> bloom: not just memory though, the CPU pipe to memory

05:41 <marcan> it seems their load/store buffers are way wider than anything else

05:41 <marcan> more outstanding transactions

09:46 <marcan> PSA: we are adjusting the RE policy and banning userspace GPU stack disassembly, since it is unlikely that approach will be necessary. at the same time, this channel is no longer allowed for any kind of disasm/binary RE

09:47 <marcan> we are not banning GPU kernel driver disassembly (but see https://alx.sh/re for the policy), but that discussion will be confined to #asahi-re

09:47 <marcan> this channel is therefore now "clean"

09:49 <marcan> the discussion here should focus on black-box RE of the userspace stack (what bloom is doing), and on hardware details and kernel driver development discussion (strictly *results* i.e. documentation resulting from kernel driver RE are allowed only, absolutely no discussion of the actual kext code)

09:50 <marcan> that is, this channel is the clean end of the clean room now

16:04 <davidrysk[m]> bloom: Is there any documentation on retrieving compiled and assembled object code of a shader?

17:29 <bloom> davidrysk[m]: 'documentation'? no, fraid not

17:29 <bloom> https://github.com/AsahiLinux/gpu/blob/main/wrap/wrap.c#L140

17:29 <bloom> I was hardcoded offsets

17:29 <bloom> *hardcoding

17:29 <bloom> but it shows up in mem_0.bin if you dump with the wrap library there

17:29 <bloom> and wrap should be clang'able by just *.c -framework IOkit -dylib or something like that

17:30 <bloom> (there is some code I need to push to help with that, but my local setup is still a giant mess of shell scripts split acorross two machines)

17:33 <davidrysk[m]> bloom: "Does that require dual licensing the other files too?" APSL sections 1.5 and 4 seem to say no

17:51 <bloom> davidrysk[m]: Ah, thank you :)