00:07Lyude: imirkin: got ce tiling working,
00:07Lyude: oh oops didn't mean to hit enter yet
00:09Lyude: 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:17karolherbst: dcomp: ohh, that's the one which has broken clock state right after boot?
00:18karolherbst: dcomp: yeah.. put it into runtime_resume somewhere :p
00:18karolherbst: nouveau_do_resume probably
00:19karolherbst: mhhh
00:19karolherbst: what an ugly bug
00:19karolherbst: actually...
00:19karolherbst: ufff
00:19karolherbst: skeggsb: we have this super ugly bug
00:19karolherbst: like _super_ ugly
00:19karolherbst: you will hate it
00:20karolherbst: skeggsb: sooo... apparently dcomp has a GPU where it requires reclocking in order to work at all
00:20karolherbst: essentially before any memory gets touched
00:20karolherbst: opinions?
00:22karolherbst: I could probably figure out all the places where we need to add the reclocking bits for it... just super ugly
00:22karolherbst: and we might want to add a module option + quirk list for those systems?
00:22karolherbst: really no idea on how to handle this
00:24skeggsb: before *any* memory gets touched is a bit extreme, vbios presumably sets up scanout just fine
00:24karolherbst: it's a laptop
00:24skeggsb: we already have a module option to change clocks, just make sure it's done in the right places i guess
00:24karolherbst: booting with config=NvClkMode=0xf _used_ to work
00:24karolherbst: but not anymore
00:24skeggsb: it's also more likely we do something wrong executing devinit
00:24karolherbst: ahh, could be
00:24skeggsb: we've had weird issues where we've fucked up the memory controller before
00:24karolherbst: why didn't I thought of that
00:25karolherbst: ohh, okay
00:25Lyude: skeggsb: btw, would you possibly know the answer to the question I asked a little higher above?
00:26karolherbst: dcomp: I bet we asked for this before, but mind sharing your dmesg?
00:27skeggsb: Lyude: yeah, you can treat those as colour channels
00:27Lyude: cool
00:28skeggsb: karolherbst: probably want a mmiotrace of RM doing devinit, and one of nouveau
00:29skeggsb: 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:29skeggsb: see the comments in subdev/bios/init.c::init_ram_restrict()
00:30karolherbst: uff
00:31skeggsb: we *do* have devinit.xml these days, maybe that'll help
00:33skeggsb: there's other stuff too, RM does a few things *before* devinit that we don't do
00:33skeggsb: that's been a factor in bugs like this before
00:33karolherbst: I see
00:34karolherbst: 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:35karolherbst: dcomp: ohh, nvm..
00:35karolherbst: I have it
00:35karolherbst: skeggsb: nouveau_vbios_trace/nv118/dcomp
00:35skeggsb: i don't have time to look atm, unfortunately
00:38karolherbst: skeggsb: LOL... :/
00:38karolherbst: this doesn't look good
00:39karolherbst: skeggsb: nvidia reclocks super early
00:39skeggsb: i'm well aware :P
00:39karolherbst: but maybe stuff is also missing
00:39karolherbst: mhh
00:40karolherbst: they do change only mem clocks though :p
00:40karolherbst: and super early I mean like within the first 200 mmio accesses
00:41karolherbst: skeggsb: that's before devinit for sure :/
00:41skeggsb: i don't think so... they might tweak some stuff, but a full mclk change is impossible that early
00:41karolherbst: well right..
00:41karolherbst: they just change the memory PLL a little
00:42karolherbst: but they do change the PLL
00:42karolherbst: [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:42karolherbst: [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:42skeggsb: this is one of those "RM does stuff before devinit that we don't" that I mentioned :P
00:43karolherbst: yeah
00:43karolherbst: I see :)
00:43karolherbst: mhh
00:43karolherbst: [0] 332.325670 MMIO32 W 0x137380 0x00000000 PCLOCK+0x380 <= 0
00:43karolherbst: [0] 332.325686 MMIO32 W 0x137360 0x00000003 PCLOCK+0x360 <= 0x3
00:43karolherbst: :/
00:43karolherbst: fun
00:44karolherbst: this will be fun to investigate
00:45karolherbst: 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:46karolherbst: anyway, time for bed
02:14Lyude: :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:15Lyude: 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:21Lyude: ...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:22Lyude: it ran for a pretty decent amount of time without failing a single crc check
02:54imirkin: Lyude: in case your question wasn't answered ... yes :)
02:54imirkin: dcomp: send a patch
02:56imirkin: dcomp: oh, nevermind, i see there was more conversation on the topic. sounds like an annoying issue.
03:02Lyude: 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:02Lyude: https://lyude.net/~lyudess/tmp/igt-evo-plane/igt-mmu-fault.txt
03:05imirkin: Lyude: i dunno what you're using it for
03:06imirkin: (the copy engine)
03:06imirkin: Lyude: also did you fix the increment to be 7 rather than 6?
03:07imirkin: (i mean free space requirement)
03:07Lyude: imirkin: yeah, and imirkin we're using it for tiling/untiling surfaces in igt
03:07imirkin: Lyude: ah, if it's just tile/until, there's never format conversion
03:07imirkin: so no swizzling
05:42imirkin: Lyude: are you sure the dst buffer is mapped properly?
05:43imirkin: Lyude: i.e. is it attached to the pushbuf submit? and/or pinned?
05:43imirkin: otherwise it can get moved out of vram
05:45imirkin: Lyude: ah yeah. this doesn't work
05:45imirkin: https://gitlab.freedesktop.org/lyudess/igt-gpu-tools/-/blob/wip/nouveau-evo-plane-v1/lib/nouveau/igt_nouveau.c#L309
05:45imirkin: this *looks* like it works
05:45imirkin: but it doesn't work
05:46imirkin: the thing is that if the pushbuf gets submitted in the middle
05:46imirkin: then the post-submit pushbuf doesn't have those referenced
05:46imirkin: the solution to that problem is to use a bufctx
05:46imirkin: (well, among others)
05:47imirkin: 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:48imirkin: not sure that it matters though
05:48skeggsb: it might matter, i can't remember what the drm does there now
05:49skeggsb: some GPUs don't have both, and i can't remember if the uapi code cares still
05:49imirkin: oh right
05:49imirkin: annoying.
05:49skeggsb: i'm doing something better there going forward, but i haven't quite finished mapping that part out yet