09:51 zfnmxt: Hi. I'm trying to get nouveau + PRIME to work. Seems like xrandr can see the two cards fine: http://ix.io/1Lnm, and `xrandr --setprovideroutputsource nouvea Intel` adds a number of interfaces to the output of `xrandr`. Yet, when I try to activate the newly added `HDMI-1-1` interface (`xrandr --output HDMI-1-1 --auto`) I get no output.
10:00 karolherbst: zfnmxt: what's the status of the output?
10:01 zfnmxt: The status?
10:02 karolherbst: well, whatever xrandr is printing
10:02 karolherbst: disconnected/connected?
10:02 zfnmxt: I also just tried `xrandr --setprovideroffloadsink nouveau Intel` and then `DRI-PRIME=1 glxinfo` and it actually fails and says the nouveau driver can't be loaded :(
10:02 zfnmxt: karolherbst: Disocnnected.
10:02 karolherbst: mhhh
10:03 karolherbst: did you had the nvidia driver installed in the past?
10:03 zfnmxt: Yeah.
10:04 karolherbst: the nouveau driver not being able to be loaded is kind of messy :/ could be that the mesa drivers aren't correctly installed?
10:04 karolherbst: check what's inside /usr/lib64/dri/
10:04 zfnmxt: I'm able to get it to load when I switch my laptop to discrete graphics mode in the BIOS
10:05 karolherbst: there should be a nouveau_dri.so file
10:05 karolherbst: ohhh, mhhh
10:05 karolherbst: sure it's nouveau and not llvmpipe?
10:05 zfnmxt: I don't have /usr/lib64 :D
10:05 karolherbst: ufff
10:05 zfnmxt: I'm on NixOS so things are a bit funky wunky
10:05 karolherbst: ehhh, understood
10:06 zfnmxt: I do have a nouveau_dri.so file, though.
10:06 karolherbst: mhhh
10:06 karolherbst: LIBGL_DEBUG=1 DRI_PRIME=1 glxinof
10:06 karolherbst: ...
10:06 karolherbst: glxinfo
10:07 zfnmxt: and `lsmod` turns up nouveau too, if that's at all informative
10:08 karolherbst: mhh, that's expected, otherwise the xrandr stuff would have failed already
10:09 karolherbst: I am wondering why the mesa driver doesn't load :/
10:10 zfnmxt: http://ix.io/1Lnx
10:10 karolherbst: ahhh
10:10 karolherbst: yeah... I think I know what's up
10:11 karolherbst: zfnmxt: can you pastebin your dmesg output as well?
10:11 karolherbst: it's probably runpm messing up (we have a workaround/fix for it in the pipeline)
10:12 karolherbst: zfnmxt: you could try to boot with nouveau.runpm=0 and see if things starting to work then... but sadly the GPU is always on and battery lifetime will be bad
10:12 zfnmxt: http://ix.io/1Lnz
10:12 karolherbst: but maybe better than in dedicate only mode
10:13 karolherbst: yeah... the PCIe device is dead
10:13 zfnmxt: I'd really prefer for it to be dynamic. It's like 2 hours vs. 8 hours of battery life on my laptop :(
10:13 karolherbst: which is kind of the runpm bug we have
10:13 karolherbst: zfnmxt: uff, mhh, sure... but without compiling a new kernel you won't be able to use the nouveau gpu for now (except with nouveau.runpm=0)
10:14 zfnmxt: I'll try it, sec
10:19 zfnmxt: karolherbst: nouveau.runpm=0 didn't fix it :(
10:19 karolherbst: mhhhh
10:19 karolherbst: interesting
10:19 zfnmxt: How could I address it with a new kernel?
10:19 karolherbst: what laptops is it?
10:19 zfnmxt: Thinkpad X1 Extreme
10:19 karolherbst: lenovo p52 or something?
10:19 karolherbst: ahh
10:19 zfnmxt: Close :D
10:20 zfnmxt: I really wish they had just wired one port to the intel card =/
10:20 karolherbst: x1 is just a pimped p52 or something, no?
10:20 zfnmxt: P52s, I think
10:20 karolherbst: k
10:20 zfnmxt: But I'd say the p52s is the pimped one, x1 is cheaper more consumer-y version
10:21 karolherbst: yeah.. wiring all to the intel GPU usually makes that stuff much simplier
10:22 zfnmxt: I managed to get bumblebee to work with propietary drivers, and then you can pipe the output of the intel card using intel-virtual-output...but it was really laggy.
10:24 zfnmxt: I'm not sure if I have mesa, tbh.
10:29 karolherbst: zfnmxt: do you have the 2560 x 1440 display?
10:30 zfnmxt: karolherbst: No, it's 1920x1080.
10:30 karolherbst: but yeah.. with bumblebee things are a bit sucky.. although you shoul be able to meet the bandwidth in order to not fall that much behind the actual rendering
10:31 karolherbst: so if the game renders at 60fps it shouldn't be laggy
10:31 zfnmxt: No, it's just the output mirroring.
10:31 karolherbst: ohh mhhh :/
10:31 zfnmxt: All I care about is getting an external monitor to work, not doing any graphics intensive anything
10:31 karolherbst: ohhhh, that part
10:31 karolherbst: right.. that's annoying with bumblebee, true
10:32 zfnmxt: I've read that performance is better for that using nouveau with bumblebee
10:32 zfnmxt: But couldn't get that to work either so...
10:32 zfnmxt: Basically, nothing works :D
10:32 karolherbst: zfnmxt: mind sharing your dmesg booted with nouveau.runpm=0?
10:32 zfnmxt: Yeah, have to add the parameter back in again. Sec.
10:36 zfnmxt: http://ix.io/1LnM
10:37 karolherbst: heh
10:37 karolherbst: okay.. interesting
10:38 karolherbst: zfnmxt: and you said that in dedicated only mode the GPU is usable just fine?
10:38 zfnmxt: Yeah, works fine with nouveau.
10:38 karolherbst: mhhh, sadly this is the second bug we see on a few GPUs and it's more annoying to deal with as it involves signed firmware :/
10:39 karolherbst: but interesting that it works in dedicated only mode
10:39 zfnmxt: :(
10:40 karolherbst: skeggsb might know something
10:40 karolherbst: Lyude noticed this as well?
10:40 zfnmxt: Does nouveau let you control the power/performance of the GPU? One of my big gripes with going dedicated-only (when I was using propietary drivers) was that the GPU would constantly switch into performance mode and spin the fans up at the slightest load
10:41 HdkR: Just use Maxwell2+ to always be locked in to the best powersaving mode possible ;)
10:41 karolherbst: zfnmxt: not on pascal gpus
10:42 karolherbst: it's more or less locked down behind signed firmware we've not gotten yet
10:42 karolherbst: so even if we knew how to change the perf states, the hardware doesn't allow us to do it
10:42 zfnmxt: :(
10:42 karolherbst: yeah.. it's silly
10:42 karolherbst: started with the gm20x GPUs where we are not allowed to change the fan speeds without signed firmware......
10:43 karolherbst: but changing voltage and clocks? sure, that's fine...
10:44 HdkR: Theoretically getting more and more locked down after each generation. Maybe it'll eventually end up like adreno where you need a signed shader to kick the 3D engine out of secure mode :P
10:44 karolherbst: :D
10:44 zfnmxt: What about something like one of those cheapo USB-to-VGA adapters?
10:44 karolherbst: well, content industry doesn't care as long as they get what they request :p
10:44 zfnmxt: Could someting like that conceivable work?
10:44 zfnmxt: conceivably*
10:44 karolherbst: nvidia is just big enough so they can't just require anything
10:45 karolherbst: zfnmxt: mhhh, probably? no idea how those work internally
10:45 zfnmxt: Must have some sort of GPU type thing on them, dunno
10:45 zfnmxt: Guess I'l look around and use iffy bumblebee for now
10:45 karolherbst: zfnmxt: ohh wait, I remember that skeggsb was pushing out some changes regarding secboot
10:46 karolherbst: no idea if that has any effects on your gpu though
10:46 zfnmxt: Honestly, I'm guessing my GPU problems are likely due to incompetence on my part
10:46 karolherbst: https://github.com/skeggsb/nouveau/commit/31a497741dc43917b1a1608b05052da0faf0874e
10:46 zfnmxt: Basically everything involved right now is foreign to me, on top of whihc NixOS adds a layer of strangeness/complexity
10:46 karolherbst: no idea in what kernel those changes will land though
10:46 karolherbst: but should be "soonish"
10:47 karolherbst: 5.4 the latest I guess
10:47 karolherbst: but probably 5.3 or even backported
10:47 zfnmxt: Well I'll keep trying every now and then :D
10:47 karolherbst: zfnmxt: well, those are known issues you are running in, it's just messy to fix those as it's more a fight against the hardware
10:49 zfnmxt: Hm, seems like a USB adapter might actually work
10:50 zfnmxt: And would solve all my problems. Gonna try that.
10:50 zfnmxt: Thanks for your help, though, karolherbst :D
14:26 Lyude: zfnmxt, karolherbst: I believe I have seen that before actually, on one of my friend's Xaomi machines
14:26 Lyude: GP108
14:26 karolherbst: interesting
14:26 karolherbst: 1050ti is a gp107 afaik
14:27 imirkin_: zfnmxt: could just boot with nouveau.noaccel=1 -- should get the screens going, maybe
16:09 kreyren: Is it sane to use nouveau on GTX780m ?
16:12 karolherbst: kreyren: should be alright
16:14 kreyren: karolherbst, Currently having problems with optimus not switchning GPU correctly https://gist.github.com/Kreyren/d476876d29e1fec1db8226dc1b4789a2 more info?
16:14 kreyren: none was able to help so far and i suspect it beeing nouveau issue
16:15 karolherbst: kreyren: nouveau isn't loaded
16:15 kreyren: how do i load it?
16:15 karolherbst: it should load automatically
16:15 karolherbst: but maybe there is some blacklisting stuff going on
16:15 karolherbst: but you can always "modprobe nouveau"
16:16 karolherbst: but it's a 870m
16:16 karolherbst: but it should be fine as well
16:16 karolherbst: hopefully
16:19 kreyren: karolherbst, invoked `modprobe nouveau` and system halted, investigating
17:45 cyberpear: zfnmxt: I was able to get that card working w/ nouveau w/ the "off then on again" patch by karolherbst (I've got a P1, which is ~identical to the X1 Extreme)
17:46 karolherbst: ufff
17:46 karolherbst: surprising
17:46 karolherbst: but okay
18:12 zfnmxt: cyberpear: What's the "off then on again" patch?
18:20 zfnmxt: Setting "nouvea.noaccel=1" seems to have helped.
18:20 zfnmxt: xrandr now sees the connected HDMI cable, but it crashes if I try to activate an output.
18:21 imirkin_: pastebin xorg log
18:21 imirkin_: iirc it might require copy accel for reverse prime if you're using the nouveau ddx
18:21 zfnmxt: http://ix.io/1Lqn that's what I'm seeing right now
18:22 zfnmxt: Sec on the xorg log
18:22 imirkin_: DRI_PRIME=1 foo is not going to do anything useful
18:22 imirkin_: you've explicitly disabled acceleration
18:23 zfnmxt: http://ix.io/1Lqq
18:23 imirkin_: try uninstalling xf86-video-nouveau
18:23 imirkin_: er wait, you have an explicit xorg config?
18:24 zfnmxt: No. My xorg is generated by my OS.
18:24 imirkin_: if so, tell the "nouveau" one to use Driver "modeset"
18:24 imirkin_: well wtvr - whoever generates it ... tell that thing to use Driver "modeset" here.
18:24 zfnmxt: I'll try, it's actually not so simple to do so on my OS
18:24 imirkin_: ok
18:24 zfnmxt: Might have to modify the xserver package, sec.
18:24 imirkin_: well just uninstall xf86-video-nouveau -- perhaps that'll convince it not to do that...
18:24 zfnmxt: Yeah, I'll try modeset.
18:25 imirkin_: in a reverse prime configuration, xf86-video-nouveau does little good, and apparently is less tolerant of lack of accel
18:26 karolherbst: imirkin_: maybe it would make sense for us to probe that and bail if we have no accel enabled?
18:26 imirkin_: or just fix it...
18:26 imirkin_: i doubt it's difficult to do - just not a case that was considered
18:27 karolherbst: I think that's because we require shaders to run, don't we
18:27 imirkin_: not for reverse prime
18:27 karolherbst: ahhh, right
18:27 imirkin_: for reverse prime i'm sure we just use the copy engine
18:27 imirkin_: and for regular rendering, we support NoAccel just fine
18:27 karolherbst: yeah.. make sense
18:27 imirkin_: (falling back on ... whatever is the thing in X that does the software impl)
18:28 karolherbst: but do we actually have means to query the driver if accel is actually enabled? or should we just try to allocate a context and fallback to the NoAccel path if that fails?
18:28 imirkin_: we try to allocate an object and it fails.
18:28 karolherbst: that's probably what's already happening, no?
18:28 imirkin_: right
18:29 imirkin_: we just don't handle this scenario with reverse prime somewhere
18:29 karolherbst: should be fixable, I might just go ahead and try to figure that out
18:30 imirkin_: patches welcome =]
18:30 karolherbst: next month will be super busy though, so I gotta be fast :D
18:30 imirkin_: i expect it'd take me ~an afternoon of fiddling
18:31 karolherbst: yeah.. shouldn't take me too long either, just a lot of stuff going on right now
18:31 imirkin_: yep
18:31 imirkin_: i'm hoping i'll have HDR going by end of this month.
18:31 imirkin_: that should be a nice waste of time :)
18:31 karolherbst: apparently I managed to convince somebody to join us for an internship and now I have to take care of stuff and help the intern out starting next month :)
18:34 zfnmxt: It sorta works with modesetting! :D
18:35 zfnmxt: `xrandr --output HDMI-1-1 --auto` correctly shows my mouse cursor...and a bunch of corrupted gibberish as the background.
18:36 zfnmxt: I tried `xrandr --output HDMI-1-1 --same-as eDP1` (eDP1 is the internal display) and don't get a signal then.
18:36 imirkin_: check to see if there are any errors in dmesg
18:36 zfnmxt: http://ix.io/1Lqx since you know much better than me :)
18:37 imirkin_: somebody was talkign about issues with the intel ddx + reverse prime, although i assumed it would only happen with multiple reverse-primed monitors
18:37 imirkin_: that's all fine
18:37 imirkin_: can you try using modeset on intel as well, see if that makes a difference?
18:38 zfnmxt: imirkin_: I actually did that by accident before, but I wasn't able to issue a `xrandr --setprovideroutputsource` in that case because both gpus get the same name (namely, `modesetting`).
18:38 imirkin_: xrandr --setprovideroutputsource 1 0
18:38 imirkin_: that always works
18:38 zfnmxt: Oh.
18:38 zfnmxt: Okay, brb!
18:38 imirkin_: (almost always. you could do some really weird shit to make it not work. don't do that.)
18:42 zfnmxt: Now the external monitor displays a frozen image of what was on screen when `xrandr --output HDMI1-1 --auto` was run, with an updating mouse cursor again.
18:42 imirkin_: hm
18:42 imirkin_: i wonder if accel really is needed
18:42 zfnmxt: Boo :(
18:42 imirkin_: or something indirectly accel-related
18:42 imirkin_: that's lame =
18:42 imirkin_: =/
18:43 zfnmxt: Does that kernel parameter even matter if I don't even have the nouveau driver?
18:44 zfnmxt: i.e., I owuldn't get differnet reuslts if I removed the parameter and tried with modesetting again, right?
18:47 imirkin_: yes, it matters
18:53 zfnmxt: Yeah, didn't work with modesetting + no param. Startx just hung.
18:53 zfnmxt: Well, maybe I'll have better luck with that patch the guy with the P1 was talking about :)
18:54 zfnmxt: Thanks for your help, imirkin_
20:53 zfnmxt: karolherbst: Any idea what cyberpear was referring to with the "off then on again" patch?
20:54 karolherbst: zfnmxt: https://github.com/karolherbst/linux/commits/runpm_fixes
20:57 zfnmxt: karolherbst: Thanks, gonna try it :D
22:03 zfnmxt: karolherbst: The patch fixed `DRI_PRIME=1 glxinfo`
22:03 karolherbst: \o/
22:03 karolherbst: zfnmxt: even if you call it several times?
22:03 imirkin_: ideally offloading should work too
22:03 karolherbst: zfnmxt: did you boot with nouveau.runpm=0 still?
22:04 imirkin_: i mean output slaving
22:04 zfnmxt: Yeah, seems like it works.
22:04 zfnmxt: karolherbst: No I didn't
22:04 karolherbst: cool
22:04 karolherbst: it helps on my laptop as well, we had bad luck with a few other ones sadly
22:04 zfnmxt: `xrandr --setprovideroutputsource` still seems a bit kaput, doesn't show anyhting but my mouse again
22:04 imirkin_: hrmph.
22:04 karolherbst: the runpm stuff still works, but the secboot part still messes up
22:04 zfnmxt: ...is there any chance that could be due to my WM?
22:04 imirkin_: unlikely.
22:05 karolherbst: zfnmxt: but do external displays work?
22:05 karolherbst: normally you don't have to do any xrandr calls anymore
22:05 karolherbst: desktop set it up just fine these days
22:05 karolherbst: *desktops
22:06 zfnmxt: Oh, I'll try that real quick
22:07 zfnmxt: xrandr doesn't even see the HDMI port without --setprovideroutputsource still.
22:07 imirkin_: that's expected.
22:07 zfnmxt: Oh, maybe I'm confused based on what karolherbst said, then.
22:07 karolherbst: right.. but sometimes desktop environments set it up correctly
22:07 karolherbst: I think gnome does it
22:07 karolherbst: plasma might as well
22:07 zfnmxt: Ah, right. I just use xmonad, so none of that
22:07 imirkin_: yeah, sometimes the desktop environment will (effectively) run that
22:08 imirkin_: the fancy ones tend to
22:08 zfnmxt: Let me try running gnome, just to see if it works
22:08 karolherbst: yeah... makes sense that all desktop environments do that :p
22:08 karolherbst: but... would be nice to not having to do it at all
22:09 karolherbst: and with wayland it is even more annoying as compositors have to implement that feature as well
22:10 zfnmxt: I have no plans to move to wayland any time soon :D
22:15 zfnmxt: Gnome works.
22:15 zfnmxt: Must be something with xmonad.
22:16 imirkin_: are you maybe doing something weird?
22:16 zfnmxt: Aren't I always :P?
22:16 imirkin_: can you try xrandr --output HDMI-1-1 --auto --right-of eDP-1 or whatever?
22:16 zfnmxt: My xmonad config is pretty vanilla, though.
22:16 zfnmxt: I mean, I tried `xrandr --output HDMI-1-1 --same-as eDP-1`
22:16 imirkin_: try right-of.
22:16 zfnmxt: Shouldn't that just mirror things without issue?
22:16 imirkin_: should.
22:17 imirkin_: try right-of :p
22:17 zfnmxt: Alright, gotta switch back to xmonad!
22:22 zfnmxt: Well,it sorta worked. Right-off made it behave as if the monitor was to the right of the laptop display in terms of the mouse, but background was all corrupt and stuff still.
22:22 zfnmxt: Let me fiddle with my WM. Maybe have to do some special multi-monitor stuff.
22:22 imirkin_: hrmph.
22:22 imirkin_: odd. X shoudl just be making one big happy image.
22:23 hagbard: Hi, I have a Quadro P2000 and I'm trying to drive a pair of NEC PA272W's at 2560x1440. These displays do 2560x1440@60Hz over displayport. The first display always gets limited to 1920x1080, whereas the second works properly at 2560x1440. When I enable debugging, I see a message suggesting the first one is imposing a pixelclock limit or something. I've verified the EDID is being read correctly. Any thought
22:23 hagbard: s?
22:23 imirkin_: hagbard: yeah. "weird" :)
22:24 imirkin_: can you detail how these are connected to your GPU?
22:25 hagbard: A seperate display port cable to each LCD. One in DP-1, the next in DP-2. If I swap the cables, then affected monitor swaps as well.
22:25 imirkin_: perhaps cable is bad? DP requires "link training", so if we only link train to lowest level, that's not enough for that resolution
22:25 hagbard: Pardon, if I swap the monitors between DP-1 and DP-2, the affected one is the one connected to DP-1. If I switch to DP-3 and DP-4, DP-3 is affected/.
22:26 hagbard: The problem seems to affect the first discovered, active port.
22:26 imirkin_: what if you plug the DP-1 cable into DP-3
22:26 hagbard: I've tried swapping cables as well as swapping between the DP and mDP ports on the LCD.
22:26 imirkin_: and leave the DP-2 one in place
22:27 hagbard: Assuming DP-2 is still connected, then DP-2 is affected.
22:27 imirkin_: i see
22:27 hagbard: This is the message from dmesg:
22:27 hagbard: [ 6556.636027] [drm:drm_mode_prune_invalid [drm]] Not using 2560x1440 mode: CLOCK_HIGH
22:27 imirkin_: can you load nouveau with .... nouveau.debug=disp nouveau.debug=i2c nouveau.debug=aux
22:27 imirkin_: er, sorry
22:28 imirkin_: can you load nouveau with .... nouveau.debug=disp,i2c,aux
22:28 hagbard: is it alright if I unload noveau and modprobe it with debug=disp,i2c,aux or should I reboot?
22:28 imirkin_: reloading nouveau is possible, but be careful... let me give you a link to some instructions
22:29 imirkin_: hrmph. nouveau.freedesktop.org is down. :(
22:29 imirkin_: http://web.archive.org/web/20190503083132/https://nouveau.freedesktop.org/wiki/KernelModeSetting/
22:30 imirkin_: see "Deactivating KMS and unloading Nouveau"
22:30 imirkin_: you don't have to kill ttm/etc... just unbind the console, rmmod nouveau, insmod nouveau
22:31 zfnmxt: The nouveau driver should let me power off the nvidia gpu when I'm not using an external display, right?
22:32 imirkin_: zfnmxt: it should do this automatically
22:32 imirkin_: you can check /sys/something/vgaswitcheroo
22:32 imirkin_: it should say DynOff
22:32 imirkin_: /sys/kernel/debug/vgaswitcheroo
22:33 hagbard: Oh, one possible useful/unuseful detail - the nvidia binary drivers detect the displays correctly. I'm trying nouveau because I was getting strange errors from the nvidia driver when using OpenGL.
22:33 karolherbst: I usually check with cat /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status
22:33 imirkin_: hagbard: ok. good to know the hw is good.
22:34 zfnmxt: imirkin_: yeah, I know, but it's stuck on DynPwr :(
22:34 imirkin_: zfnmxt: is one of the outputs on? then it'll stay on
22:35 zfnmxt: imirkin_:Fresh xserver, didn't touch the outputs with `xrandr` yet and the HDMI cable is unplugged
22:35 imirkin_: merely being attached in X is not enough to keep it on.
22:35 imirkin_: did you boot with nouveau.runpm=0? :)
22:35 zfnmxt: Nope :(
22:36 hagbard: imirkin_: I've reloaded with the debug string, and there are two odd errors.
22:36 hagbard: [ 7205.925629] nouveau 0000:91:00.0: disp: 0x00005ed1[ ]: INIT_GENERIC_CONDITON: unknown 0x07
22:36 hagbard: [ 7221.308976] nouveau 0000:91:00.0: gr: intr 00000040
22:37 hagbard: Running debian 4.19.0-5-amd64
22:37 imirkin_: INIT_GENERIC_CONDITION is fine
22:37 imirkin_: that's fully expected
22:37 imirkin_: can you pastebin dmesg?
22:38 zfnmxt: imirkin_:uh, me or hagbard
22:39 imirkin_: hagbard: ---^
22:39 hagbard: imirkin_: Yes, presently. I'd like to reboot so it's not full of garbage.
22:39 imirkin_: sure
22:39 imirkin_: (watch it start working on reboot...)
22:40 hagbard: Well, that'd make my day if it did.
22:47 hagbard: imirkin_: Is it possible you meant nouveau.debug="disp=debug,i2c=debug,aux=debug" as described on https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ as the string you described above doesn't appear to elicit any extra debugging.
22:48 imirkin_: hagbard: =debug is implied
22:49 imirkin_: (i think? maybe not?)
22:49 zfnmxt: imirkin_:Hm, so it only goes to DynOff if I unplug my laptop :P
22:49 imirkin_: hagbard: hm, yeah. you'er right. have to stick the =debug's in. sorry :(
22:49 zfnmxt: From the AC adapter, that is.
22:49 imirkin_: zfnmxt: could be. this is all controlled by ACPI.
22:49 zfnmxt: That's how it behaves on Windows too.
22:50 zfnmxt: Okay, cool. All issues sorted except for Xmonad :D
22:50 zfnmxt: A good day of progress!
22:50 zfnmxt: It's still insane to me that some random patch from 2017 fixed the issue D:
22:50 zfnmxt: Thanks for your help, karolherbst and imirkin_ !!
22:51 karolherbst: well, that's the beauty of random patches
22:54 zfnmxt: karolherbst: I don't know anything about this stuff, but why haven't you submitted you submitted a PR (or whatever happens with linux) for the patch?
22:54 karolherbst: I did, but we have no idea why that works and if it has any negative impacts on other cards
22:55 karolherbst: and fixing something without having any understanding what the actual issue was is always a bad sign
22:55 hagbard: imirkin_: https://paste.debian.net/1087313/
22:56 zfnmxt: Aha, I see.
22:58 imirkin_: whaaa....
22:58 imirkin_: why are the bw requirements for the two heads so different?
22:58 hagbard: I have no idea.
22:58 hagbard: They're identical panels.
22:58 imirkin_: can you add drm.debug=0x1e
22:58 imirkin_: in addition to the other thing
22:59 hagbard: I'm curious if the BIOS/POST procedure is preconfiguring the heads somehow? I was considering rebooting with no monitors attached.
22:59 imirkin_: mmmmaybe, but for a secondary gpu, it wouldn't
22:59 imirkin_: although wait, it's primary
22:59 hagbard: Yes, it's the primary and only.
22:59 imirkin_: do you have fbcon disabled?
23:00 hagbard: No, I don't.
23:00 imirkin_: DRM: allocated 2560x1440
23:00 imirkin_: right, i was looking for that line. missed it somehow.
23:03 hagbard: https://paste.debian.net/1087315/
23:05 imirkin_: ok, so this is the problem
23:06 imirkin_: nouveau 0000:91:00.0: DRM: display: 4x162000 dpcd 0x11
23:06 imirkin_: perhaps related to drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -6
23:06 imirkin_: note how the second display has:
23:06 imirkin_: nouveau 0000:91:00.0: DRM: display: 4x270000 dpcd 0x11
23:07 imirkin_: unfortunately this is all well above my paygrade. skeggsb to the rescue! --^
23:09 hagbard: Interesting.
23:09 hagbard: imirkin_: good eye. Thank you.
23:09 imirkin_: it could be not waiting for the aux channel to actually come up when it should
23:10 imirkin_: it could be the monitor being out-of-spec-slow to respond, and by the time the first one times out, the second one is ready
23:11 hagbard: There are the messages earlier up about using a 40ms delay instead of 10ms on bus 0002
23:11 hagbard: pardon, "monitoring devices" must be like a hwmon chpi?
23:11 imirkin_: something like that, yeah
23:11 imirkin_: more generally, various i2c devices
23:12 imirkin_: i thought some of the dp-aux stuff came out as i2c
23:12 imirkin_: but there's other totally unrelated things that come out as i2c as well
23:12 hagbard: I have an idea. I have a third display here, I'll plug that in the first connector and reboot.
23:14 hagbard: Would you hazard drm_kms_helper's dp_aux_i2c_* variables might be worth fiddling with?
23:14 imirkin_: btw, note that even in a perfect world, nouveau's perf will be WAY below nvidia's
23:14 imirkin_: because we can't change gpu clocks, and it boots to lowest
23:14 imirkin_: mmmmaybe? i didn't kow those existed.
23:15 hagbard: Understood. And, with all respect, nvidia's driver has served me very well for years. But, at the moment, I don't need much acceleration, but I do need reliable 2D.
23:15 hagbard: parm: dp_aux_i2c_speed_khz:Assumed speed of the i2c bus in kHz, (1-400, default 10) (int)
23:15 hagbard: parm: dp_aux_i2c_transfer_size:Number of bytes to transfer in a single I2C over DP AUX CH message, (1-16, default 16) (int)
23:15 imirkin_: thing is ... modern 2D uses the 3D engine a lot
23:16 imirkin_: yeah, unfortunately i know nothing about the details of dp-aux
23:16 imirkin_: i know it's a sideband data channel... that's about it :)
23:17 hagbard: Using the nvidia drivers, I get a bucket of the following in dmesg along with X stalling for 20s:
23:17 hagbard: [514975.175461] NVRM: Xid (PCI:0000:91:00): 69, Class Error: ChId 0009, Class 0000902d, Offset 000008b0, Data ffffff8a, ErrorCode 00000004
23:17 imirkin_: ah yes, everyone's favorite, Xid errors
23:17 imirkin_: in the 2d class, no less!
23:18 imirkin_: on the bright side, it recovers :)
23:18 hagbard: the 902d class, no less.
23:18 imirkin_: 902d = nvc0+ 2d class
23:18 hagbard: I see.
23:18 imirkin_: https://github.com/envytools/envytools/blob/master/rnndb/graph/g80_2d.xml
23:19 hagbard: Do you mean 2D as in two-dimensions or is hexadecimal 0x2d?
23:19 imirkin_: (GF100_2D = 0x902d)
23:19 imirkin_: both =]
23:19 hagbard: DMA errors. Neat.
23:20 imirkin_: *97 = 3d, *2d = 2d, *c0 = compute
23:20 imirkin_: https://github.com/envytools/envytools/blob/master/rnndb/fifo/nv_object.xml#L190
23:20 hagbard: blit_dst_X
23:20 hagbard: oh, you're way ahead of me.
23:21 imirkin_: i've been playing this game a bit longer.
23:21 hagbard: I can tell; I'm impressed.
23:22 hagbard: What's the meaning of ChId?
23:22 imirkin_: i'm much better versed in the 2d/3d engine than in all this display gunk :)
23:22 imirkin_: probably channel id?
23:22 imirkin_: (what is a channel, you ask?)
23:23 imirkin_: it's basically a separate virtual memory "thing" ... iirc
23:23 imirkin_: which is also a holder for command submission, data objects, etc
23:23 hagbard: because what the world really needs, is more levels indirection?
23:24 imirkin_: well, these GPUs have evolved a bit since the voodoo2 days...
23:24 imirkin_: they're basically full computers which happen to be accessible via the PCI bus
23:24 imirkin_: they have their own VM, context switching, you-name-it
23:25 hagbard: I can imagine.
23:25 imirkin_: modern ones (like your pascal board) even allow VM faults to be handled by the CPU
23:26 imirkin_: so yeah. lots of indirection for everyone.
23:26 hagbard: Alright, well, this is novel. I plugged in 4k monitor as DP-1, and my regular two as -2 and -3. The 4k comes up correctly, the first of the pa272w gets limited, and the second is fine.
23:28 hagbard: here, I'll post a dmesg.
23:28 hagbard: I don't know if it matters, but these panels are kinda goofy. They do 30bit color among other things.
23:28 imirkin_: ohhhhhh
23:28 imirkin_: so ... we try to do 10bpc if we can
23:28 imirkin_: i wonder if that logic's a bit off
23:29 imirkin_: (i'm trying to do bringup of HDR, so it's likely i'll be mucking with those bits soon enough...)
23:30 imirkin_: some dp logic here: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/dp.c
23:33 hagbard: imirkin_: I had to use pastebin.com, https://pastebin.com/U31XZF9p
23:33 ajmitch: have a nice long weekend?
23:33 hagbard: imirkin_: It's odd that it only affects the first LCD, but not the second. It's like there's an un-cleared, uninitialized flag or something.
23:34 imirkin_: from that dmesg, actually looks like the third is affected
23:34 imirkin_: i.e. DP-3
23:34 imirkin_: what if, while it's running, you unplug the "broken" monitor and plug it back in?
23:35 imirkin_: anyways, i gtg. hopefully skeggsb will pipe up with some helpful words of advice.
23:37 hagbard: Wow.
23:38 hagbard: If anyone speaks ot imirkin when he gets back, he's brilliant.
23:39 RSpliet: yeah, he's a treasure
23:40 karolherbst: hagbard: might be that Lyude is able to help out with DP related issues as well
23:40 karolherbst: but yeah.. usually replugging the display helps to some degree