00:00Lyude: wooo
00:01Lyude: basic outp inheritance through nvif working :)
00:01Lyude: for tmds at least, the rest is super easy to do though now that i know everything that nees to happen
00:01Lyude: ^ skeggsb :)
00:02Lyude: what I did was just introduce an INHERIT command, which is basically "acquire this outp for the user, but only if it's already hooked up and active"
00:02Lyude: also definitely have a much better idea of how all nvif/nvkm hooks up display wise I think
03:06fdobridge: <gfxstrand> Oh, there's a reproducer now. Should be easy enough to sort out.
03:06fdobridge: <gfxstrand> I should probably do that before it bites rbmckeever.
12:11fdobridge: <karolherbst🐧🦀> okay, seems like at least the way of binding that buffer doesn't change..
13:01fdobridge: <karolherbst🐧🦀> https://github.com/NVIDIA/open-gpu-doc/blob/master/manuals/volta/gv100/dev_ctxsw.ref.txt#L105 mhhh
13:02fdobridge: <karolherbst🐧🦀> `#define NV_CTXSW_MAIN_IMAGE_PRIV_ACCESS_MAP_CONFIG_MODE_ALLOW_ALL 0x00000000` mhhhh
13:02fdobridge: <karolherbst🐧🦀> _maybe_ I can prototype the MME stuff with that
13:02fdobridge: <karolherbst🐧🦀> if that flag actually allows full access
13:03fdobridge: <karolherbst🐧🦀> `#define NV_CTXSW_MAIN_IMAGE_PRIV_ACCESS_MAP_CONFIG_MODE_USE_MAP 0x00000002` probably means to use the buffer
13:03fdobridge: <karolherbst🐧🦀> yeah, that would make things easy to implement
13:07fdobridge: <karolherbst🐧🦀> but at least this part is stable across generations, so that's really good
13:18fdobridge: <karolherbst🐧🦀> for future reference, `gf100_grctx_generate` is the function to create a context (and where we could also enable helper invoc for all gens)
13:18fdobridge: <karolherbst🐧🦀> didn't try it yet, but I'm highly confident we could just do it there
13:19fdobridge: <karolherbst🐧🦀> not sure if that would work with gsp though
13:23fdobridge: <marysaka> Would be nice to give all those magical values in ctxgv100 and co some names now I suppose :aki_thonk:
13:24fdobridge: <marysaka> (I got lost in dev_graphics.ref.txt a bit ^^')
13:34fdobridge: <karolherbst🐧🦀> yeah...
13:36fdobridge: <karolherbst🐧🦀> though we can't use that file as is, because it's not a valid C header file 🥲
13:38fdobridge: <marysaka> yeah and the ranges definition are annoying...
13:41fdobridge: <karolherbst🐧🦀> we do have evil macro magic for this tho
13:43fdobridge: <marysaka> wait a sec
13:43fdobridge: <marysaka> https://github.com/LineageOS/android_kernel_nvidia_nvgpu/blob/52003423a8ecf0b4f6252e0d92b75c50104356ac/drivers/gpu/nvgpu/hal/gr/init/gr_init_gv11b.c#L59
13:43fdobridge: <marysaka> they give names here :Thinkeyes:
13:43fdobridge: <marysaka> and those matches a lot of what I dumped
13:45fdobridge: <karolherbst🐧🦀> yeah
13:45fdobridge: <karolherbst🐧🦀> it's all known what those fields are (more or less)
13:46fdobridge: <karolherbst🐧🦀> `0x419ea8, /* gr_pri_gpcs_tpcs_sms_hww_warp_esr_report_mask */` heh
13:46fdobridge: <marysaka> ah I see I wasn't aware of that ^^'
13:46fdobridge: <karolherbst🐧🦀> yeah.. it's just.. hidden
13:46fdobridge: <marysaka> they also have stuffs for ampere in here it seems
13:46fdobridge: <karolherbst🐧🦀> e.g. grep for `gr_gpcs_tpcs_sms_hww_warp_esr_report_mask_r`
13:46fdobridge: <marysaka> I haven't looked "recent" nvgpu stuffs for years so yeah
13:47fdobridge: <karolherbst🐧🦀> or maybe it's different in your version there
13:47fdobridge: <🌺 ¿butterflies? 🌸> look at the linux-nvgpu.git upstream tegra repo
13:47fdobridge: <karolherbst🐧🦀> `drivers/gpu/nvgpu/include/nvgpu/hw/gv11b/hw_gr_gv11b.h`
13:47fdobridge: <karolherbst🐧🦀> anyway
13:47fdobridge: <🌺 ¿butterflies? 🌸> has ga102 support
13:47fdobridge: <karolherbst🐧🦀> `gr_pri_gpcs_tpcs_sms_hww_warp_esr_report_mask` is needed to enable the shader trap handler
13:47fdobridge: <karolherbst🐧🦀> `gr_pri_gpcs_tpcs_sms_dbgr_control0` might also be relevant
13:48fdobridge: <karolherbst🐧🦀> no wonder I never seen nvidia enabling it via mmiotraces
13:48fdobridge: <karolherbst🐧🦀> they do that in firmware via the priv_access_map stuff
13:48fdobridge: <🌺 ¿butterflies? 🌸> https://nv-tegra.nvidia.com/r/plugins/gitiles/linux-nvgpu
13:49fdobridge: <🌺 ¿butterflies? 🌸> ```gpu: nvgpu: move gv11b code under config flag
13:49fdobridge: <🌺 ¿butterflies? 🌸>
13:49fdobridge: <🌺 ¿butterflies? 🌸> Move gv11b specific code under CONFIG_NVGPU_GV11B_SUPPORT so that gv11b
13:49fdobridge: <🌺 ¿butterflies? 🌸> support can be removed for qnx later as it is no longer POR for qnx on
13:49fdobridge: <🌺 ¿butterflies? 🌸> dev-main.
13:49fdobridge: <🌺 ¿butterflies? 🌸>
13:49fdobridge: <🌺 ¿butterflies? 🌸> Jira NVGPU-8189
13:49fdobridge: <🌺 ¿butterflies? 🌸> Bug 3642168
13:49fdobridge: <🌺 ¿butterflies? 🌸> ``` RIP old soldier
13:49fdobridge: <karolherbst🐧🦀> heh
13:51fdobridge: <🌺 ¿butterflies? 🌸> the very neat thing with nvgpu is having mostly complete commit history
13:51fdobridge: <marysaka> I guess I will have to dig nvgpu repo later... could be worth scrapping all those values once and for all?
14:41fdobridge: <karolherbst🐧🦀> maybe, maybe not. Kind of depends if there is anything in there we don't know yet. If so, we also should just ask nvidia to release docs on it
14:41fdobridge: <karolherbst🐧🦀> releasing docs is way easier if the information is already out in the public
14:42fdobridge: <marysaka> right, that is probably a better strategy
14:56fdobridge: <karolherbst🐧🦀> @gfxstrand @airlied https://gitlab.freedesktop.org/drm/nouveau/-/commit/99401da29004b777d6999bf78206f989423e3985
14:56fdobridge: <karolherbst🐧🦀> not sw subchan witchery needed anymore
14:57fdobridge: <karolherbst🐧🦀> I didn't check out how GSP changes things there and I don't know if we can still poke those registers from the host side (and if we do this thing at all)
14:57fdobridge: <karolherbst🐧🦀> if all of this will change I can dig into the MME part so we do it properly
14:57fdobridge: <karolherbst🐧🦀> but for testing this is good enough
14:57fdobridge: <karolherbst🐧🦀> and also has the benefit of fixing userspace without having to patch mesa
14:58fdobridge: <karolherbst🐧🦀> if this approach works also with GSP I'm inclined to clean it up and send it out. If it doesn't work with GSP, then we have to go the MME path
15:03fdobridge: <marysaka> nice! kind of related, last night I rewrote the MME macro for FALCON04 to do some testing so if you want I can send you mine ^^
15:04fdobridge: <marysaka> Also I don't know if it's known buut if you cause an infinite loop in some MME macro, it doesn't recover :nya_panic:
15:04fdobridge: <marysaka> (had to force reboot)
15:35fdobridge: <karolherbst🐧🦀> uhh
15:35fdobridge: <karolherbst🐧🦀> normally the context gets nuked by the kernel, no?
15:35fdobridge: <karolherbst🐧🦀> but userspace might behave weirdly
15:57fdobridge: <gfxstrand> Woo! I like 4-line patches. 😄
15:57fdobridge: <gfxstrand> Yeah, I've seen some nasty hangs from MME.
16:05fdobridge: <karolherbst🐧🦀> if MME is able to hang we should figure out if our recovery code is broken and fix that
16:07fdobridge: <gfxstrand> Yeah, we should
18:44fdobridge: <karolherbst🐧🦀> sadly, if cleaned up it will turn into a ... 20 line patch 🥲
18:45fdobridge: <karolherbst🐧🦀> but let's see what @airlied is saying, because I didn't look into how GSP is wired up at all and if we can still do any of this
19:29fdobridge: <airlied> yeah I don't think that will fly with gsprm unfortunately
19:30fdobridge: <airlied> I can poke around a bit today to see there is any point we can see those regs, but I suspect not
19:30fdobridge: <karolherbst🐧🦀> yeah.. that would be helpful
19:31fdobridge: <karolherbst🐧🦀> I'm not really looking forward in implementing the same logic for archs older than 2nd gen maxwell
19:31fdobridge: <karolherbst🐧🦀> but there we could just do it in the kernel
19:31fdobridge: <karolherbst🐧🦀> at least we only need this for kepler+ afaik
20:21fdobridge: <J., Echo (she) 🇱🇹> 1-line patches are even better 😈
20:24fdobridge: <karolherbst🐧🦀> -1000 line patches are even better
21:50fdobridge: <gfxstrand> https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/191
22:20fdobridge: <karolherbst🐧🦀> seems like my fancy patch doesn't work with GSP indeed 🙃
22:21fdobridge: <karolherbst🐧🦀> hopefully I'll figure it out all by next week then
22:21fdobridge: <karolherbst🐧🦀> but so far I think I'd advise to rely on the new patch and remove the sw subchan stuff from nvk
22:21fdobridge: <karolherbst🐧🦀> because that's going to go away one way or the ohter
22:22fdobridge: <karolherbst🐧🦀> Ben acked the approach of doing it for non nvidia fw devices, so the only case where Userspace will have to do something would be 2nd gen Maxwell+ or GSP driven GPUs
23:09fdobridge: <airlied> @phomes probably for you to validate the turing while fix
23:23fdobridge: <phomes> It fixes the problem I had 🙂
23:56fdobridge: <gfxstrand> Yeah, I tested it with @phomes' patch.