00:41 fdobridge_: <a​irlied> @zmike. what does zink do with sparse residency?
01:07 fdobridge_: <z​mike.> https://i.imgur.com/tJaBJjl.mp4
01:07 fdobridge_: <a​irlied> sparse residency is now fixed 😛
01:13 fdobridge_: <z​mike.> Do clipping next
01:14 fdobridge_: <z​mike.> :galaxybrain:
01:16 Lyude: AHAHAHAHAHA YES
01:16 Lyude: [ 26.788818] rvkms: Now playing: RVKMS by Lyude
01:16 Lyude: [ 26.789297] [drm] Initialized rvkms 0.0.0 20240115 for vgem on minor 1
01:16 Lyude: (i forgot to change the name of the driver oop)
01:17 Sid127:observes
01:22 airlied: Lyude: nice
01:26 fdobridge_: <a​irlied> one does not simply march into clipping
01:31 fdobridge_: <z​mike.> No, you can't wait till March to fix it, that's too far off
01:58 fdobridge_: <a​irlied> @gfxstrand https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27407 I'm sure you have a better idea :0
02:03 fdobridge_: <a​irlied> @gfxstrand do you have a plan to do bounds checking on scratch loads?
02:04 fdobridge_: <a​irlied> there's a piglit test that creates an array, and loads an index from a ubo outside the array, and it triggers a ctx crash
02:04 fdobridge_: <g​fxstrand> Yeah...
02:04 fdobridge_: <g​fxstrand> There was a Vulkan CTS test that did that. I told them to delete it. 😝
02:05 fdobridge_: <a​irlied> tests/spec/glsl-1.20/execution/array_bounds/glsl-array-bounds-13.shader_test
02:07 fdobridge_: <g​fxstrand> We probably should add something for debug purposes if nothing else. Without pulling up that test (I'm on my phone), IDK if it's valid or not.
02:07 fdobridge_: <g​fxstrand> Nvidia killing your context for going OOB is pretty mean, though.
02:39 fdobridge_: <k​arolherbst🐧🦀> it's global memory tho
02:39 fdobridge_: <k​arolherbst🐧🦀> but
02:40 fdobridge_: <k​arolherbst🐧🦀> it's not the hardware doing it
02:40 fdobridge_: <k​arolherbst🐧🦀> it's all configurable
02:40 fdobridge_: <k​arolherbst🐧🦀> we just don't know how
02:41 fdobridge_: <k​arolherbst🐧🦀> btw.. `LDG` got a `.PRIVATE` flag for operation not perceived by any other threads
02:41 fdobridge_: <k​arolherbst🐧🦀> though I guess in `LDL` that's implicit
02:52 fdobridge_: <m​henning> Do you know if LDG.PRIVATE is appropriate for private operations in the vulkan memory model sense?
02:52 fdobridge_: <k​arolherbst🐧🦀> I have no idea 🙂
02:52 fdobridge_: <m​henning> I found the instruction encoding for .PRIVATE a while ago, but I don't exactly understand how that changes hardware behavior so I didn't want to set it anywhere
02:53 fdobridge_: <k​arolherbst🐧🦀> it relates to the scope of the operation
02:53 fdobridge_: <k​arolherbst🐧🦀> so you can make it PRIVATE to the CTA and stuff
02:53 fdobridge_: <k​arolherbst🐧🦀> though I think it's just a weird caching opt
02:57 fdobridge_: <k​arolherbst🐧🦀> ~~could also create a new one and just move on :ferrisUpsideDown: ~~
02:57 fdobridge_: <k​arolherbst🐧🦀> the VM is entirely independent from the context, sooo...
02:58 fdobridge_: <k​arolherbst🐧🦀> though recovering from that in a game crashing the context every 2 seconds is kinda funky 😄
03:19 fdobridge_: <g​fxstrand> I mean yes it lives in memory but the hardware does tightly bounds check.
03:19 fdobridge_: <g​fxstrand> And it kills your context if you ever go OOB, which is kinda mean.
03:19 fdobridge_: <g​fxstrand> It could discard/write zero
03:20 fdobridge_: <g​fxstrand> But nooooo....
11:39 fdobridge_: <k​arolherbst🐧🦀> I _think_ this can be configured. There are MMIO registers which define who is handling what error. I know that such faults can be redirected to trap handlers. I don't know if we can also make the hardware ignore certain faults here
11:39 fdobridge_: <k​arolherbst🐧🦀> but I think with local memory we are out of luck as this is just a generic memory fault
13:35 karolherbst: Lyude: btw, did you finish this patch to verify userspace modelines?
18:57 fdobridge_: <g​fxstrand> @airlied dakr: Trying to help @mohamexiety with sparse and I'm hitting `-ENOSPC` when `VM_BIND_SPARSE` is set.
18:58 fdobridge_: <g​fxstrand> Hrm... No, that was me being dumb.
19:48 fdobridge_: <a​irlied> @gfxstrand got a complete run with shards on 64-bit (once I reverted the new KHR ext enablement patches)
19:57 fdobridge_: <a​irlied> it's been a long time since I've done 32-bit builds, let me see if I can work it out
20:02 fdobridge_: <a​irlied> @gfxstrand does rust need some incantation in the cross file or special install?
20:06 fdobridge_: <g​fxstrand> Yeah, you need rust stuff in the cross file
20:35 fdobridge_: <a​irlied> drop me yours whenever you have a chance, I'm failing to find it quickly
21:19 fdobridge_: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1202724855112278046/x86.cross?ex=65ce7fcf&is=65bc0acf&hm=b41c688e510339f0b4f4f336058b60884262f53a51de164ca53e6c76187bd054&
21:59 fdobridge_: <a​irlied> okay, got a bit further, now have some crate snark about compiled with wrong target, will dig in later
23:47 Lyude: does rust-analyzer actually display all of the compile errors for everyone else?
23:47 Lyude: oh sorry - in the linux kernel I mean
23:48 Lyude: It seems like completion works just fine but I keep finding compile errors that don't appear until I run mae
23:48 Lyude: *make