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