12:32 jbakita: skeggsb: Are you still online? I have a question about how much we know about the firmware's behavior in scheduling the runlist
12:55 RSpliet: jbakita: I think if I draw a venn-diagram of skegggsb's and your waking hours, it'd look like binoculars :-P
13:11 jbakita: Haha, I think so
13:12 jbakita: I think he's online later in the day for me though, I just need to remember to come back over here
13:13 jbakita: RSpliet: I did end up getting your paper back from the repository yesterday, thanks!
13:42 RSpliet: jbakita: no worries, and thanks! Without you I would'nt've known that I wasn't receiving repository requests due to an outdated e-mail address in their systems :_D
14:49 jbakita: yalue: Hey Nathan!
14:49 yalue: Hi!
14:50 jbakita: RSpliet: I think that Nathan was also at OSPERT the year you were there
14:52 jbakita: He's a more senior PhD student in my group with a focus on GPU scheduling
15:00 imirkin: jbakita: did you get a sufficient answer to your question about how the imem stuff works?
15:14 jbakita: imirkin: Yes! Thank you so much. Your help was just what I needed
15:15 jbakita: I was trying to parse the page table structure while the proprietary module was loaded, and your pointers were enough for me to figure it out. So if anyone else is wanting to print the BAR2/3 page tables while the proprietary module is loaded, I have a kernel module for that
15:36 imirkin: jbakita: put it up somewhere, could come in useful for someone
15:44 jbakita: imirkin: I will. It's a bit brittle right now (doesn't properly handle big pages for example), but I'll ping you when it's up in case you think it's worthy of being linked to from a nouveau page
17:26 RSpliet: yalue: oh yes hello Nathan. We definitely had a chat around OSPERT/ECRTS. And if memory serves me well, we toasted a fine glass of bruschetta...
18:09 yalue: RSpliet: I remember! It was a great talk. I just printed out another copy of your OSPERT paper. Unfortunate that I took so long to reconnect, but since then I've tried to move my research to AMD GPUs, simply due to their open-source compute stack.
18:16 RSpliet: yalue: heh, yeah the same has happened here. My next GPU's likely to be AMD. As far as firmware goes, NVIDIA has so far been all fart but no poo. It hampers OSS development...
18:52 Lyude: i've never seen such an incredibly simple analogy that so elegantly describes nvidia's open source situation Lol
20:00 ajax: here i sit, all broken hearted
20:06 marex: RSpliet: ever since I got this AMD GPU, my upstream contributions in that area reduced to zero ... I didn't have to debug any kernel bug and send patches to make the GPU usable, I didn't have to investigate X11 internals either, ... I can highly recommend against it if that's what you're after, the damn thing just works so far
20:06 Lyude: yeah amd works great
20:07 Lyude: i'd like to clean up their driver but hey
20:07 Lyude: the code works
20:07 marex: that :)
20:09 RSpliet: marex: my contributions have dried up long ago. Not in the least because I work for a competitor right now. Also because 40 hours of computering is enough.
20:09 RSpliet: With that in mind, i'd happily trade my crash-four-times-a-day Kepler for an AMD card
20:11 marex: [ 31.363374] nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 3 [Xorg[535]] subc 0 mthd 0060 data beef0201
20:11 marex: dang
20:12 marex: this is on NVIDIA Corporation G86M [Quadro NVS 140M] and 5.14.y
20:23 marex: RSpliet: :)
20:26 karolherbst: marex: current 5.14?
20:27 marex: karolherbst: whatever is in debian unstable, I am now installing the 5.14.y with extra patches
20:27 marex: 5.14.9 it says
20:27 karolherbst: I don't think the fix for nv50 suspend landed yet in a stable tree
20:28 marex: karolherbst: I am about to add that, the machine is slow :)
20:28 karolherbst: it's not even in 5.15 yet.. oh well
20:28 karolherbst: I guess it will take a bit more time :D
20:28 karolherbst: I have no idea how long it takes
20:29 marex: karolherbst: it must land in linus tree first, and only then it can be picked for stable
20:29 marex: I recently made the mistake of asking stable to pick USB ID from next, rejected
20:29 marex: oh well
20:29 karolherbst: ehh.. yeah.. :D
20:32 marex: karolherbst: ah btw skeggsb told me to try drivers/gpu/drm/nouveau/nv84_fence.c
20:32 marex: - priv->base.uevent = true;
20:32 marex: + priv->base.uevent = false;
20:33 karolherbst: ahh
20:33 karolherbst: that's for the sway thing, right?
20:33 marex: to avoid the suspend issue, that does help, but it isnt the right fix
20:33 marex: yep
20:33 karolherbst: mhhh
20:33 karolherbst: right...
20:34 marex: all right, kernel is all nicely patched and kde/plasma on this old box starts properly
20:34 marex: the cache error is still there however
20:34 marex: [ 40.421666] nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 4 [Xorg[534]] subc 3 mthd 1b00 data 00000000
21:14 Lyude: speaking of amd: if someone ever started a collab project on cleaning up their driver, it sounds like I wouldn't be the only one interested in that
23:14 HdkR: Lyude: Is this why RH is hiring more kernel people? amdgpu janitor? :D
23:14 Lyude: no
23:39 marex: that brno location is nice btw ;-)