00:03 fdobridge: <E​sdras Tarsis> I think TU117 doesn't have GSP firmware support in Ben's nouveau driver 🐸
00:26 fdobridge: <g​fxstrand> Ok, decent Maxwell now landed. I've also added a few generic MME tests. We should add more but I got us started.
00:26 fdobridge: <g​fxstrand> These are for testing the builder not the hardware so it runs against the simulators. This means we can run them in CI. 😄
00:26 fdobridge: <g​fxstrand> If you follow the pattern I used, it'll test both simulators to ensure consistency.
00:27 fdobridge: <g​fxstrand> But, yeah, Maxwell is now almost as good as Turing. 😄
00:28 anholt: kepler still effectively unsupported, right?
00:29 fdobridge: <k​arolherbst🐧🦀> no, it is supported
00:29 fdobridge: <k​arolherbst🐧🦀> just not tested I think atm 😄
00:30 fdobridge: <k​arolherbst🐧🦀> I will probably look into it this weekend and fix all the texture header bugs lurking around or something 😛
00:41 anholt:shoves some code at ci, let's see what happens.
01:10 HdkR: :+1: to simulators in CI. I do the same :D
03:02 fdobridge: <g​fxstrand> I should add more to the sim-based tests. There's only 4 tests in there now. But at least I started.
05:01 fdobridge: <n​epnep> Until Turing gets GSP :frog_pregnant:
05:06 fdobridge: <g​fxstrand> Until Turing gets GSP, Maxwell is probably better. 😅
05:08 airlied: skeggsb: did you figure out gsp sync reporting yet?
05:08 airlied: that was what stopped me crossing the streams last time between gsp and vk
05:09 skeggsb: no - i haven't looked again yet. i will next week
05:18 mupuf: HdkR: Simulators in CI bring up more PTSD than good feelings over here
05:19 mupuf: Not that it isn't possible to do it right... it's just that it requires careful consideration which I have never seen it from teams that design such simulators :D
06:28 HdkR: mupuf: Sometimes its the only option, ideally I'll remove it from CI when no longer necessary
06:29 HdkR: Missing features, bugs, slow, etc
06:30 mupuf: Yeah. I guess what I hate is not, simulators, it is shoddy HW development practices
06:30 HdkR: Indeed, that's a problem
06:31 mupuf: If they use high-level synthesis, all is fine as the simulator will actually be enjoyable to work with (you can even step in the code in gdb)
06:31 HdkR: Just make sure to have multiple tiers of simulators at different levels, so you can hit bugs all the way down ;)
06:32 mupuf: but if it is a re-implementation based on a behavioral spec... which is itself often not updated...
06:32 mupuf: absolutely :)
06:36 mupuf: I started a project called LiteDIP when I was burnt out at Intel. It stands for LiteX-based Discoverable IPs, and I was designing it so that the hardware had test benches, the driver had unit tests, and integration testing would have been possible with verilator+UserModeLinux
06:36 mupuf: Of course, you could run this directly on an FPGA too, which was somewhat the point
06:37 mupuf: I hope to get back to it during my parental leave
06:37 mupuf:really wants to make his own display engine running over USB or PCIe
06:40 mupuf: Weirdly enough, my biggest issue is not related to PCIe, USB, DMA, DDR (all of these components are plug and play in LiteX), but the silly PLL designs found in Xilinx or Lattice FPGAs: no dynamic reclocking*
06:40 mupuf: (well, you can dynamically reclock on Xilinx, but it is meant as a partial reconfiguration)
06:42 mupuf: so... I started designing my own fractional divider over the summer vacation.
06:42 mupuf: </offtopic>
07:01 HdkR: Very cool though
14:54 fdobridge: <g​fxstrand> This simulator only stimulates the NVIDIA MME and it's just for mme_builder unit testing.
15:31 fdobridge: <E​sdras Tarsis> what is mme?
15:33 fdobridge: <k​arolherbst🐧🦀> macro engine to generate command streams on the GPU
15:53 fdobridge: <g​fxstrand> Mmio Macro Engine
15:54 fdobridge: <p​homes> wrt the mme I am still puzzled about nvk issue #49
16:10 fdobridge: <g​fxstrand> Yeah, I don't get that either.
16:12 fdobridge: <n​anokatze> it's macro method expander
16:25 fdobridge: <g​fxstrand> That makes sense too, I guess.
16:44 fdobridge: <g​fxstrand> Whatever it is, we have simulators and unit tests and they'll run in CI. 😅
16:45 fdobridge: <E​sdras Tarsis> I didn't know how Ben's kernel looks for gsp firmware so I added a printk
16:45 fdobridge: <E​sdras Tarsis> `nouveau: searching for firmware in nvidia/tu117/gsp/gsp-5256011.bin`
16:45 fdobridge: <E​sdras Tarsis> now it's clear :)
20:16 fdobridge: <g​fxstrand> Does the nouveau kernel module make copies of pushbufs or anything like that?
20:38 fdobridge: <a​irlied> Nope
21:26 fdobridge: <g​fxstrand> Maybe my WFI isn't actually idling the compute engine?
23:51 fdobridge: <g​fxstrand> Ok, I finally maybe got indirect draw working. 😄