12:52 OftenTimeConsuming: karolherbst: Yeah, I have a 780 and a 780 Ti and they kind of work, but they're very unstable. GtK can easily get Xorg to hang for example (and then I can't cleanly reboot as the keyboard doesn't work).
12:53 karolherbst: OftenTimeConsuming: might fetching logs from there via ssh or netconsole or a serial console?
12:54 karolherbst: OftenTimeConsuming: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19543 _might_ improve the situation but it kinda depends on why it freezes
12:54 OftenTimeConsuming: Ah yes, why didn't I think of that? I do have a serial port and an null modem cable, but nothing to plug it in, so ssh it is.
12:54 karolherbst: I kinda want to eliminate as many as possible of those freezes, at least the ones caused by userspace
12:55 karolherbst: yeah.. I bought a RS232 serial console for my desktop :D
12:55 OftenTimeConsuming: The BIOS I'm using is very buggy and has problems with interrupts, but they don't seem to correspond with the hangs, as I don't see anything in dmesg when there's a hang.
12:57 OftenTimeConsuming: Well, time to start drawing with GIMP
12:59 karolherbst: yeah.. it kinda depends on how the machine goes down
13:00 karolherbst: it might also just it freezes for a while as the kernel is still waiting to tear the context down or something
13:00 OftenTimeConsuming: In sway I do get 20 second long hangs with a few seconds of breaks between due to context switching issues.
13:01 karolherbst: mhhh
13:01 karolherbst: yeah.. might be that how fences work in nouveau/mesa that my MR would indeed help with that
13:02 OftenTimeConsuming: Nice.
13:02 karolherbst: but there is more I have to add on top
13:03 OftenTimeConsuming: All the fences seem to get tripped once you push 1440p@120Hz
13:03 karolherbst: uhh
13:03 karolherbst: annoying
13:06 OftenTimeConsuming: Hmm, maybe this is a BIOS bug: https://termbin.com/1eokg
13:13 OftenTimeConsuming: I'm guessing that a BIOS bug that causes threads to lock up turns a "crash Xorg" bug into a "hang and keyboard stops working" bug, as the crashed xorg thread can't exit. I guess I'm going to have to get that dasharo build done to see if they've fixed that bug...
13:14 karolherbst: ohh.. you want to upgrade your kernel
13:14 karolherbst: OftenTimeConsuming: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213
13:14 karolherbst: or downgrade
13:15 karolherbst: yeah...
13:15 karolherbst: it's not fixed in 6.3.8 yet
13:15 karolherbst: you have to wait until 6.3.9
13:15 karolherbst: or downgrade to 6.2
13:15 OftenTimeConsuming: Thanks, but I can't read that on this computer.
13:15 karolherbst: just downgrade to 6.2 and you should be fine
13:16 karolherbst: airlied: ^^ 🙃 let's hope it's fixed good enough, but we really should get rid of all the lockdep splats and other things
13:16 OftenTimeConsuming: What about 6.4-rc7?
13:17 karolherbst: OftenTimeConsuming: seems like the fix landed in 6.4-rc7
13:17 karolherbst: so should be good
13:18 OftenTimeConsuming: Thanks, time to compile...
13:18 karolherbst: but yeah.. this issue is a hard kernel crash
13:18 karolherbst: and almost nothing works after that
13:19 OftenTimeConsuming: It seems that I have enough cores that the scheduler still manages to work even with a bunch stuck
13:20 karolherbst: yeah soo... things kinda work as long as they don't allocate new kenrel memory through `kmalloc`
13:20 OftenTimeConsuming: Does gcc use kmalloc?
13:24 OftenTimeConsuming: It does, everythings falling over when I try to compile :D
13:24 karolherbst: well.. it does try to allocate memory
13:24 karolherbst: but it's a kernel side thing
13:52 OftenTimeConsuming: karolherbst: Thanks for your help, the crash bug and the sway context switching issues now seem to be gone. I haven't induced a hang yet. Maybe I should have listened to the instinct to upgrade Linux... Looks like my computer is now perfectly usable, yayyy
13:52 karolherbst: nice
13:54 OftenTimeConsuming: Hmm, I wonder why 3D performance is better than 2D performance.
13:55 OftenTimeConsuming: Supertuxkart runs fine, but xmoto (SDL2 version) drops to like 30fps.
13:55 karolherbst: well... CPU rendering is expensive
13:55 karolherbst: but it always depends
13:55 karolherbst: some 2D games are just badly optimized
13:56 karolherbst: some are quite expensive to render
13:56 karolherbst: OftenTimeConsuming: is this on X with the nouveau DDX?
13:56 OftenTimeConsuming: Ideally SDL2 should be doing GPU rendering.
13:56 karolherbst: yeah... SDL2 should, but it doesn't
13:56 karolherbst: not automatically
13:56 OftenTimeConsuming: DDX?
13:56 karolherbst: Xorg driver
13:57 karolherbst: applications have to allocate a GPU accelerated SDL context explicitly afaik
13:57 OftenTimeConsuming: Yes.
13:57 karolherbst: you might want to try out the modesetting one as it supports acceleration for more 2D operations than the nouveau one
13:57 karolherbst: it uses OpenGL directly though, so it's not a clear cut on what's better
13:57 karolherbst: but modesetting should be prefered
13:58 OftenTimeConsuming: I guess that explains why I need to call: SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC); in that sdl2 port
13:58 karolherbst: yes
13:59 karolherbst: I think there is an env variable to force it even
13:59 karolherbst: but apps can crash if they use backend SDL functions
13:59 karolherbst: like the SDL_GL stuff
14:00 OftenTimeConsuming: I believe I'm using modesetting actually
14:01 OftenTimeConsuming: Although I do have x11-drivers/xf86-video-nouveau installed
14:02 Ermine: You may want to specify driver in xorg.conf
14:03 OftenTimeConsuming: Any examples?
14:06 Ermine: I believe Section "Device" \ Identifier "Nvidia card" \ Driver "modesetting" \ EndSection should do
14:06 OftenTimeConsuming: The video mode doesn't seem to change when I swap from Xorg to fbcon (figuring out how to force 1440p@120Hz max wasn't fun when Linux wants to do 1440p@165Hz, even though nvidia in their infinite wisdom didn't allow DP to achieve the max VBR2 clock rate)
14:06 OftenTimeConsuming: Lets try.
14:10 OftenTimeConsuming: I don't seem to see any difference, I believe the modesetting driver was the default.
14:17 OftenTimeConsuming: Checking Xorg.0.log, it seems that modesetting is loaded, then unloaded and then the "exa" module is loaded. Now it's just modesetting
14:34 karolherbst: mhh, yeah, maybe it's just not very optimized
14:40 Ermine: Isn't EXA thing from somethere mid-2000s?
14:46 OftenTimeConsuming: If it works, it works.
14:47 karolherbst: yeah.. exa is kinda broken
14:52 Ermine: I mean, the only places where I saw EXA mentioned are some pages listed at https://nouveau.freedesktop.org/IntroductoryCourse.html
14:53 Ermine: So I thought it's long forgotten and deprecated thing...
15:57 karolherbst: yeah, it is