13:57alyssa: /o\
13:57alyssa: nir_lower_io's bounds checking doesn't match NVK's
13:57alyssa: I think nir_lower_io's is wrong.
13:58alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_lower_io.c#L1298-1307
13:59alyssa: suppose bound = 1000, offset = -8, size = 16
13:59alyssa: that code will check "7 < 1000" and conclude that's in-bounds
14:00alyssa: but of course the first two elements fault
14:00alyssa: I think this works out accidentally for SSBOs because of scalarization + alignment
14:04alyssa: jnoorman: i'm doing related work around SSBO bounds checking and I think it's probably easier to do efficiently with your shift stuff fwiw
14:18jnoorman: alyssa: great! Let me know if there's anything that can be improved in the MR to make your life easier.
14:18alyssa: :+1:
14:18alyssa: I'm still trying to figure out how this could fit together on agx
14:18alyssa: since we don't ingest load_ssbo in vulkan
14:19jnoorman: What do you ingest? load_global?
14:19alyssa: yeah
14:19alyssa: but that sucks because nir_lower_io's bounds checking code isn't good
14:20alyssa: so i'm working on a branch that plumbs in a load_global_bounded like load_global_constant_bounded
14:20alyssa: although that's just.. load_ssbo with an extra source for the bound, so..
14:20jnoorman: Ok, well you could take a look at the branch I linked in the SSBO shift MR, it implements global memory using offset_shift on ir3.
14:21alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35092 this one?
14:21alyssa: oh https://gitlab.freedesktop.org/jnoorman/mesa/-/commits/ir3-ldg-stg-ssbo-shift
14:21alyssa: right ok.
14:21jnoorman: Yes, indeed.
14:22alyssa: i'm going to do the simple stupid thing now and then maybe circle back once your stuff is landed
14:22jnoorman: 👍
14:23alyssa: current: `if (offset in bytes < bound in bytes) { load(base, offset in elements << 2) } phi(0)`
14:24alyssa: my branch: `valid = offset in bytes < bound in bytes; base = valid ? base : NULL; offset in elements = valid ? offset in elements : 0; load(base, offset in elements << 2)`
14:24alyssa: hypothetical future building on your work:
14:25alyssa: `valid = offset in elements < bound in elements; base = valid ? base : NULL; offset in elements = valid ? offset in elements : 0; load(base, offset in elements << 2)`
14:25alyssa: (don't materialize the shift at all)
14:25alyssa: I could do this without your stuff it would just be nasty pattern matching
14:26jnoorman: Right, that's what I'm trying to prevent with my MR :)
14:32alyssa: 1 file changed, 31 insertions(+), 14 deletions(-)
14:32alyssa: oops i did the pattern matching
15:45alyssa: deleted 13% of the spills in my fossildb, that's gotta help something
15:46alyssa: -89.40% spills on elden ring t_t
15:46alyssa: and -52.38% in MHW lol
15:47mattst88: wow, that's incredible
15:49alyssa: mattst88: the old impl was really bad =D
15:49alyssa:deletes a 0 from the usleep(100)
15:50mattst88: haha
15:50ccr: :P
16:03karolherbst: so what's the proper way to get access to a proper fossil-db thing? Work for the right company or do we have something developers can ping at and get access to something?
16:24anholt: karolherbst: one could set up a shader-db-private, probably using the same members as traces-db-private. but nobody has to my knowledge.
16:40pendingchaos: karolherbst: I can add you to radv_fossils, which is what some use
16:42anholt: pendingchaos: would love to get access too
16:49karolherbst: pendingchaos: sure
16:49karolherbst: thanks
17:05alyssa: radv_fossils is what I use
17:05alyssa: (despite not being on radv - it's largely fine, I think there's only 1 problem fossil)
17:07anholt: yeah, I use a whole mess of random stuff -- bits I captured for nvk, some igalia internal vkd3d fossils, whatever's in shader-db.
17:08karolherbst: I need to debug why my "convert this 8x4 phi into a 32 bith pack" let's some shaders explodes, and it's like... *sigh* I wished it would be one with like 200 blocks
17:08karolherbst: *wouldn't
17:08anholt: really need to go capture a bunch of fossils for replaying my gl app traces on zink, because I think we've got work to do on processing what zink hands us, but also I don't really want to do two separate runs and two separate reports before and after for every compiler change.
17:59zzyiwei: Hi, wonder if anyone can help take a look at the remained bits of the vulkan prime blit barrier fixes in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35034 Much appreciated!