16:52 RyokoChan: wow - compared to compilation and installation of nouveau, the nvidia driver is quite ... time-consuming ... i'm still reading the manual which seems to consist of hundreds of pages. -_-
16:53 RyokoChan: I don't know yet, if the effort is worth it, but my kde installation tends to freeze when gui-interaction is done, and I wanted to check, if it happens too with the vendor's drivers, to rule out nouveau or kde
18:00 alohanouveau: Hello, is this an appropriate place to seek help with installing/configuring nouveau?
18:39 omegatron: just ask your question ..
18:39 omegatron: you don't need to ask, if you can ask
18:39 omegatron: in the case noone can help you (right now), you simply won't get any answer
18:41 alohanouveau: Thought that if this is a dev channel a support request might be inappropriate here.
18:42 alohanouveau: I've posted a question on U&L if anyone can help, there's plenty of info about my issue on there
18:42 alohanouveau: https://unix.stackexchange.com/questions/685509/very-bad-performance-choppy-ui
19:14 karolherbst: alohanouveau: nouveau is already installed by default (in most distributions) you just need to tell the driver to use a different GPU than your integrated one
19:15 karolherbst: "DRI_PRIME=1 glxinfo" should make it use the nvidia GPU
19:18 hell__: alohanouveau: you most likely have a laptop with Nvidia Optimus
19:19 alohanouveau: karolherbst
19:19 alohanouveau: $ DRI_PRIME=1 glxinfo | grep -i opengl
19:19 alohanouveau: nvc0_screen_create:1046 - Base screen init failed: -19
19:19 alohanouveau: libGL error: failed to create dri screen
19:19 alohanouveau: libGL error: failed to load driver: nouveau
19:19 hell__: er, forget about it, looks like you have a desktop?
19:19 alohanouveau: Yeah I'm on a desktop that's about 5y old
19:20 alohanouveau: The card is Nvidia gtx 1050
19:20 hell__: ah, I wonder why the iGPU is still enabled
19:23 hell__: with all the monitors plugged into the GTX 1050 and the Intel iGPU disabled, you should just need to tell the OS to use nouveau
19:24 alohanouveau: How do I do that? When I disable the integrated graphics anything that requires the slightest of graphics processing becomes barely usable right now.
19:25 hell__: right, because it's using llvmpipe
19:25 hell__: (software rendering)
19:25 alohanouveau: Indeed, I'm trying to figure out how to tell it not to
19:26 hell__: so debian has this about the proprietary nvidia drivers, but I can't find anything about nouveau itself: https://wiki.debian.org/NvidiaGraphicsDrivers
19:26 alohanouveau: Or find out why it's doing that, which should essentially lead me to the solution of the problem.
19:27 hell__: if you've tried the proprietary drivers before, I'd re-check the uninstallation section
19:28 alohanouveau: On this instance I haven't.
19:28 hell__:has no idea how to use debian
19:29 alohanouveau: I am running a "dual-boot" system with both disks having Debian 11, on the second one, which I use for testing and stuff, I have installed the proprietary drivers.
19:30 alohanouveau: I'm trying to keep my main OS clean and I'd love it if I can get nouveau to function as supposed.
19:32 karolherbst: alohanouveau: mind sharing the output of "dmesg"?
19:33 karolherbst: I suspect that nouveau is loaded, but something goes wrong. Like missing firmware or some other weirdo bug
19:34 karolherbst: hell__: some firmware allow you to configure the graphics settings
19:34 alohanouveau: Ok there are some errors
19:34 alohanouveau: https://pastebin.com/raw/msqdJLUG
19:34 karolherbst: I especially got a firmware like this, where you can have intel or a discrete one the main thing
19:34 karolherbst: and disable/enable intel for display offloading
19:35 karolherbst: alohanouveau: ahh yeah, you need the signed firmware, it's usually installed through linux-firmware and added to a initramfs automatically
19:36 hell__: karolherbst: yes, on a desktop it should be possible to just disable the Intel iGPU. on laptops with muxless Optimus it's not doable because the iGPU is the one driving the displays
19:37 karolherbst: hell__: there are even laptops where you can disable the iGPU
19:38 hell__: but that's when there's physical multiplexers so that the video outputs can be driven from the dGPU itself
19:38 hell__: muxless = no muxes (multiplexers)
19:38 karolherbst: well.. some laptops only wire external ports to the dGPU, and just mux the internal display
19:38 hell__: usually high-end gaming laptops or workstations where optimus cripples the performance too much
19:39 karolherbst: with USB-C it gets even stranger, where external ports might be driven by the dGPU, but USB-C DP ports by the iGPU
19:39 alohanouveau: karolherbst how can I get that signed firmware? I'm not a very advanced linux user, I apologize if what I'm asking is common knowledge.
19:39 karolherbst: alohanouveau: normally your distribution should have everything in place
19:40 karolherbst: unless you use a libre kernel or something
19:40 hell__: alohanouveau: probably `firmware-misc-nonfree` if the debian documentation is correct
19:40 alohanouveau: well apparently something got messed up, I suppose I should seek help from the debian guys then?
19:40 karolherbst: yeah.. sounds like a good idea
19:40 hell__: ^
19:41 alohanouveau: but I'm trying to avoid adding nonfree packages
19:42 alohanouveau: isn't that the whole purpose of foss drivers
19:42 karolherbst: alohanouveau: yeah... I understand
19:42 karolherbst: but the firmware has to be signed
19:42 karolherbst: and we don't know the key
19:42 karolherbst: soo...
19:42 hell__: think of it this way: with the proprietary nvidia drivers, you have even more nonfree stuff
19:43 hell__: because the firmware is still needed
19:43 hell__: full disclosure (not that it's a secret though): I'm just a firmware developer who forgot how they've ended up here
19:43 karolherbst: all I am saying is, we don't have much of a choice here :/
19:44 alohanouveau: well if I get it running I can just remove nonfree from sources, I doubt I'll need firmware updates anyway
19:44 karolherbst: yeah... those updates are quite rare indeed
19:45 karolherbst: they do happen though in case nvidia messed up and shipped outdated or buggy firmware
19:45 karolherbst: here you see the history of changes: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/nvidia
19:45 karolherbst: not many and overall just hw enablement
19:46 alohanouveau: well, rebooting - hold your breath :D
19:46 hell__: things are much worse on the pre-OS side
19:46 karolherbst: ...
19:47 karolherbst: I just wanted to say that a simple reboot doesn't do much if the initramfs isn't regenerated
19:47 karolherbst: but maybe apt is smart
19:47 alohanouveau: $ glxinfo | grep -i opengl
19:47 alohanouveau: OpenGL vendor string: nouveau
19:48 alohanouveau: wohoo
19:48 karolherbst: yay
19:48 hell__: nice
19:48 alohanouveau: Thank you! I'll make sure to mention you on U&L for what it's worth :D
19:51 hell__: as a coreboot dev, the binary situation of the GTX 1050 reminds me of the state of coreboot on sandy/ivy bridge: coreboot can run a blob that does RAM init or use a native, open-source RAM init implementation (which is pretty decent, but not perfect); in either case, one still needs to have Management Engine firmware in flash
19:53 karolherbst: hell__: that manamgenent stuff is really scary.. we use it to remotely hard reset machines for driver development :D They even put a VNC server into it with direct framebuffer access...
19:54 hell__: but that's only in the "large" firmware type, the one shipped with "vPro" machines
19:54 karolherbst: ehh, no
19:54 karolherbst: laptops have that as well
19:54 hell__: which laptops?
19:54 karolherbst: normal ones
19:55 karolherbst: not sure if it's limited to ones with Xeon CPUs, but we do use it on laptops
19:55 karolherbst: and those are just "normal" ones
19:55 karolherbst: not sure if it started with a certain gen or not
19:55 hell__: even if not branded as such, ThinkPads have this firmware type
19:55 karolherbst: hell__: ahh.. yeah
19:56 hell__: they're "business" laptops
20:00 hell__: but as a coreboot dev, I much prefer trying to improve RAM init code, because it's something I can easily do
20:01 hell__: even though RAM init is insanely complex, ME firmware is signed and there's no documentation on what it does: good luck replacing that
20:01 karolherbst: be happy you don't have to be able to change RAM clockings on the fly :D
20:01 hell__: oh, this is a thing since skylake
20:01 karolherbst: oh wow
20:02 karolherbst: like the full dynamic thing or just two/three clocks to choose from?
20:02 hell__: just a few fixed frequencies
20:03 hell__: RAM is trained at two (or even more in newer platforms) different frequencies and all the training results are saved, so that the memory controller hardware can later switch the frequency on the fly
20:03 karolherbst: okay.. sadly I don't know how that works on newer Nvidia GPUs, but I think they went the full dynamic way now...
20:04 hell__: no idea how RAM init on GPUs is handled, but it certainly sounds interesting
20:04 karolherbst: well.. I guess similiar, we get a vbios with tables and according to them we have to figure out which registers set to what :D
20:05 karolherbst: the problem really is changing it while stuff still accesses it though
20:05 karolherbst: because you still want your display to display stuff even though the VRAM controller was "paused"
20:05 karolherbst: I am actually wondering how that works with the CPU
20:05 hell__: yeah, on Intel memory controllers this is all taken care of by the hardware itself
20:05 karolherbst: is just enough stuff put into L2/L3 cache?
20:06 hell__: no idea how the underlying implementation works, but I'm pretty sure there's caches involved
20:06 karolherbst: hell__: well on GPUs it's done by firmware mostly, but for older gens we had to write the firmare ourselves and on newer gens we need signed firmware we don't have
20:07 hell__: ah, when I say hardware I mean that the thing doing the frequency changes is a state machine
20:07 hell__: but the thing that decides *when* to change the frequency is firmware
20:07 HerrSpliet: Yeah, novueau is lacking the configuration of exactly one cache to make this work nicely. IIRC it's called (or used to be called) the NISO buffer, and it's used to cache pixels from DRAM to scanout logic.
20:07 karolherbst: on nvidia GPUs there is a line buffer where you just store enough data so that you can still scan out.. we never really figured it out
20:07 RSpliet: We never figured it out indeed, but tbh... I also never really really tried.
20:09 hell__: on the CPU side we don't need to worry about runtime frequency changes, but the RAM training is much more complex
20:09 karolherbst: yeah...
20:09 RSpliet: hell__: RAM link training happens on NVIDIA too. For some chips it's done by firmware, but I think for the majority there's dedicated hardware that you give a training pattern and say "go"
20:10 karolherbst: I did some experiments on the GPU and I was able to change core clockings over 1k times a second without userpsace even noticing
20:10 karolherbst: well.. perf was a bit volatile
20:10 hell__: wow
20:10 karolherbst: but not _bad_
20:10 karolherbst: so it avg. around the difference in clocks
20:10 karolherbst: yeah... changing clocks for the cores is done within ns
20:10 RSpliet: Sure, setting a PLL takes like 50 microseconds
20:11 RSpliet: Worst-case
20:11 karolherbst: I just wanted to say...
20:11 karolherbst: 50 us counds a bit slow
20:11 karolherbst: *sounds
20:11 karolherbst: but I think we also never really wait until the PLLs to lock?
20:12 RSpliet: I hope we do
20:12 karolherbst: yeah.. no idea :D
20:12 hell__: I hope so too o_O
20:12 RSpliet: I definitely wrote code that does
20:12 karolherbst: all this reclocking code in nouveau is more or less best effort anyway
20:12 karolherbst: RSpliet: yeah... I think you did
20:12 karolherbst: question is, did it actually land?
20:13 karolherbst: and do you want to find out? :D
20:13 RSpliet: I was just looking to see if I can find the NVAA code back
20:13 hell__: RSpliet: similar thing with Intel memory controllers: before Sandy Bridge, firmware would send DRAM commands by setting some bits in the memory controller and using MMIO reads/writes. From Sandy Bridge onwards, there's this state machine where you can tell it to run sequences of several "run this DRAM command with these parameters this many times" subsequences, and also handles error
20:13 hell__: checking
20:14 karolherbst: yeah..
20:14 karolherbst: with all the firmware stuff going on, people often don't see that there is a real benefit of doing it in firmware
20:15 hell__: to this day, x86 firmware still does RAM training on Intel hardware, even if it's with the help of the hardware
20:16 hell__: since AMD Zen, it's the PSP firmware (signed blob) that does RAM init, so RAM is already working when the x86 cores are released from reset. of course, I hate it
20:16 RSpliet: I'm going to go out on a limp and say that the nvkm_rd32() on https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/clk/mcp77.c line 356 checks whether the PLL locked
20:17 karolherbst: RSpliet: sure, but it doesn't check if the lock bit is set, doesn't it?
20:18 hell__: which is the lock bit?
20:18 RSpliet: hell__: all good questions. The answer lies somwehere in envytools (and sadly, no longer in my head)
20:18 hell__: maybe register 0x4080 is a read-only "PLL status" register
20:18 karolherbst: RSpliet: I know that you wrote some patches to check that somewhere
20:19 hell__:looks up envytools
20:20 RSpliet: hell__: here's the prettiest-picture I got
20:20 hell__:gets startled by https://github.com/envytools/envytools/commit/946d711370af2bea4b2add957de965e3b8115b7c
20:20 RSpliet: https://envytools.readthedocs.io/en/latest/hw/pm/gt215-clock.html
20:20 hell__: wait, this is someone I know from elsewhere
20:20 karolherbst: hell__: usually goes by by being a cat or so I heard on twitter
20:23 mwk: meow?
20:24 RSpliet: from now on I shall read your nickname as meowk
20:25 mwk: hm
20:25 hell__: oh hi there
20:25 karolherbst: mwk: I am now actually confused if this was your intention all along or if you just assume it always was
20:26 mwk: it was not
20:27 RSpliet: mwk: you still in the "business" of REing FPGAs?
20:27 mwk: ... kind of
20:28 mwk: currently in the business of having my identity completely broken
20:28 karolherbst: mwk: still the same problem? :/
20:29 mwk: not quite sure mwk survived the process
20:29 mwk: ... I should get rid of that nickname at some point, perhaps
20:29 RSpliet: Ouch, yeah I heard it can take its toll on one. I hope you're making some progress, best of luck...
20:30 hell__: ouch, best of luck!
20:30 mwk: well, yeah
20:31 mwk: finding out you're not the first or only person to be occupying your body tends to have some funny effects on your identity
20:31 mwk: so does finding out about the reasons
20:31 hell__: I can imagine
20:34 karolherbst: mwk: I hope others are not making a bigger deal out of it than it actually has to be, best of luck and everything
20:36 mwk: well
20:36 mwk: I did end up breaking some relations
20:36 karolherbst: :/
20:37 mwk: long overdue
20:37 karolherbst: can be exhausting still
20:37 mwk: very