11:48 karolherbst: huh
11:48 karolherbst: nouveau 0000:01:00.0: fifo: PBDMA0: 04000000 [ACQUIRE] ch 2 [00ff946000 Xorg[1429]] subc 0 mthd 001c data 00001004
11:48 karolherbst: mthd 001c?
11:49 karolherbst: NVC0_3D_COUNTER_RESET_UNK1C mhh
11:49 karolherbst: ehh no
11:49 karolherbst: that's a value
13:56 imirkin: method 0x1c is a subchan method
14:11 karolherbst: ohhh
14:11 karolherbst: I totally forgot about those
14:13 karolherbst: used inside nvc0_hw_query_fifo_wait
14:14 imirkin: anything less than 0x100 is subchan
14:14 imirkin: 0x100+ is class method
14:14 karolherbst: right
14:14 imirkin: don't even need an object bound to a subchan to execute the subchan methods
14:14 karolherbst: now what could this error mean in the end
14:15 imirkin: i guess it failed to acquire the semaphore?
14:15 karolherbst: sure, but would it also get hit if the semaphore is in whatever way invalid?
14:16 karolherbst: or is there some weird timeout?
14:28 imirkin: good question
14:28 imirkin: next question?
15:25 imirkin: glennk: btw, i have https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8544 -- never pushed it because i reverted the bit needed to support drm-shim
15:25 imirkin: glennk: if you're looking at making shader changes, it might still be useful
16:24 glennk: looks pretty orthogonal to the bits in my tree so far
16:28 glennk: random question, is srgb conversion for blits handled by nv50/nvc0? don't see anything explicit for it though they both report PIPE_CAP_DEST_SURFACE_SRGB_CONTROL
16:28 imirkin: yes.
16:29 imirkin: srgb has different PIPE_FORMAT's
16:29 imirkin: which in turn results in different RT formats
16:29 imirkin: e.g. https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/g80_defs.xml.h#n115
17:34 Lyude: well that's not good. i just noticed we're getting enough spam aimed at nouveau's mailing lists that gmail has started classifying the notifications for it as spam
17:34 imirkin: Lyude: heh, yeah, i saw that too sometimes
17:34 karolherbst: Lyude: happens to ranom users as well
17:35 imirkin: Lyude: i've been managing it most of the time
17:35 Lyude: karolherbst: yeah gmail is not kind to patch submissions for some reason
17:35 Lyude: been considering switching to something like fastmail for a while now and trying to forward everything from gmail to there
17:36 imirkin: what i really want is something with (a small handful of) gmail's features, but self-hosted
17:36 imirkin: unfortunately i'm not aware of anything which has the gmail features i want
17:36 imirkin: (threading)
17:37 karolherbst: the issue is that IMAP is just broken
17:37 Lyude: karolherbst: that's why there's jmap
17:37 Lyude: wish more things would actually adopt it
17:37 imirkin: is that the EE variant of IMAP?
17:38 Lyude: imirkin: I believe so
17:38 imirkin: ;)
17:38 Lyude: fastmail supports jmap I'm fairly sure, not sure if my client (evolution) does though
17:38 karolherbst: Lyude: but does JMAP actually support folders or just in the IMAP crappy way?
17:38 karolherbst: well
17:38 karolherbst: labeling rather
17:39 Lyude: karolherbst: no idea, I've always just used folders
17:39 karolherbst: yeah.. folders are annoying :(
17:39 Lyude: i also have never actually tried it, just heard nice things about it
17:40 karolherbst: "The data model is backward compatible with both IMAP folders and Gmail-style labels."
17:56 karolherbst: I think I will even try out to recover from a dead channel and see how that goes...
19:44 karolherbst: ehhh.. libdrm needs fixing :(
20:20 karolherbst: channel recovery is working out great https://gist.githubusercontent.com/karolherbst/5f0157cdf64f6d327a63a8883952ef6d/raw/73b05c578df0480e93bd3dc7fde0d1899e724fab/gistfile1.txt
20:22 karolherbst: I may want to ask skeggsb how that's all supposed to work out
21:18 karolherbst: imirkin: any idea how channel recovery might work and what needs to be done? I assume the entire object tree needs to be recreated, but besides that?
21:18 imirkin: no clue, sorry
21:46 karolherbst: what is a bit weird is this READ fault..
21:46 karolherbst: fifo: fault 00 [READ] at 0000000000000000 engine 00 [gr] client 04 [HUB/FE] reason 02 [PTE] on channel 8 [007e694000 RenderingThread[19298]]
21:59 imirkin: trying to deref addr 0?
21:59 imirkin: that's usually frowned upon
21:59 karolherbst: right.. but I am wondering how that can happen
21:59 karolherbst: ohhhh wait
21:59 imirkin: i barely know what HUB/FE is
21:59 karolherbst: I am stupid
21:59 imirkin: sounds like ctxsw?
21:59 karolherbst: yeah.. it's worse
21:59 karolherbst: look.. I created a new channel I have to.. you know
22:00 karolherbst: also set the entire state
22:00 imirkin: oops?
22:00 karolherbst: I guess
22:00 karolherbst: sooo...
22:00 karolherbst: I essentially have to do most of the shit done in screen_create and new context (if any) and mark everything dirty?
22:01 karolherbst: and probably also recreate all subchan objects
22:01 karolherbst: mhh
22:01 karolherbst: let's rewrite some code :D
22:03 karolherbst: but at least I know that I can keep the pushbuffer object
22:03 karolherbst: and that submitting stuff works
23:51 karolherbst: imirkin: not sure if improvement or not: https://gist.githubusercontent.com/karolherbst/3a59b74f3a203bccbac03f766167648d/raw/433ec9ae736a622056fd7de455599d7a0d2b2e52/gistfile1.txt
23:51 imirkin: almost there
23:52 karolherbst: I mean.. I keep the bos...
23:58 karolherbst: is there something funky about macros I forget?