15:37 fdobridge: <j​ekstrand> Yeah, HMM design is very different from D3D12/Vulkan/OptiX. HMM is all automagic "just use memory; we'll make sure it's there" whereas D3D12/Vulkan/OptiX is very manual: we give you the tools to detect faults and upload/map memory and you handle it all.
17:14 fdobridge: <🌺​ ¿butterflies? 🌸> So: HMM requires resume on faults. This just requires a way to detect from a GPU program if a page is mapped before accessing it - and if so take an alternate path
17:14 fdobridge: <🌺​ ¿butterflies? 🌸> Without faulting support in the GPU being used...
17:17 fdobridge: <k​arolherbst🐧🦀> well, the report happens on access, but there is no interrupt/signal raised to the host
17:17 fdobridge: <k​arolherbst🐧🦀> you know inside the shader if the access was faulty or not
17:18 fdobridge: <🌺​ ¿butterflies? 🌸> You don't actually fault - no C++-style exception support on GPUs yet
17:21 fdobridge: <🌺​ ¿butterflies? 🌸> Very interesting way around limitations - instructions to detect if an access would be faulty instead of access and fault handlers...
17:27 fdobridge: <k​arolherbst🐧🦀> well.. on nvidia you have no special instruction to detect if a page is sparse. You do the load/store op and check the predicate to see if it was invalid afterwards
17:28 fdobridge: <k​arolherbst🐧🦀> I wouldn't be surprised if the mechanism is mostly the same, just that you don't pause the shader, but simply continue executing
17:28 fdobridge: <k​arolherbst🐧🦀> and that was actually always configurable
17:28 fdobridge: <k​arolherbst🐧🦀> you also had the option of catching faults inside the shader, where the SM invoked a trap handler
17:47 fdobridge: <🌺​ ¿butterflies? 🌸> Yeah that's the interesting one
18:01 fdobridge: <k​arolherbst🐧🦀> I suspect that for sparse it still traps, but with a special signal the SM handles accordingly
18:26 rmckeever: I'm trying to run the CTS tests with deqp_runner, and my system freezes 2-3 minutes into the run. I'm running Xubuntu 22.04 with a NVIDIA GeForce RTX 2060 GPU.
18:27 rmckeever: I ssh'ed in from another computer and noticed this message come up in dmesg when the freeze starts:
18:27 rmckeever: nouveau 0000:01:00.0: bus: MMIO write of 00000002 FAULT at b64000 [ TIMEOUT ]
18:28 rmckeever: Anyone have any suggestions?
18:38 karolherbst: might want to run this branch: https://gitlab.freedesktop.org/skeggsb/nouveau/-/tree/00.06-gr-ampere
18:38 karolherbst: though I think drm-next also contains those patches
18:46 fdobridge: <j​ekstrand> I think she's running that branch. 😕
18:46 fdobridge: <k​arolherbst🐧🦀> 🥲
18:48 karolherbst: btw, I hope you enjoyed your boost or something :D
18:54 rmckeever: I was running the 01.01-gsp-rm branch. I'll try the 00.06-gr-ampere branch. Thanks!
18:56 karolherbst: that should also contain the 00.06 one, but it could also have broken things, so probably a good idea to try that
19:08 fdobridge: <g​ouz> Hello! Is there any way i can get the index of an output variable in nv50_ir_prog_info_out.out[] array from a nir_variable location?
19:09 fdobridge: <k​arolherbst🐧🦀> `Converter::assignSlots` should have all the info and how those fit together
19:11 fdobridge: <g​ouz> thanks @karolherbst🐧
20:14 fdobridge: <j​ekstrand> Your boost got me over 50%.
20:14 fdobridge: <k​arolherbst🐧🦀> I think it was Lina's but yeah 😄
20:14 fdobridge: <j​ekstrand> Oh, right, lina boosted too. Yeah, that probably helped. 🙂
20:14 fdobridge: <k​arolherbst🐧🦀> she boosted it at some point
20:14 fdobridge: <k​arolherbst🐧🦀> yeah
20:15 fdobridge: <k​arolherbst🐧🦀> I'm now at 87%, soo 😄 twitter can burn down for all I care
20:27 fdobridge: <j​ekstrand> There's still a couple people I enjoy interacting with on Twitter that haven't moved over yet. 😦
20:28 fdobridge: <k​arolherbst🐧🦀> 😢 yeah...
20:28 fdobridge: <j​ekstrand> Or rather aren't posting to Mastodon
20:28 fdobridge: <k​arolherbst🐧🦀> but I personally just can't stay with a good conscience
20:57 airlied: jekstrand: you should just go all in and become a streamer :-P
20:59 karolherbst: :D
21:00 fdobridge: <p​homes> I wanted to work a bit on the conditional rendering tonight. I looked at how the other drivers do it. They all call it predicate in the implementations. Is that just a common name for this kind of thing?
21:20 fdobridge: <j​ekstrand> Fairly common, yeah.
21:20 fdobridge: <j​ekstrand> BTW, for NVK, I think we want to store the predicate in one of the scratch states so we don't have to constantly fetch it from memory.
21:21 fdobridge: <j​ekstrand> airlied: I've thought about streaming
21:25 fdobridge: <p​homes> can you give me a pointer to what I should look at to do that?
22:07 fdobridge: <j​ekstrand> In nvk_mme.h, there's an nvk_mme_scratch enum that already defines a couple. I'm using it for tracking CS invocations.
22:08 fdobridge: <j​ekstrand> If you look at nvk_cmd_dispatch.c, you can find the MMEs that I build for doing that.
22:11 fdobridge: <p​homes> perfect. Thanks. I will see if I can get something working with that