00:23fdobridge: <gfxstrand> Merged!
00:34fdobridge: <airlied> yay hopefully we can unblock cond render now
14:56fdobridge: <karolherbst🐧🦀> so let's get this MME magic figured out
15:27fdobridge: <karolherbst🐧🦀> interesting
15:27fdobridge: <karolherbst🐧🦀> so I got something to write into `NVC597_SET_MME_SHADOW_SCRATCH(0)` :3
15:27fdobridge: <karolherbst🐧🦀> and it's not me
15:28fdobridge: <karolherbst🐧🦀> and it's indeed a delayed write
15:29fdobridge: <karolherbst🐧🦀> ```
15:29fdobridge: <karolherbst🐧🦀> TEST_F(mme_tu104_sim_test, gr_test)
15:29fdobridge: <karolherbst🐧🦀> {
15:29fdobridge: <karolherbst🐧🦀> static const uint32_t chunk_size = 32;
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> mme_builder b;
15:29fdobridge: <karolherbst🐧🦀> mme_builder_init(&b, devinfo);
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> mme_value load0 = mme_load(&b);
15:29fdobridge: <karolherbst🐧🦀> mme_mthd(&b, NVC597_WAIT_FOR_IDLE);
15:29fdobridge: <karolherbst🐧🦀> mme_emit(&b, mme_zero());
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> mme_mthd(&b, NVC597_SET_MME_SHADOW_SCRATCH(0));
15:29fdobridge: <karolherbst🐧🦀> mme_emit(&b, mme_zero());
15:29fdobridge: <karolherbst🐧🦀> mme_emit(&b, mme_zero());
15:29fdobridge: <karolherbst🐧🦀> mme_emit(&b, mme_zero());
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> mme_mthd(&b, NVC597_SET_FALCON09);
15:29fdobridge: <karolherbst🐧🦀> mme_emit(&b, load0);
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> mme_loop(&b, mme_imm(100)) {
15:29fdobridge: <karolherbst🐧🦀> mme_value r0 = mme_state(&b, NVC597_SET_MME_SHADOW_SCRATCH(26));
15:29fdobridge: <karolherbst🐧🦀> mme_value m1 = mme_merge(&b, mme_zero(), r0, 0, 8, 0);
15:29fdobridge: <karolherbst🐧🦀> mme_store_imm_addr(&b, data_addr + 0, m1);
15:29fdobridge: <karolherbst🐧🦀> }
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> mme_value r0 = mme_state(&b, NVC597_SET_MME_SHADOW_SCRATCH(0));
15:29fdobridge: <karolherbst🐧🦀> mme_store_imm_addr(&b, data_addr + 4, r0);
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> auto macro = mme_builder_finish_vec(&b);
15:29fdobridge: <karolherbst🐧🦀>
15:29fdobridge: <karolherbst🐧🦀> but only if the loop runs long enough
15:29fdobridge: <karolherbst🐧🦀> so the firmware is doing _something_
15:29fdobridge: <marysaka> I think the original MME macro wait for ``NVC597_SET_MME_SHADOW_SCRATCH(0)`` to be 1 with some write to method NOP
15:30fdobridge: <karolherbst🐧🦀> currently trying to figure out mme 34, because I suspect it's the read from priv reg function
15:30fdobridge: <karolherbst🐧🦀> contrary to mme 33 being the setter
15:30fdobridge: <marysaka> fun fact the FALCON04 write the value you send (or written?) to ``NVC597_SET_MME_SHADOW_SCRATCH(2)``
15:31fdobridge: <karolherbst🐧🦀> heh
15:31fdobridge: <marysaka> so maybe they do the same for FALCON09?
15:31fdobridge: <karolherbst🐧🦀> not sure
15:31fdobridge: <karolherbst🐧🦀> I mean..
15:31fdobridge: <karolherbst🐧🦀> they do write it anyway
15:32fdobridge: <karolherbst🐧🦀> ```
15:32fdobridge: <karolherbst🐧🦀> mthd(0x3400, 1) /* NVC597_SET_MME_SHADOW_SCRATCH(0) */)
15:32fdobridge: <karolherbst🐧🦀> emit(0x0)
15:32fdobridge: <karolherbst🐧🦀> emit($load0)
15:32fdobridge: <karolherbst🐧🦀> ```
15:32fdobridge: <karolherbst🐧🦀>
15:32fdobridge: <karolherbst🐧🦀> so it should be in `NVC597_SET_MME_SHADOW_SCRATCH(1)`
15:33fdobridge: <karolherbst🐧🦀> but lemme give it access to all registers and see if I can actually read the mmio space out
16:01fdobridge: <karolherbst🐧🦀> it's weird..
16:01fdobridge: <karolherbst🐧🦀> FALCON09 kind of fills the entire scratch space with 1
16:02fdobridge: <karolherbst🐧🦀> @gfxstrand also.. I think your parsed mme stuff is broken a bit? dunno..
16:05fdobridge: <karolherbst🐧🦀> also what is this `JAL (0x8003)` part all about.. mhh
16:12fdobridge: <gfxstrand> That's entirely possible. I think it's a little unlikely but possible.
16:13fdobridge: <gfxstrand> As long as we're only using FALCON commands on context init, that's fine. We're using scratch registers some today for CS queries and we're likely to use them for other state going forward. That can all be trash on init. We just can't be trashing it mid-client-command-buffer
16:20fdobridge: <karolherbst🐧🦀> any good doc on how `BEQ` works?
16:20fdobridge: <karolherbst🐧🦀> and well.. `JAL` as well
16:37fdobridge: <karolherbst🐧🦀> ohh wait.. figured out `BEQ`
16:44fdobridge: <gfxstrand> Yeah, those are weird.
16:44fdobridge: <gfxstrand> If you figure out more than I have, please write tests and fix the simulator.
16:44fdobridge: <gfxstrand> I wasn't able to get them figured out 100%. I got enough to make basic control-flow work and moved on.
16:44fdobridge: <karolherbst🐧🦀> mhhh
16:44fdobridge: <karolherbst🐧🦀> the annoying thing is, I have no idea what the nvidia stuff is doing
16:45fdobridge: <karolherbst🐧🦀> also.. what's `JAL (0x8003)`...
16:46fdobridge: <karolherbst🐧🦀> just a jump three instructions forward as it seems
16:46fdobridge: <karolherbst🐧🦀> maybe I just copy nvidias macro and see how well it works in GL...
16:58fdobridge: <karolherbst🐧🦀> well.. doesn't work
16:58fdobridge: <karolherbst🐧🦀> I think I have to try that out with GSP running
16:59fdobridge: <karolherbst🐧🦀> I even added a garbage buffer address and nothing bad happens.. maybe I should again set the allow all and see if it works now...
16:59fdobridge: <karolherbst🐧🦀> but I suspect our firmware doesn't have it
17:06fdobridge: <karolherbst🐧🦀> and I think I also know why...
17:07fdobridge: <karolherbst🐧🦀> uhhh
17:19fdobridge: <gfxstrand> There's some control bits in the top. I don't know what they all do.
17:20fdobridge: <karolherbst🐧🦀> right..
17:20fdobridge: <karolherbst🐧🦀> but I mean.. I took nvidia's macro as it is (like the binary) and well.. that didn't do a thing either
17:21fdobridge: <karolherbst🐧🦀> I think the firmware has this feature disabled
17:21fdobridge: <karolherbst🐧🦀> anyway, I think I understand completely now what the macro is doing
17:30fdobridge: <gfxstrand> Cool
17:30fdobridge: <gfxstrand> I'm okay with needing separate code-paths for GSP vs. not, as long as we have it all sorted pre-merge and don't have any backwards compat issues.
17:32fdobridge: <karolherbst🐧🦀> yep
17:32fdobridge: <karolherbst🐧🦀> pre GSP we'll just do it on the kernel side
17:32fdobridge: <karolherbst🐧🦀> and then the device info UAPI should be updated to indicate if GSP is used or not
17:38fdobridge: <karolherbst🐧🦀> anyway, now I have to boot the GSP stuff. Where is the latest branch for that and which gsp binary do I have to use here?
20:33fdobridge: <airlied> https://gitlab.freedesktop.org/skeggsb/nouveau/-/tree/01.02-gsp-rm was it I think, then you have to do lot of dancing, 525.89.02
20:34fdobridge: <airlied> run scripts/extract-openrm-firmware.sh from that repo
20:35fdobridge: <airlied> put the gsp-5258902.bin and the booters into /lib/firmware/nvidia/<family>/gsp
20:44fdobridge: <Esdras Tarsis> and choose the correct firmware for your gpu architecture, the driver comes with two iirc
20:55fdobridge: <Mohamexiety> theoretically the same steps should apply to ampere right?
21:19fdobridge: <airlied> yup in theory, just making sure you have the right files
21:20fdobridge: <Mohamexiety> alight, thanks! I should have time to try this out tomorrow or sunday
21:20fdobridge: <Mohamexiety> alright, thanks! I should have time to try this out tomorrow or sunday (edited)
23:49fdobridge: <karolherbst🐧🦀> as long as I'm not driving a display, I should be fine, right?
23:50fdobridge: <karolherbst🐧🦀> or should I also avoid running anything using kms?
23:53airlied: display can work