01:27 dakr: gfxstrand, airlied: The series to report the IB limit: https://lore.kernel.org/nouveau/20230927012303.23525-1-dakr@redhat.com/T/#t
02:28 gfxstrand: dakr: Okay, I'll try to cook something up tomorrow
03:43 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> It's interesting how glxgears can be messed up
07:58 karolherbst: pabs: they can send patches to see how much work it is to support a super niche feature nobody should use
07:59 karolherbst: if you use VRAM as swap and it crashes your machine it's entirely your fault
08:00 karolherbst: we have way better alternatives like compressed RAM
08:12 pabs: they're in Venezuela, probably can't afford extra RAM for swap
08:15 karolherbst: sure, but using VRAM is just calling for trouble as this is in no way supported by anything. As I said, you can use compressed RAM and won't need to buy more RAM. With e.g. zram you see compression rations of 2.5 and higher (I saw 4.0 myself)
08:17 pabs: I use that myself. you'll use some RAM for the compressed bits though, and they are always complaining about Firefox memory usage, so might be at their limits
08:17 pabs: anyway, yeah very niche feature, I'm surprised it still works at all
08:17 karolherbst: well.. with the frambuffer it kinda makes sense
08:17 karolherbst: but still...
08:18 karolherbst: there are some issues with doing random access over PCIe
08:18 karolherbst: using a SATA SSD would probably be faster even
08:19 pabs: hmm, do people use SSDs as swap? sounds like a bad idea
08:19 karolherbst: they do and it's reasonably fast
08:19 karolherbst: you only notice if you run out of swap space
08:19 karolherbst: things might get a bit slower _if_ you hit swap with heavy workloads
08:20 karolherbst: but it's a totally different experience compared to swap on spinning rust
08:20 pabs: I was thinking from an SSD durability perspective
08:20 karolherbst: mhhh.. I guess it depends on the actual use case, but distributions use swap on SSDs and I don't think there are many problems with that
08:21 karolherbst: the kernel is kinda good at paging out the least used pages anyway
08:21 karolherbst: atm I have 14GiB cached and 8GiB swap use, and the swap is just sitting there unused
08:21 karolherbst: uhm.. not accessed I mean
08:22 karolherbst: so on most modern systems the Swap is usually small enough so only rarely accessed things end up being there and
08:22 karolherbst: yeah..
08:24 karolherbst: but I also have 40GiB of zram set up on my machine ... and I had some fall back disc cache on my SSD in the past, but it's not really needed here...
08:24 pabs:only has 19GB RAM, and only because I found a newer computer in a dumpster :)
08:24 karolherbst: yeah.. I have 32 and it wasn't enough :D
08:28 HdkR: As someone that has hit swap on a RAID-0 NVMe array, it still really sucks. Getting more RAM is still ideal
08:28 karolherbst: oh sure.. it's not perfect, but it's also not terrible
08:29 karolherbst: but as long as you don't run heavy workloads you won't really notice much
08:29 HdkR: I hit it weekly or so, so I complain a lot :D
08:29 karolherbst: but I think using RAID adds a significant overhead here anyway
08:29 karolherbst: at least overhead enough it's noticeable with swap
08:30 HdkR: Could be. I haven't benched swap performance
08:32 karolherbst: but this entire VRAM as swap business is so cursed
08:32 karolherbst: there is also a swap on VRAM implementation using OpenCL! and FUSE!?!? in order to provide swap
08:33 pabs: oO
08:34 karolherbst: yeah.. so it allocates memory via OpenCL and privdes it to the kernel via a file node through fuse, it's really cursed
08:34 karolherbst: you can also use it as a tempfs replacement :D
08:34 karolherbst: *tmpfs
08:35 pabs:feels like there might be a better way...
08:35 karolherbst: though I guess these days you could also do the same through vulkan
08:35 karolherbst: GL even...
08:36 karolherbst: though that's all playing with fire, because some drivers might be like: you know, mapping VRAM to the host is _really_ slow, we just keep a copy in RAM and give you a pointer to that
08:36 karolherbst: so you won't win anything in the end
08:52 karolherbst: pabs: anyway... in regards to using VRAM through nouveau, the problem is, that it's not possible to do without bugs, so it's kinda a mood point to begin with. There are technical reasons why "disabling some range in VRAM" isn't as easy as indicated.
08:53 karolherbst: I tried to explain it to that person already
08:54 Tom^: karol heh i dont know if you remember the 780ti reclocking and benchmarking i did with your patches must be like 10 years ago now, it seems with skeggs patches posted for gsp i might be back to test things on this 3060 laptop gpu soon :P
08:55 karolherbst: heh, fun
08:55 karolherbst: but yeah, I do remember :D
08:55 Tom^: cool :D
09:52 OftenTimeConsuming: I'm getting a lot of lockups to do with context switching playing this stream with mpv with --vo=gpu with my 780; https://live.gnu.org/gnu40.webm Any tips?
09:54 OftenTimeConsuming: I can just switch to CPU rendering, but ehh.
10:00 karolherbst: OftenTimeConsuming: what mesa version are you on?
10:05 OftenTimeConsuming: 23.1.2-r1
10:06 OftenTimeConsuming: I guess I'll compileeeee 23.1.6
10:06 OftenTimeConsuming: Or maybe I should sync first to get the latest versions of packages.
10:09 karolherbst: mhh.. not sure if we have releavant fixes in there for that
10:09 karolherbst: it's still on my todo list to look into what's up with video acceleration here
10:10 karolherbst: it's such a pain to reproduce because whenever I look into it, it just works.. maybe it's different with this video...
10:14 OftenTimeConsuming: How it's a unreliable stream of VP8+vorbis is probably what is causing it. Seems to be fine showing a static image though
10:14 karolherbst: mhhh
10:15 karolherbst: any errors in dmesg?
10:15 OftenTimeConsuming: I just lost the errors, but plenty of context switching ones.
10:16 OftenTimeConsuming: Plugging in a 2560x1440p screen over DP and running such at 120Hz should help with reproduction in my experience. After the lunch break the lockups should continue to occur.
10:18 karolherbst: would be easier if it could be reproduced with a downloadable video file than a stream
10:19 OftenTimeConsuming: I know right? I found the logs in kern.log, so I'll cut them out and upload them.
10:27 karolherbst: anyway.. there isn't really a point in debugging this with a live stream, because it's probably going to take more time than that to figure out and fix things... If there are recordings and the error shows with that, it's a different story...
10:28 OftenTimeConsuming: I got this dmesg error; https://termbin.com/ggl1
10:30 karolherbst: mhhhh
10:30 OftenTimeConsuming: I just updated mesa, if the errors keep occurring, I'll see if I can download a video.
10:30 karolherbst: is this with default clocks?
10:30 karolherbst: but there is quite a bit going on...
10:30 karolherbst: "nv50cal_space: -16" generally means that something couldn't be submitted to the hardware
10:31 karolherbst: OftenTimeConsuming: have you tried to change the pstate to something higher? I know that higher clocks can help with a few errors in this regards
10:32 OftenTimeConsuming: I generally leave it at default clocks as otherwise the card draws 100W at idle.
10:32 karolherbst: 100W as reported through nouveau?
10:33 karolherbst: there is a bug with the power reporting and we don't handle it well, so sometimes you can end up with overreported values
10:33 karolherbst: _but_
10:33 OftenTimeConsuming: Via nouveau-pci-0100 under sensors. I'm getting 82W-85W power draw at pretty much idle now.
10:33 karolherbst: right...
10:34 karolherbst: sooo.. you probably have one of those three lane power sensors and we just add all three lanes together, but those lanes can overlap in what part of the GPU they report the power draw for
10:35 karolherbst: OftenTimeConsuming: also.. you can try to boot with `nouveau.config=NvPmEnableGating=1`
10:35 karolherbst: this should reduce power consumption of the GPU
10:35 karolherbst: but it might cause random bugs...
10:36 OftenTimeConsuming: I have the EVGA 'GHz edition 780', but I get the same with another ASUS 780 Ti.
10:36 OftenTimeConsuming: I'll add that flag to my already spicy list of boot time flags, thanks
10:37 OftenTimeConsuming: I guess I'll upgrade Linux and reboot.
11:04 OftenTimeConsuming: That reduces reported power consumption by 5-10W, but I guess that's better than nothing
11:04 karolherbst: yeah....
11:04 karolherbst: but then again, there is a bug with the reporting anyway
11:05 OftenTimeConsuming: So it's drawing like 30W actually?
11:05 karolherbst: unknown
11:05 karolherbst: I never had time to figure out what's wrong
11:05 karolherbst: but what I know is, that e.g. there can be three lanes, two in use, and one of those is for the entire GPU, the other for only a part, but we just sum them all together
11:06 karolherbst: so it might be 60W, or 50W or 40W or something
11:06 karolherbst: we might also have to do some calibration
11:07 karolherbst: it's sadly not the case on all GPUs
11:16 OftenTimeConsuming: Okay, seems to be working fine now.
11:22 OftenTimeConsuming: I was hoping minetest performance would be good too, but I guess there's still a culling issue.
11:25 OftenTimeConsuming: Thanks for all the help. I do wonder why I can't find out such details via a web search.
11:30 karolherbst: OftenTimeConsuming: after reclocking or just updating everything?
11:45 OftenTimeConsuming: Updating and reclocking, so shotgun surgery that ended up working.
11:49 OftenTimeConsuming: I been wondering, is the bug that makes taisei unplayable in the game or in nouveau? It does seem to use all the OpenGL features considering what the output looks like.
12:21 karolherbst: hard to tell without looking into it
12:21 karolherbst: OftenTimeConsuming: okay, so I guess the issue with mpv is simply that the GPU can't keep up on low clocks or something...
12:59 OftenTimeConsuming: I guess, its been working decently now.
12:59 OftenTimeConsuming: *it has
13:06 karolherbst: could always switch back to lower clocks and see if it starts happening again
13:06 OftenTimeConsuming: Okay, back to 07 power mode.
13:06 karolherbst: I had some very very WIP patches to get reclocking be done automatically, but uhh...
13:13 DodoGTA: karolherbst: So how can I explode my GPU? /s
13:18 karolherbst: yeah so my biggest concern there was, that I wanted to finish thermal throttling and other bits first :D
13:45 OftenTimeConsuming: karolherbst: Ran into the bug again in the default power mode; https://termbin.com/avu3 https://termbin.com/rqc4
13:45 karolherbst: mhh
13:46 OftenTimeConsuming: Happens after a "Audio/Video desynchronisation detected!"
13:46 karolherbst: yeah, so that's just happens when the context got reaped
13:46 karolherbst: errors in dmesg are more relevant here
13:47 OftenTimeConsuming: The latter link is the errors I got in dmesg
13:50 karolherbst: ohh...
13:50 karolherbst: I didn't see that one
13:50 karolherbst: mhhh
13:50 karolherbst: yeah.. so it can't keep it
13:50 karolherbst: OftenTimeConsuming: I suspect the "nv50cal_space: -16" errors are also less often/gone with higher clocks?
13:51 karolherbst: the other errors before that are a little concerning as those indicate either some memory corruption or we produce broken shaders in userspace
14:02 OftenTimeConsuming: I'll say it's the latter, as I'm using ECC RAM (although I'm not 100% sure it works, as I haven't got a reported memory error yet.).
14:03 OftenTimeConsuming: I've been testing with higher clocks for a while now and all seems fine.
14:03 karolherbst: ohh, I meant corruption in a sense of threading bugs or something
14:04 karolherbst: like data races and stuff. I fixed a bunch of those with 22.2, but I think more bugs are lurking, especially with vdpau, but I could never pinpoint anything
14:04 karolherbst: so maybe it's indeed just a performance problem
21:27 gfxstrand: dakr: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25444
21:27 gfxstrand: dakr: I've not tested it yet because I have a CTS run going
21:42 gfxstrand: dakr: Okay, I've poked about in GDB and proven to myself that it's doing the right thing. Also, dEQP-VK.api.command_buffers.record_many_draws_primary_2 passes on it and that's one of the ones that runs out. I checked manually and it now limits to 511, not 512.
21:43 dakr: Yes, that's intended.