00:07 Lyude: imirkin: got ce tiling working,
00:07 Lyude: oh oops didn't mean to hit enter yet
00:09 Lyude: what i was about to ask was regarding the comments about swizzling in nve4_m2mf_transfer_rect() (the one that says DST_W = SRC_W, DST_X = SRC_X, etc...), do XYZW just refer to the (up to) four different color channels?
00:17 karolherbst: dcomp: ohh, that's the one which has broken clock state right after boot?
00:18 karolherbst: dcomp: yeah.. put it into runtime_resume somewhere :p
00:18 karolherbst: nouveau_do_resume probably
00:19 karolherbst: mhhh
00:19 karolherbst: what an ugly bug
00:19 karolherbst: actually...
00:19 karolherbst: ufff
00:19 karolherbst: skeggsb: we have this super ugly bug
00:19 karolherbst: like _super_ ugly
00:19 karolherbst: you will hate it
00:20 karolherbst: skeggsb: sooo... apparently dcomp has a GPU where it requires reclocking in order to work at all
00:20 karolherbst: essentially before any memory gets touched
00:20 karolherbst: opinions?
00:22 karolherbst: I could probably figure out all the places where we need to add the reclocking bits for it... just super ugly
00:22 karolherbst: and we might want to add a module option + quirk list for those systems?
00:22 karolherbst: really no idea on how to handle this
00:24 skeggsb: before *any* memory gets touched is a bit extreme, vbios presumably sets up scanout just fine
00:24 karolherbst: it's a laptop
00:24 skeggsb: we already have a module option to change clocks, just make sure it's done in the right places i guess
00:24 karolherbst: booting with config=NvClkMode=0xf _used_ to work
00:24 karolherbst: but not anymore
00:24 skeggsb: it's also more likely we do something wrong executing devinit
00:24 karolherbst: ahh, could be
00:24 skeggsb: we've had weird issues where we've fucked up the memory controller before
00:24 karolherbst: why didn't I thought of that
00:25 karolherbst: ohh, okay
00:25 Lyude: skeggsb: btw, would you possibly know the answer to the question I asked a little higher above?
00:26 karolherbst: dcomp: I bet we asked for this before, but mind sharing your dmesg?
00:27 skeggsb: Lyude: yeah, you can treat those as colour channels
00:27 Lyude: cool
00:28 skeggsb: karolherbst: probably want a mmiotrace of RM doing devinit, and one of nouveau
00:29 skeggsb: last time it was something stupidly subtle, like extra (maybe it was not enough?) register *reads* to determine memory strapping made it screw up
00:29 skeggsb: see the comments in subdev/bios/init.c::init_ram_restrict()
00:30 karolherbst: uff
00:31 skeggsb: we *do* have devinit.xml these days, maybe that'll help
00:33 skeggsb: there's other stuff too, RM does a few things *before* devinit that we don't do
00:33 skeggsb: that's been a factor in bugs like this before
00:33 karolherbst: I see
00:34 karolherbst: dcomp: anyway, did you ever create a proper bug somewhere with all the details? dmesg, vbios.rom file, maybe even an mmiotrace of nvidia?
00:35 karolherbst: dcomp: ohh, nvm..
00:35 karolherbst: I have it
00:35 karolherbst: skeggsb: nouveau_vbios_trace/nv118/dcomp
00:35 skeggsb: i don't have time to look atm, unfortunately
00:38 karolherbst: skeggsb: LOL... :/
00:38 karolherbst: this doesn't look good
00:39 karolherbst: skeggsb: nvidia reclocks super early
00:39 skeggsb: i'm well aware :P
00:39 karolherbst: but maybe stuff is also missing
00:39 karolherbst: mhh
00:40 karolherbst: they do change only mem clocks though :p
00:40 karolherbst: and super early I mean like within the first 200 mmio accesses
00:41 karolherbst: skeggsb: that's before devinit for sure :/
00:41 skeggsb: i don't think so... they might tweak some stuff, but a full mclk change is impossible that early
00:41 karolherbst: well right..
00:41 karolherbst: they just change the memory PLL a little
00:42 karolherbst: but they do change the PLL
00:42 karolherbst: [0] 332.325706 MMIO32 R 0x137310 0x01100000 PCLOCK.MCLK_PLL0_REF_DIV_CRTL => { POST_DIVIDER_DIV_MODE = 0x2 | POST_DIVIDER_PLL_MODE = 0x2 | 0x1100000 }
00:42 karolherbst: [0] 332.325721 MMIO32 W 0x137310 0x01100606 PCLOCK.MCLK_PLL0_REF_DIV_CRTL <= { POST_DIVIDER_DIV_MODE = 0x8 | POST_DIVIDER_PLL_MODE = 0x8 | 0x1100000 }
00:42 skeggsb: this is one of those "RM does stuff before devinit that we don't" that I mentioned :P
00:43 karolherbst: yeah
00:43 karolherbst: I see :)
00:43 karolherbst: mhh
00:43 karolherbst: [0] 332.325670 MMIO32 W 0x137380 0x00000000 PCLOCK+0x380 <= 0
00:43 karolherbst: [0] 332.325686 MMIO32 W 0x137360 0x00000003 PCLOCK+0x360 <= 0x3
00:43 karolherbst: :/
00:43 karolherbst: fun
00:44 karolherbst: this will be fun to investigate
00:45 karolherbst: dcomp: willing to play a bit of ping pong and try out patches and stuff? I could probably write something simple which might fix it as well, just wondering what exactly is what is missing
00:46 karolherbst: anyway, time for bed
02:14 Lyude: :D, figured out the last piece to getting kms_plane running. turns out I forgot to hook up ce blitting in one spot, and now things seem to work
02:15 Lyude: still will probably need to make a few more changes though to teach kms_plane how to cope with missing a crc frame occasionally, but I'm pretty sure i know how to do that
02:21 Lyude: ...or maybe not, [34834.496022] nouveau 0000:1f:00.0: fifo: fault 01 [WRITE] at 000000007f400000 engine 15 [CE0] client 01 [HUB/CE0] reason 02 [PTE] on channel 2 [103f9a7000 kms_plane[3720]]. I'm close at least
02:22 Lyude: it ran for a pretty decent amount of time without failing a single crc check
02:54 imirkin: Lyude: in case your question wasn't answered ... yes :)
02:54 imirkin: dcomp: send a patch
02:56 imirkin: dcomp: oh, nevermind, i see there was more conversation on the topic. sounds like an annoying issue.
03:02 Lyude: imirkin: yeah-although I don't think I'm going to need swizzling at all, it doesn't look like we need to convert color formats with the gpu since igt has a bunch of code to handle it already. But, now that I've got kms_plane kind of running I'm dealing with this very bizarre issue: https://lyude.net/~lyudess/tmp/igt-evo-plane/igt-kms-plane-fail.txt
03:02 Lyude: https://lyude.net/~lyudess/tmp/igt-evo-plane/igt-mmu-fault.txt
03:05 imirkin: Lyude: i dunno what you're using it for
03:06 imirkin: (the copy engine)
03:06 imirkin: Lyude: also did you fix the increment to be 7 rather than 6?
03:07 imirkin: (i mean free space requirement)
03:07 Lyude: imirkin: yeah, and imirkin we're using it for tiling/untiling surfaces in igt
03:07 imirkin: Lyude: ah, if it's just tile/until, there's never format conversion
03:07 imirkin: so no swizzling
05:42 imirkin: Lyude: are you sure the dst buffer is mapped properly?
05:43 imirkin: Lyude: i.e. is it attached to the pushbuf submit? and/or pinned?
05:43 imirkin: otherwise it can get moved out of vram
05:45 imirkin: Lyude: ah yeah. this doesn't work
05:45 imirkin: https://gitlab.freedesktop.org/lyudess/igt-gpu-tools/-/blob/wip/nouveau-evo-plane-v1/lib/nouveau/igt_nouveau.c#L309
05:45 imirkin: this *looks* like it works
05:45 imirkin: but it doesn't work
05:46 imirkin: the thing is that if the pushbuf gets submitted in the middle
05:46 imirkin: then the post-submit pushbuf doesn't have those referenced
05:46 imirkin: the solution to that problem is to use a bufctx
05:46 imirkin: (well, among others)
05:47 imirkin: also, i dunno what the deal is with the CE0 | CE1 engine thing, but i don't think you want that - just use CE0.
05:48 imirkin: not sure that it matters though
05:48 skeggsb: it might matter, i can't remember what the drm does there now
05:49 skeggsb: some GPUs don't have both, and i can't remember if the uapi code cares still
05:49 imirkin: oh right
05:49 imirkin: annoying.
05:49 skeggsb: i'm doing something better there going forward, but i haven't quite finished mapping that part out yet