14:42 sanaris: Guys, if there is somewhere a way to run Nouveau on Windows, I would like to look into it purely for testing and compare experiments. Show me links if there's any, thanks :)
18:08 Lyude: Hey - does anyone here understand how the interlock stuff with update methods works on the evo channel?
18:11 Lyude: hm, actually I think I might understand it. it seems like it just designates what resources on the evo channel to lock for updating
18:55 Lyude: wow, I am very pleasently surprised at how easy it is to figure out evo channel related issues
18:55 Lyude: it even tells you what method you got wrong!
18:59 Lyude: imirkin: ^ I am working on getting CRC readback working today, if it wasn't obvious :)
19:27 Lyude: skeggsb/imirkin: if either of you two are around right now, do you guys know how to ensure that a memory mapping (setup with nvif_mem_init_map() type NVIF_MEM_VRAM) is aligned to 4k?
19:28 Lyude: I'm not entirely sure if that's my issue, but I'm trying to debug why the GPU seems to say the address I'm passing it for the CRC notifier ctx isn't reachable
19:53 imirkin_: Lyude: what's the precise error you're getting?
19:53 imirkin_: all maps are aligned to 4k on non-insane setups
19:54 imirkin_: however you have to set up these stupid dma things which are vestiges of pre-G80 thinking
19:54 imirkin_: esp relevant to notifier objects
19:55 Lyude: imirkin_: ok cool, I was hoping the case. And so: first off the handle that gets set by nvif_mem_init_map() ends up always being 0, so of course trying to set that results in this: https://paste.fedoraproject.org/paste/-Se5ThFbRGZL9vej6tW9vw (not terribly surprising)
19:55 Lyude: also let me actually upload my wip branch
19:56 imirkin_: (basically pre-G80, i.e. pre-gpu-mmu, you had to carefully delineate where the memory you were trying to write was...)
19:59 Lyude: imirkin_: https://gitlab.freedesktop.org/lyudess/linux/blob/wip/nouveau-crc-v1/drivers/gpu/drm/nouveau/dispnv50/crc.c#L171 here's where I'm actually setting up the memory mappings for the crc notifier contexts, and here's where I actually try setting them: https://gitlab.freedesktop.org/lyudess/linux/blob/wip/nouveau-crc-v1/drivers/gpu/drm/nouveau/dispnv50/crc907d.c#L84
20:00 Lyude: is that maybe not the handle I'm supposed to program?
20:02 imirkin_: so it actually yells at you for method 430
20:02 imirkin_: not 438
20:02 Lyude: imirkin_: yes, because 0 is a valid dma context I'd assume and is part of the disable process
20:02 imirkin_: dma handle 0 is inalid
20:03 imirkin_: (i really need a keyboard that reliably operates the letter v)
20:03 Lyude: imirkin_: not according to https://github.com/NVIDIA/open-gpu-doc/commit/36db1ace0c3658ad43b5d94ccbba9be15f14dee5#diff-f74cbce8d73c8fe71f9d279f6a7af387R63
20:03 imirkin_: right yeah, gimme a minute
20:03 Lyude: gotcha
20:04 imirkin_: i'm confused.
20:04 imirkin_: case NV50_CRC_SOURCE_NONE:
20:04 imirkin_: crc_args = 0x7ff80000;
20:05 imirkin_: where does that come from?
20:05 imirkin_: #define NV907D_HEAD_SET_CRC_CONTROL_PRIMARY_OUTPUT 19:8
20:05 imirkin_: you know this means bits 8..19 right?
20:05 imirkin_: not bits 19..27
20:06 Lyude: trying to figure out where I got that from, might have just been a mistake
20:06 imirkin_: you have a lot of <<19's which i think should be <<8's
20:06 Lyude: yeah that value must have been a mistake
20:07 Lyude: imirkin_: mhh, alright-what about the 0 dma handle though?
20:07 Lyude: oh, duh, I shifted by 19 instead of 8 on SOURCE_NONE
20:08 Lyude: that's probably where I got the bogus value from
20:08 imirkin_: not just SOURCE_NONE
20:08 imirkin_: on all of them
20:08 Lyude: yeah
20:08 imirkin_: so the doc you linked to supports my claim
20:08 imirkin_: 0 is not a valid handle
20:08 imirkin_: when you set the handle to 0 it's effectively disabled.
20:09 Lyude: oh-ok, sorry I think I misunderstood what you meant by valid
20:09 Lyude: yeah I assumed 0 would be disabling that
20:09 imirkin_: it's valid in that you can write it, but it's not valid in that it doesn't do DMA :)
20:09 Lyude: yeah-I thought you meant as in "you can't write that"
20:09 imirkin_: right
20:10 imirkin_: also, word of warning - i doubt ben will be big on stuff like BIT(2) and GENMASK(31, 24)
20:11 Lyude: imirkin_: oh yeah I'm aware
20:11 Lyude: I was planning on converting those afterwards
20:11 imirkin_: k
20:11 Lyude: was just easier for copy pasting
20:11 imirkin_: sure
20:25 Lyude: imirkin_: fwiw too, passing ctx->addr instead of ctx->object.handle actually gives a non-zero handle, but that causes us to hit disp: chid 0 stat 00007438 reason 7 [UNRESOLVABLE_HANDLE] mthd 0438 data 00079000 code 00000000: https://paste.fedoraproject.org/paste/E4O23DKkWTaitsfLXbYptw
20:27 imirkin_: yeah, you want the handle there
20:28 Lyude: that's what I figured
20:36 imirkin_: does it work better with << 8?
20:37 Lyude: imirkin_: see the fpaste I just gave, I've got it using the proper << 8 stuff there
20:38 imirkin_: oh, so still get the INVALID_ARG then
20:38 imirkin_: f0f - i don't think that's right
20:38 imirkin_: oh, that's for SOR0
20:39 imirkin_: you need to stick a NONE into the secondary output, i'm guessing
20:39 Lyude: ahhh, good idea
20:40 imirkin_: (that's << 20)
20:45 Lyude: imirkin_: ok cool-that gets rid of the invalid arg
20:48 imirkin_: yay
20:48 imirkin_: now collect crc values and enjoy
20:48 Lyude: imirkin_: we still don't have a valid dma handle though
20:48 Lyude: :P
20:49 imirkin_: uh what?
20:49 imirkin_: you had it right before
20:49 imirkin_: what'd you change?
20:49 Lyude: imirkin_: I didn't have it right, remember how I said ctx->object.handle was 0?
20:49 imirkin_: oh
20:49 imirkin_: well, then you screwed up
20:49 imirkin_: object.handle is what you want
20:49 imirkin_: you just must not be setting it
20:49 imirkin_: check how the LUT stuff works
20:49 imirkin_: it's the same thing
20:50 imirkin_: it might get set in one of the atomic check functions? i forget
20:57 Lyude: imirkin_: I mean-the lut stuff is where I figured out how to do the memory stuff in the first place. memory mappings get initialized in nv50_lut_init(), handle gets flushed for 907d @ head907d_olut_set()
20:57 imirkin_: right
20:58 imirkin_: so that already has the olut.handle as the correct thing
20:58 Lyude: oooh, you get the handle from elsewhere?
20:58 imirkin_: trying to find the cod
20:59 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/dispnv50/head.c#L212
21:01 Lyude: imirkin_: but, that's assigning the handle of the lut to the handle of the core channel's vram buffer isn't it?
21:02 imirkin_: yes.
21:02 imirkin_: i told you
21:02 imirkin_: the handle is a dumb old thing
21:02 imirkin_: a vestige of pre-G80 times
21:02 Lyude: but, then how do you point it to the memory you just allocated?
21:02 imirkin_: you give it the address
21:02 Lyude: OH- the handle gets set, then you init the memory mapping
21:03 Lyude: then you pass the address?
21:03 imirkin_: the memory mapping is unrelated to all this
21:03 imirkin_: first you init all the memory stuff
21:03 imirkin_: asyh->olut.offset
21:03 imirkin_: that's the address in memory
21:03 imirkin_: asyh->olut.handle
21:03 imirkin_: this is basically the instructions for what to do with that address
21:04 imirkin_: imagine pre-mmu days ... is it in VRAM or GART?
21:04 imirkin_: (it's a handle to a dma object, and the dma object contains such info)
21:04 imirkin_: (the dma object can also hold a base address, and a limit size)
21:04 imirkin_: in nouveau, we just make a "vram" dma object
21:05 imirkin_: which lets you address all vram
21:21 cosurgi: imirkin_: (Re: trying the patch) sorry, I didn't try this yet. I am happy that I had no crash these last few days ;) But it's ready to roll. I did a `git pull` and the last commit that I will use next times is: 5444cab "make error when failing to allocate surface more descriptive"
21:21 imirkin_: cosurgi: cool. that should give you more info for those "-2" errors :)
21:22 cosurgi: Any progress on -EAGAIN front is great for me ;))
21:22 imirkin_: well, it's not going to change the outcome
21:23 imirkin_: just when the error happens, it'll tell you what surface size/etc was being allocated
21:23 cosurgi: Good! Maybe we can spot some useful stuff with this info!
21:23 Lyude: imirkin_: ok-I understand what a handle is, and I see where the address we want is, but there's nothing in the CRC documentation I see that accepts anything but a handle. Whereas with head907d_olut_set() we program the offset in method 0x448, _then_ program the handle in 0x45c. The reason I'm getting confused is we have a method in that CRC documentation that lets us program the handle, but nothing that lets
21:23 Lyude: us program an offset.
21:23 cosurgi: Since I have gdb attached to everything, it won't crash immediately. I will make a photo of my screen, and we will know what was there.
21:24 imirkin_: Lyude: ok, that sucks. that means you have to make a special dma object
21:24 Lyude: ok phew
21:24 imirkin_: Lyude: but let me look over those docs first to see if you haven't missed anything
21:24 Lyude: this is what I have been confused about all day :)
21:24 Lyude: imirkin_: np
21:25 imirkin_: hrmph
21:25 imirkin_: well that stinks
21:25 imirkin_: let me find an appropriate example then
21:26 imirkin_: iirc the notifier has the same problem
21:26 Lyude: imirkin_: they -do- call this a notifier
21:26 imirkin_: ah
21:26 Lyude: so it's probably related
21:26 imirkin_: well i mean the main notifier
21:26 imirkin_: but probably same idea
21:27 imirkin_: like SET_CONTEXT_DMA_NOTIFIER notifier.
21:27 imirkin_: (0x0088)
21:29 imirkin_: Lyude: look at chan.sync
21:30 imirkin_: Lyude: disp.c::nv50_dmac_create
21:30 imirkin_: see how it creates 2 dma objects... you get to add a third
21:30 Lyude: four, unfortunately
21:30 imirkin_: huh?
21:31 imirkin_: well wtvr - you get the idea
21:31 imirkin_: note how vram has start = 0, limit = end-of-vram
21:31 imirkin_: and sync has start = syncbuf, end = syncbuf + 1 page
21:32 imirkin_: (oh, looks like syncbuf gets passed in from the outside... i don't fully know the data flow here. but it's the address of the notifier sync buffer)
21:32 Lyude: imirkin_: yeah-btw, the 2 buffers is because each buffer has a limit of 255 CRCs. I have no idea how many most igt tests but from what I can see none of them assume any kind of limit on how many crcs you can read, so the only way we could implement such an api is to flip between notifier contexts before we're about to run out of space
21:32 Lyude: *many most igt tests use
21:35 Lyude: tldr it's basically page flipping
21:35 imirkin_: it's very odd that the crc thing doesn't take an offset.
21:36 imirkin_: but based on the released docs, that appears to be accurate.
21:36 imirkin_: however i wouldn't be surprised if they had omitted something
21:36 Lyude: imirkin_: yeah i'm a bit worried they might have as well
21:36 imirkin_: 430 = config, 438 = handle
21:36 imirkin_: for cursor,
21:37 imirkin_: 480 = config, 484 = offset, 48c = handle. hm.
21:37 Lyude: you know what, I'll give that a try
21:37 imirkin_: i guess it might just not be there
21:37 imirkin_: coz there's an extra hole before the handle in each case
21:38 imirkin_: but not for notifier
21:38 imirkin_: notifier config = 0x84, handle = 0x88
21:38 imirkin_: so yeah. could be.
21:38 imirkin_: worst case, the gpu will take off like a rocket into outer space.
21:39 Lyude: imirkin_: heh, would make a good youtube video
21:40 imirkin_: an easter egg...
22:01 imirkin_: Lyude: any luck?
22:02 imirkin_: Lyude: although come to think of it
22:02 imirkin_: maybe it's best to have dedicated notifiers anyways
22:02 imirkin_: for things where the gpu is *writing* to vram...
22:02 Lyude: imirkin_: I think we do need a special object :( https://paste.fedoraproject.org/paste/Z00L4LI9AJ75s4E98aOhzw
22:03 imirkin_: yeah ok
22:03 Lyude: imirkin_: also, am I right in assuing I'm doing that last core507d_update part wrong as well?
22:03 Lyude: *assuming
22:04 imirkin_: ?
22:04 imirkin_: link
22:04 Lyude: imirkin_: check the fpaste I just linked you too, https://paste.fedoraproject.org/paste/Z00L4LI9AJ75s4E98aOhzw
22:04 Lyude: [ 98.065833] nouveau 0000:01:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0080 data 00000000 code 0020000a
22:04 imirkin_: i mean ...
22:04 imirkin_: that's probably coz of the INVALID_ARG thing
22:44 Lyude: imirkin_: so, in nv50_dmac_create() where exxactly do we get the handle that gets passed to nvif_object_init()?
22:45 Lyude: e.g. the 0xf0000000 that gets passed to nvif_object_init()
22:46 imirkin_: you pass &dmac->sync to nvif_object_init
22:46 imirkin_: nvif_object_init will ... init ... that object
22:46 imirkin_: oh
22:46 imirkin_: you mean wtf is 0xf000000 etc?
22:46 imirkin_: those are totally made-up values
22:46 Lyude: yes
22:46 Lyude: oh perfect
22:46 imirkin_: use your imagination to make up more.
22:47 imirkin_: basically that handle gets "configured" i think?
22:47 imirkin_: i'd have to look
22:47 imirkin_: but i don't think it's anything important
22:47 imirkin_: just has to be unique