14:52fdobridge: <marysaka> Just saw that https://github.com/NVIDIA/open-gpu-doc/commit/e0f11a901955351953182156f49758650efd2ae2
14:52fdobridge: <karolherbst🐧🦀> that reminds me, I still have to write an email to get more docs
14:55fdobridge: <karolherbst🐧🦀> 1. SPH as proper C headers
14:55fdobridge: <karolherbst🐧🦀> 2. that invocation helper reg thing
14:56fdobridge: <Mohamexiety> Hm, speaking of this... this may be a really naive question but is there hope I could get proper firmware to get the 3080 running by contacting NVIDIA through their dev portal?
15:01fdobridge: <karolherbst🐧🦀> well..
15:01fdobridge: <karolherbst🐧🦀> we are talking with them about updating their firmware
15:01fdobridge: <karolherbst🐧🦀> but it's not sure if that's your issue
15:02fdobridge: <karolherbst🐧🦀> tried using the GSP stuff? @airlied and/or others might be able to help out with getting it set up
15:03fdobridge: <marysaka> Would be nice to put some doc up somewhere for it I guess to refer to it when needed :aki_thonk:
15:05fdobridge: <Mohamexiety> Yeah it's not really ready for use yet from what I understood so I'll wait for a bit then
15:05fdobridge: <karolherbst🐧🦀> well.. the idea is, that everybody gets it sooner or later anyway
15:05fdobridge: <karolherbst🐧🦀> yeah.. the displaying bits are a but broken, but if you only use the nvidia GPU as a secondary device and drive your desktop with Intel it should be fine
15:05fdobridge: <karolherbst🐧🦀> officially Nvidia already supports using GSP in data center use cases
15:06fdobridge: <karolherbst🐧🦀> so for that it's totally fine
15:15fdobridge: <karolherbst🐧🦀> aaaaaand.. sent
15:15fdobridge: <karolherbst🐧🦀> hopefully we'll get something soon
19:46fdobridge: <airlied> getting gsp and nvk to work together is still a bit up in the air, we have to get that register lists working
19:53fdobridge: <karolherbst🐧🦀> mhhh, right...
19:54fdobridge: <airlied> skeggsb seems to think we should have access to it via our non-gsp fw as well
19:54fdobridge: <airlied> so we could probably look at what nvgpu does for pre-gsp
19:54fdobridge: <karolherbst🐧🦀> yeah
19:54fdobridge: <airlied> then work out how to program MME to do it
19:54fdobridge: <karolherbst🐧🦀> I wouldn't be surprised if it's the same
19:55fdobridge: <Mohamexiety> anyways if there's anything I could do / test on ampere/GA102 I am available
19:56fdobridge: <karolherbst🐧🦀> @airlied did you check if the open source driver has that stuff wired up?
19:56fdobridge: <karolherbst🐧🦀> I didn't yet
19:56fdobridge: <airlied> nvgpu or openrm?
19:58fdobridge: <karolherbst🐧🦀> openrm
19:58fdobridge: <karolherbst🐧🦀> the MME part is the easy part
19:58fdobridge: <karolherbst🐧🦀> the MME part is the easy part anyway here (edited)
20:06fdobridge: <airlied> it should be but I don't see it, like I can see the priv map stuff, but no register lists
20:06fdobridge: <Esdras Tarsis> I thought nvgpu is only for tegra
20:07fdobridge: <J., Echo (she) 🇱🇹> I wan byg FPZ in mai clasic Nid fur Spid geim tho 😈
20:08fdobridge: <J., Echo (she) 🇱🇹> But seriously I should really test NVK with a Need for Speed game to see how well it runs right now 🐸
20:26fdobridge: <karolherbst🐧🦀> mhhh...
20:26fdobridge: <karolherbst🐧🦀> interesting
20:27fdobridge: <karolherbst🐧🦀> maybe the buffer gets filled by gsp now or something
20:55fdobridge: <airlied> that would make some sense I think
20:55fdobridge: <J., Echo (she) 🇱🇹> Maybe there should be an emote for GSP 🐸
20:55fdobridge: <airlied> if that's the case then if someone can write the MME patch I could test it
22:39fdobridge: <karolherbst🐧🦀> soo.. the current theory is, the host allocates that buffer and hands that over to GSP and GSP does things? At least looking at it from openrm?
22:39fdobridge: <karolherbst🐧🦀> @gfxstrand do you still have that macro dump somewhere?
22:40fdobridge: <gfxstrand> Yeah, somewhere.
22:40fdobridge: <gfxstrand> https://people.freedesktop.org/~gfxstrand/macros.txt
22:41fdobridge: <karolherbst🐧🦀> ehh... we talked about it here It hink...
22:41fdobridge: <karolherbst🐧🦀> let's search for it
22:41fdobridge: <gfxstrand> They may not be the most recent or have all of them. It's hard to parse the dumps since I'm literally dumping several GB of mapped memory and searching for macro commands. 😅
22:42fdobridge: <karolherbst🐧🦀> or was that on IRC?
22:42fdobridge: <gfxstrand> Link above
22:42fdobridge: <karolherbst🐧🦀> yeah, but I mean.. we talked about it and I pointed out which is the correct macro for it
22:42fdobridge: <gfxstrand> Yeah, that would have been IRC.
22:42fdobridge: <karolherbst🐧🦀> it's a generic one where you pass in the reg + value + mask
22:42fdobridge: <gfxstrand> I've got logs but I'm on my phone right now
22:43fdobridge: <karolherbst🐧🦀> ehh wait. I tihnk I now what to search for
22:45fdobridge: <karolherbst🐧🦀> nah.. let me check my logs 😄
22:45fdobridge: <marysaka> Is this related to ``SET_FALCON04``?
22:45fdobridge: <karolherbst🐧🦀> ahh yeah,t hat was it
22:45fdobridge: <marysaka> that's something that exist on Maxwell and co too
22:45fdobridge: <karolherbst🐧🦀> I think..
22:46fdobridge: <marysaka> I really need to setup something to dump command buffers again...
22:49fdobridge: <karolherbst🐧🦀> it's mme 33
22:50fdobridge: <karolherbst🐧🦀> reg/value/mask
22:50fdobridge: <karolherbst🐧🦀> are the inputs
22:51fdobridge: <karolherbst🐧🦀> so NVC597_SET_FALCON04 is the trigger I think
22:51fdobridge: <karolherbst🐧🦀> ehh.. wait
22:56fdobridge: <marysaka> well if it's the same as for Maxwell, the macro will loop until ``SET_MME_SHADOW_SCRATCH(0) == 1``
22:57fdobridge: <karolherbst🐧🦀> ohhr ight, I think the two last args are provided as data thing
23:00fdobridge: <marysaka> huh that macro is weird
23:01fdobridge: <marysaka> Are the arguments truely inlined in it?
23:05fdobridge: <marysaka> On Nintendo Switch (OpenGL/VK driver), I already saw a macro that does the same and takes address, value and some mask.
23:05fdobridge: <marysaka>
23:05fdobridge: <marysaka> At init it would do the following calls
23:05fdobridge: <marysaka> ```c
23:05fdobridge: <marysaka> macro(0x00418800, 0x1, 0x1);
23:05fdobridge: <marysaka> macro(0x00419A08, 0x0, 0x10);
23:05fdobridge: <marysaka> macro(0x00419F78, 0x0, 0x8);
23:05fdobridge: <marysaka> macro(0x00404468, 0x7FFFFFF, 0x3FFFFFFF);
23:05fdobridge: <marysaka> macro(0x00419A04, 0x1, 0x1);
23:05fdobridge: <marysaka> macro(0x00419A04, 0x2, 0x2);
23:05fdobridge: <marysaka> ```
23:05fdobridge: <marysaka> the macro in the dump have that same 0x418800 inlined
23:05fdobridge: <airlied> that looks like the sort of thing I'd want
23:17fdobridge: <marysaka> Just did a quick redump from Switch instead of relying on my old notes: https://gist.github.com/marysaka/82f1dfba4f4be1b0a432d49863844b61
23:19fdobridge: <karolherbst🐧🦀> probably the offset
23:20fdobridge: <karolherbst🐧🦀> so each bit in the data buffer respresents one reg
23:20fdobridge: <karolherbst🐧🦀> and I guess in order to save memory, they just offset it
23:20fdobridge: <karolherbst🐧🦀> wouldn't be surprsied if nvgpu contains that value as well
23:21fdobridge: <marysaka> I remember looking up nvgpu a bit, one was documented from the top of my memory
23:23fdobridge: <marysaka> actually no it's not matching...
23:24fdobridge: <marysaka> https://github.com/fpb4/android_kernel_nvidia_shieldtablet/blob/b24d07ff0a0e8a7dec37051736c77d93b4d1403b/drivers/gpu/nvgpu/gm20b/hw_gr_gm20b.h
23:24fdobridge: <karolherbst🐧🦀> I hope they don't change the base every version
23:30fdobridge: <🌺 ¿butterflies? 🌸> Reminder that everything firmware ABI wise is currently defined as unstable
23:31fdobridge: <marysaka> I had a sense of deja vu!
23:31fdobridge: <marysaka> Just searched (yet again) for what I was refering to and https://github.com/muxable/nvidia-jetson-linux/blob/899dcfb124e766aca051304b9275b44d5fdfcc02/sources/kernel/nvgpu/drivers/gpu/nvgpu/gm20b/regops_gm20b.c
23:32fdobridge: <marysaka> this could be similar stuffs but I haven't poked much more (those are for regops stuffs for nvgpu debug stuffs)
23:34fdobridge: <marysaka> oh yeah 0x00418e40 is listed on one of those tables