01:26 fdobridge: <g​fxstrand> Maxwell B:
01:26 fdobridge: <g​fxstrand> `Pass: 354089, Fail: 1335, Crash: 1544, Warn: 4, Skip: 1776347, Timeout: 1, Flake: 50, Duration: 1:38:06`
01:28 fdobridge: <g​fxstrand> I'm going to try re-enabling the derivative and graphicsfuzz tests
01:29 fdobridge: <a​irlied> why so much more crashy?
01:29 fdobridge: <g​fxstrand> Maxwell? No `vkCmdCopyQueryPoolResults()`
01:31 fdobridge: <g​fxstrand> I've already got a pretty good blocklist which cuts down the crashing a lot but I couldn't get them all
01:31 fdobridge: <g​fxstrand> On Turing, specifically.
01:32 fdobridge: <a​irlied> ah yes cmd copy
01:34 fdobridge: <g​fxstrand> Oh, look! `*null_descriptor*` is in my Maxwell blocklist. 🙃
02:07 fdobridge: <g​fxstrand> `Pass: 380616, Fail: 1944, Crash: 16, Skip: 1750664, Flake: 130, Duration: 38:57`
02:16 fdobridge: <g​fxstrand> Looks like I can turn those back on. Yay!
02:17 fdobridge: <g​fxstrand> Now the only things left in the blocklist are the allocation max tests which just suck for multi-threaded test runs and WSI which I don't really care about testing at the moment. The CTS tests for it basically don't do anything interesting.
02:30 fdobridge: <g​fxstrand> Reminder to myself: Flip the meson option to use the new kernel API around so it uses the new API by default.
02:38 tertl8: i recently saw the Phronix article about nvk being merged in 6.6
02:39 tertl8: however, Im a bit confused how this relates to the established nouveau driver
02:40 airlied: nvk isn't a kernel driver
02:40 airlied: and isn't going into the 6.6 kernel
02:41 airlied: nouveau support for the nvk userspace is planned to be added for6.6
03:30 tertl8: thank you airlied
05:45 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I see `push_dump` option twice (also I'm able to run NVK on Linux 6.4)
05:50 fdobridge: <g​fxstrand> Yeah, we're going to be dropping pre-6.6 support before too long. It'll probably live on for a few months behind a configure flag but it'll get ripped out soon enough.
05:51 fdobridge: <g​fxstrand> Oops. That second one should be `push_sync`
06:35 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Why does #Nouveau-vk still exist despite #Nouveau having all the NVK discussion?
07:28 fdobridge: <k​arolherbst🐧🦀> what fixed it again? I think there was something, but what was it specifically? 😄
07:29 fdobridge: <k​arolherbst🐧🦀> legacy reasons
07:30 fdobridge: <k​arolherbst🐧🦀> I changed the channel topic
07:32 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> So was that channel active back in 2022?
07:57 fdobridge: <k​arolherbst🐧🦀> yeah, it kinda was
08:07 fdobridge: <g​fxstrand> Probably helpers
08:07 fdobridge: <k​arolherbst🐧🦀> nah, there was a crash in the texture unit
08:08 fdobridge: <k​arolherbst🐧🦀> or something
08:09 fdobridge: <k​arolherbst🐧🦀> wait.. I'll get the test hitting it
08:10 fdobridge: <k​arolherbst🐧🦀> @gfxstrand `dEQP-VK.robustness.robustness2.push.notemplate.rgba32i.dontunroll.volatile.storage_image.fmt_qual.null_descriptor.samples_1.1d.comp`
08:11 fdobridge: <k​arolherbst🐧🦀> but maybe that works now? I was sure to run that on top of the helper invoc fix
20:44 fdobridge: <g​fxstrand> Passes on Turing
20:44 fdobridge: <k​arolherbst🐧🦀> yeah, but not on pascal
20:44 fdobridge: <k​arolherbst🐧🦀> at least the last time I've tried
20:45 fdobridge: <g​fxstrand> IDK. I don't think I have a Pascal card.
20:45 fdobridge: <k​arolherbst🐧🦀> should also fail on anything before that
20:45 fdobridge: <g​fxstrand> Fails on Maxwell
20:46 fdobridge: <g​fxstrand> I get a write fault
20:46 fdobridge: <k​arolherbst🐧🦀> yep
20:47 fdobridge: <k​arolherbst🐧🦀> my theory is, that if the fetched descriptor from the tic table is null it causes a write/read fault, but not quite sure...
20:48 fdobridge: <k​arolherbst🐧🦀> though in theory you can configure those operations to return 0/do nothing on OOB read/writes, just didn't had a chance to actually look what's wrong there
20:50 fdobridge: <g​fxstrand> I think zero isn't a valid NULL with TIC1 but it is with TIC2
20:51 fdobridge: <g​fxstrand> Hrm... Pascal still uses TIC2
20:58 fdobridge: <g​fxstrand> `COMPONENTS_SIZES_INVALID` was added on Volta....
21:00 fdobridge: <g​fxstrand> I bet that's what it keys off of.
21:00 fdobridge: <g​fxstrand> Let's see if I can fake something on older hardware
21:07 fdobridge: <k​arolherbst🐧🦀> @gfxstrand in theory you might be able to bind a 0x0 sized image and let the hardware deal with it as an OOB access
21:07 fdobridge: <k​arolherbst🐧🦀> in theory
21:12 fdobridge: <g​fxstrand> You can't do 0x0 with TIC2
21:13 fdobridge: <g​fxstrand> All the sizes are minus 1
21:13 fdobridge: <k​arolherbst🐧🦀> .... annoying
21:14 fdobridge: <g​fxstrand> If we take advantage of the fact that 0 is our reserved null descriptor, we can predicate everything by tex != 0
21:15 fdobridge: <g​fxstrand> I'm also playing with other things we can stick in the descriptor to make it behave as null
21:15 fdobridge: <g​fxstrand> Like min_lod > max_lod
21:17 fdobridge: <k​arolherbst🐧🦀> soo.. one thing you could do is to predicate the surfare operations with a check against 0. Codegen will insert a 0 in the other case
21:19 fdobridge: <k​arolherbst🐧🦀> but not sure if any of that happens with bindless ones.. probably not?
21:20 fdobridge: <k​arolherbst🐧🦀> ehh wait.. on maxwell+ we don't insert those oob checks I think
21:21 fdobridge: <k​arolherbst🐧🦀> ahh yeah... not for bindless
21:22 fdobridge: <k​arolherbst🐧🦀> yeah.. on kepler nothing bad happens
21:23 fdobridge: <k​arolherbst🐧🦀> it actually compares the handle against 0
21:23 fdobridge: <k​arolherbst🐧🦀> I think it wouldn't be terrible to do that in nir, it will add 1 instruction in the best, 2 in the worst case
21:24 fdobridge: <g​fxstrand> Maybe? It'd mean pulling it all into an if
21:24 fdobridge: <g​fxstrand> Which I guess maybe codegen will flatten?
21:24 fdobridge: <k​arolherbst🐧🦀> on kepler it's like this:
21:24 fdobridge: <k​arolherbst🐧🦀> set u8 $p1 eq u32 $r255 $r4 (8)
21:24 fdobridge: <k​arolherbst🐧🦀> not $p1 sustp 2D $r0 $s0 rgba u32 # u8 $r0d $r3 $p0 $r4q (8)
21:24 fdobridge: <g​fxstrand> for store, sure.
21:25 fdobridge: <k​arolherbst🐧🦀> for load you have a `$p1 mov ... 0`
21:25 fdobridge: <k​arolherbst🐧🦀> more if you read more components I guess
21:26 fdobridge: <k​arolherbst🐧🦀> but some of the surface operands are also 0
21:26 fdobridge: <k​arolherbst🐧🦀> just if the compiler wouldn't be so terrible 🥲
21:27 fdobridge: <k​arolherbst🐧🦀> anyway.. yeah, if we could something outside of shaders it would be great, but...