03:22damo22: im on Rocky Linux 8.5, https://paste.debian.net/plain/1237190 any idea what causes this? when i try to enable the display in X
03:40imirkin: damo22: "some kind of display problem"
03:40imirkin: damo22: looks like a 4k display, not that this should be an issue. how is it connected? DisplayPort i presume since it's GK107?
03:40damo22: DP over dock
03:41damo22: i tried a few different resolutions and none work
03:42imirkin: once it's stuck, the dream is over
03:42damo22: but its intermittent, sometimes i reboot and everything works
03:42imirkin: so ... at some point ... we added large cursor support
03:42imirkin: and it didn't work well on kepler iirc
03:42imirkin: it was then fixed
03:42imirkin: but i have no idea whether the kernel you have has the bug and/or the fix
03:43damo22: yea redhat keeps backporting random fixes iiuc
03:43imirkin: although iirc that issue wasn't a hang
03:43imirkin: it was just a messed up curosr
03:43damo22: is it possible for me to build latest nouveau out of tree?
03:43damo22: would that work?
03:43imirkin: there were also some issues where we'd try to do things that weren't super-supported
03:44imirkin: out-of-tree nouveau is directly linked to a particular kernel version
03:44imirkin: you can't build it against a random tree
03:44damo22: thats annoying
03:45damo22: its that because the internals keep changing?
03:45damo22: unrelated to nouveau
03:45imirkin: so usually it'll work against a range of versions
03:45imirkin: but that range is in no way documented
03:45imirkin: or apparent
03:45damo22: can i build a whole kernel that is known to work?
03:45imirkin: i don't think such a kernel exists ;)
03:46damo22: i dont recall having any issues on my x230
03:46damo22: it was intel not nv
03:46damo22: thats why probably
03:46imirkin: i guess having a full time team _does_ lead to better results
03:48imirkin: vs nouveau
03:49damo22: yeah i meant sorry i pointed that out
03:49imirkin: nah, it's cool
03:49imirkin: well-known situation :)
03:49damo22: bloody kernel keeps changing
03:50damo22: cant they agree on a stable internal api?
03:50imirkin: short answer: no :)
03:50imirkin: long answer: nope!
03:51imirkin: yes ... because microkernel somehow makes people design better interfaces
03:51airlied: just put graphics drivers in userspace :-P
03:52damo22: no, because if a piece is broken fix just that piece
03:52imirkin: airlied: i thought we did
03:52damo22: airlied: thats what i plan to do with Hurd
03:53imirkin: damo22: ah yes, because one person without the detailed technical expertise can achieve what those silly dedicated teams can. the power of the microkernel!
03:54damo22: maybe, i mean, i got disk to boot with no expertise in AHCI
03:55damo22: if you can fit pieces together in userspace its very powerful
03:57imirkin: i wrote an IDE ATA controller in VHDL. this graphics stuff is a bit different :)
03:57damo22: if the interfaces are not changing, you can focus on adding new support instead of refactoring borken apis
04:00imirkin: it's a nice theory
04:00imirkin: the reality is that we leverage various shared libraries
04:00imirkin: whether they're in kernel or in userspace
04:00imirkin: those libraries evolve with the usage
04:00imirkin: the only thing is that userspace enables dll hell, while kernel doesn't
04:01damo22: statically linked binary driver in userspace :D
04:02imirkin: just because it's statically linked
04:02imirkin: doesn't mean it's not dll hell
04:02imirkin: you have diff drivers using diff versions of the same lib
04:02imirkin: which effectively negates the advantage of sharing
04:03imirkin: the advantage isn't some sort of memory reduction
04:03imirkin: it's the sharing of effort to make features happen
04:04damo22: i refuse to use binary driver from NV
04:04damo22: i will rather make do with less monitors
04:05damo22: until the bugs are squashed :D
04:13imirkin: damo22: also keep in mind that 4.18 is a whole ... 1.0 off current
04:27damo22: redhat ports tonnes of stuff back to old kernel versions
04:42damo22: i switched to a longterm supported kernel in elrepo on 5.4 and its working
05:26damo22: now i hit a new unrelated problem that my laptop overheats and shuts down when i use the display lol, i will need to check thermal paste
05:47imirkin: mmmmm paste
05:48imirkin: damo22: on kepler you can adjust clocks
05:48imirkin: if it's a laptop, chances are the fans are controlled by the EC
05:48imirkin: and it's meant to have various logic to clock down which we don't plug into
05:48imirkin: you can access this via /sys/kernel/debug/dri/0 (or 1)/pstate
13:54graphitemaster: so what's the verdict on the latest l4t nvidia opensource kmd?
13:54graphitemaster: anything of value in there
14:00karolherbst: graphitemaster: what do you mean?
14:17Draceus: Anyone here able to help me out? Im using nouveau on popos since Im on an older gpu (gtx 570) and Im getting terrible performance. I would describe the experience as choppy
14:21imirkin: i think that's expected
14:21imirkin: esp if you're trying to use a 'modern' desktop
14:23karolherbst: Draceus: yeah... we can't change the clocks on those GPUs and fermi is one of hte gens where GPUs just boot with crappy clocks
14:23karolherbst: Draceus: do you know if wayland or Xorg is used?
14:23imirkin: the higher-end GPUs esp boot with very low clocks
14:23imirkin: the lower-end GPUs actually end up faster ;)
14:23karolherbst: oh really
14:23imirkin: (for fermi)
14:23Draceus: Ok thanks for the answers. I'm not sure to check if Im using wayland or xorg. How to I check this?
14:24karolherbst: ps aux | grep X
14:24karolherbst: if XWayland or nothing besides the grep shows up you run wayland
14:25Draceus: Got a bunch of information
14:25karolherbst: ehhh.. right.. you might have other processes with X in the name
14:25karolherbst: something like X11 or Xorg in that list?
14:26imirkin: i prefer 'xrandr' -- if the displays are called XWAYLAND
14:26Draceus: yeah its xorg
14:26imirkin: then you have wayland
14:26karolherbst: imirkin: ohh, true
14:26imirkin: if they're called something reasonable (e.g. DVI-I-1 or DP-1 or whatever) then you have xorg
14:26imirkin: but it's also not a question i really have to ask myself too often
14:26imirkin: so i dunno what the preferred way to check is
14:27Draceus: Pretty sure its xorg then I cant see anything about wayland and I see xorg
14:27karolherbst: yeah.. on X11 I am not sure what could improve perf, I got the feeling that using modesetting or nouveau DDX is faster than the other, but I didn't really benchmark it :) I just now there is a difference
14:27imirkin: Draceus: anyways, if you use plain X with a plain window manager, you should be fine. if you're using gnome/kde/etc, you're in for a bad time
14:27Draceus: imirkin: Yeah I guess Ill have to just deal with the terrible performance
14:27karolherbst: disabling effects helps
14:28imirkin: definitely the nouveau ddx will do much better, but won't help if you're using a heavy wm
14:28karolherbst: imirkin: I wouldn't say that :p
14:28karolherbst: I am sure modesetting is actually faster, but I have no numbers to back it up
14:28karolherbst: _but_ it could depend on how gnome is using glamor
14:28karolherbst: I just know there is a difference
14:29karolherbst: well, for sure
14:29imirkin: with under-clocked GPUs, blits become much more expensive
14:29karolherbst: right, but it wouldn't be surprising if modesetting + glamor is more optimized than the nouveau ddx
14:29karolherbst: but yeah...
14:29karolherbst: maybe it also depends on the GPU and everything
14:30imirkin: with nouveau ddx, we just render directly to the linear surfaces
14:30karolherbst: trying out the other one might be a valid thing to try
14:30imirkin: which ideally are scanned out
14:31karolherbst: "grep -i nouveau /var/log/Xorg.0.log" to check what's used?
14:32karolherbst: Draceus: anyway, what you could try out is either removing or installing the nouveau ddx, but not sure what is used on your system and no idea how the packges are called on your OS
14:33Draceus: karolherbst: Gotcha, I think Ill just stick with what it is for now since there seems to be no clear way to fix it. Thanks everyone!
14:34karolherbst: yeah well.. somebody could reverse engineer it and implement changing clocks and all that, but that's usually work for like a month or two
14:36Ermine: ... and requires skills
14:36imirkin: karolherbst: well, skeggsb has a branch that doesn't work (for me) :)
14:36imirkin: i think a month or two is _way_ optimistic
14:36imirkin: maybe if you were doing it full time and had ready access to a lot of hw
14:37imirkin: (and were intimately familiar with what you were doing)
14:42graphitemaster: karolherbst, https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Kernel-Driver-Source
14:45imirkin: graphitemaster: in the past, it has been useful for documenting error conditions
14:45imirkin: since those tend to be the same across GPUs
14:45karolherbst: imirkin: this is something else though
14:45imirkin: otherwise it's not particularly helpful
14:46karolherbst: currently looking at it
15:05omeringen: is there a filled bug about gf108m bug about wayland+nouveau ? I want to bookmark and track the progress.
15:05karolherbst: graphitemaster: yeah soo.. it looks like _some_ bits are there, but it's limited to tegra devices
15:09graphitemaster: oh noes they got 'em
15:09graphitemaster: wew back, thought the nv mafia severed ur internet
15:10graphitemaster: i've been lookin' through it mainly for power state stuff, can't find anythin'
15:10imirkin: omeringen: a singular bug about it? no
15:12omeringen: @imirkin, i talked with someone (probably @karolherbst) long time ago and told me that it's related to kernel. Then he was looking for a gf108m graphics card as far as i remember.
15:12omeringen: here is my logs and system specs: https://drive.google.com/drive/u/0/folders/19kBULZ3OKNISdoFBkmCF66uqq4vLwVI5
15:13omeringen: there are random crashes with wayland + nouveau and it still exists on 5.17 kernel
15:14imirkin: do you remember approximately what he said the problem was about?
15:15omeringen: no, i need to dig online logs :D gonna take some time
15:16imirkin: there was definitely an issue which could cause random sadness
15:16imirkin: which has been fixed in recent times
15:16imirkin: pretty sure 5.17 would have the fix though
15:16imirkin: karolherbst: when did the super thing land?
15:16karolherbst: uhh sometime and it got even backported
15:17karolherbst: but not sure how far
15:17karolherbst: let me check
15:20omeringen: currently exists on Linux arch 5.17.1-zen1-1-zen
15:21imirkin: omeringen: ok. you were getting the "ce init" issue
15:21imirkin: that should def be fixed
15:21imirkin: can you pastebin your dmesg?
15:22karolherbst: ehh that ce init thing...
15:23karolherbst: yeah.. current logs from 5.17 would be very helpful here
15:24omeringen: i am not at home right now, gonna send them to you 7 hours later probably
15:24karolherbst: that's fine
15:29omeringen: see you later, thanks
22:22omeringen: i'm back !
22:24omeringen: system is completely freezing, i am not sure if log shows the issue or not.