00:36 rhyskidd: karolherbst: a big thank you for your work getting gp107 runpm patches upstream. booting cleanly with 5.7 mainline now!
01:00 shadow: imirkin: I've borrowed a DP->HDMI cable to test with, so far it is not any better looking than DP cable
01:00 shadow: imirkin: still very blue
01:01 shadow: if the colors would be correct I think it might be usable
01:21 imirkin: passive or active?
01:22 shadow: imirkin: passive I think it's a single cable nothing else to it
01:22 imirkin: hrmph
01:22 imirkin: hdmi should be much simpler
01:22 imirkin: perhaps we're not driving the anx9805 chip correctly
01:23 imirkin: or perhaps it's actually an active cable
01:23 imirkin: they don't always require separate power
01:25 shadow: imirkin: this thing https://www.amazon.com/Anbear-Displayport-DisplayPort-Desktops-Displays/dp/B01EY67S6O
01:31 imirkin: shadow: wow, they really don't go into a lot of detail
01:31 imirkin: DisplayPort (DP, DP++, DisplayPort++) -- that would suggest that it's an active cable
01:31 imirkin: since normally only DP++ ports support the passive thing
01:31 imirkin: otoh, could be that their description is imprecise
01:31 imirkin: and they're just trying to get search matches
01:32 imirkin: shadow: should be able to tell by looking at the EDID
01:32 imirkin: shadow: can you run 'xrandr --verbose' and pastebin when using that cable?
01:36 shadow: imirkin: https://gist.github.com/eshattow/9ac5c82fe6905b3689a171ed6aa38945
01:38 imirkin: ok, looks like legit hdmi.
01:39 imirkin: shadow: it looks like it's using a doublescan mode??
01:39 shadow: imirkin: this is what it looks like https://i.imgur.com/PmOFGwU.jpg when I did the xrandr command
01:39 imirkin: shadow: can you try running xrandr --output DP-1 --rate 60
01:40 imirkin: yeah, it has a f'd up modeline
01:40 shadow: imirkin: tried, no visual change
01:40 imirkin: it's f'd for multiple different reasons
01:40 imirkin: how about --rate 50
01:40 shadow: nope
01:41 imirkin: hwo about xrandr --output DP-1 --mode 0x4ae
01:41 shadow: that made the screen do something
01:41 imirkin: anything good?
01:43 shadow: imirkin: now it looks like https://i.imgur.com/Q5WzBay.jpg
01:43 imirkin: looks perfect
01:44 imirkin: just get some red glasses
01:44 shadow::P
01:44 imirkin: was the screen irradiated with heavy-duty radiation of some sort to give off that healthy blue glow? :)
01:45 imirkin: i'll be honest -- never seen anything like that before
01:45 imirkin: my GUESS is that there are some settings in the screen which you can adjust to make it look normal
01:45 imirkin: something to do with color modes, etc
01:45 shadow: :) nice joke. Raspberry Pi 4 seems to drive it okay via HDMI, so if you need info from some computer that is connected and driving it I have that.
01:45 imirkin: we SHOULD be sending an infoframe, but chances are pretty good that this doesn't work with the PIOR situation
01:46 imirkin: skeggsb: does that sound like a plausible explanation?
01:47 skeggsb: my guess is it's the removal of clock doubling that's causing the blue
01:47 imirkin: skeggsb: or would you expect the infoframe we set via hdmi regs to make it to the pior?
01:47 skeggsb: i was trying to find my notes from when i first wrote it, but those appear to be long gone
01:47 imirkin: skeggsb: but why was it showing stupid doublescan modes in the first place?
01:47 skeggsb: *shrug*
01:47 imirkin: i'm sort of assuming that shadow didn't manually add those
01:48 imirkin: skeggsb: oh, you mean my patch? heh
01:48 imirkin: shadow: try a kernel without my changes
01:48 imirkin: shadow: skeggsb's claim is that my patches are bogus. i wouldn't necessarily disagree :)
01:49 skeggsb: well, we still need to handle rejecting the too high clocks after doubling etc too :P
01:49 skeggsb: i really don't know why that doubling is there, but it *was* needed, and nvidia do it
01:49 imirkin: oh, is that what happens
01:49 imirkin: we double "too late", after the *= 2?
01:49 imirkin: er
01:49 imirkin: we check clock before doubling
01:49 skeggsb: yeah, i think mode_valid() happens before that
01:50 imirkin: right
01:50 imirkin: and PIOR is restricted to 165mhz (330mhz effective)?
01:50 imirkin: i could believe that.
01:51 imirkin: probably a single link-type situation
01:51 imirkin: plausible.
01:51 imirkin: shadow: er wait, you still need one of my patches
01:52 imirkin: shadow: i think you need https://github.com/imirkin/nouveau/commit/bcd1d5f2d44876a88fde59e634a37db5d95ea7f7
01:52 imirkin: skeggsb: so that nva0 was literally the only PIOR you ever personally ran into?
01:52 shadow: interesting. It has those weird slowdowns but I'm able to change to Single Display on the BenQ and it's working in color
01:52 skeggsb: imirkin: yep, it's *stupidly* rare
01:52 imirkin: shadow: try it with just that one patch, see if it helps
01:53 shadow: different kernel version to be clear, okay will be some minutes to compile and try
01:53 skeggsb: the PIORs themselves are used for other stuff more commonly, but, for external TMDS/DP encoders, rare
01:53 imirkin: skeggsb: well, looks like the Dell Precision M4600 (going from memory?) has a G92 + PIOR :)
01:54 imirkin: (for DP)
01:54 imirkin: shadow: wait, so when you said DP was blue
01:54 imirkin: did you mean it was blue like this HDMI is blue
01:54 imirkin: or did you mean it was solid blue?
01:54 shadow: imirkin: precisely
01:54 imirkin: ahhhhh
01:54 imirkin: shadow: hold off on that kernel compile
01:54 shadow: imirkin: copy
01:55 imirkin: shadow: https://github.com/imirkin/nouveau/commit/b54f8d8b343136ffdd9d60382d242cced6b17bd7
01:55 imirkin: also add that in
01:55 imirkin: i bet with those 2 patches, you'll be able to get e.g. 1920x1080 modes to work
01:55 shadow: imirkin: I had the 8bpp clamp hack when it was blue
01:55 imirkin: shadow: yeah, i get it
01:55 imirkin: the blue was coz i messed with clock stuff in the other patch
01:55 imirkin: (or so it would seem)
01:55 shadow: ohhh
01:55 imirkin: (at least that's the current theory)
01:56 skeggsb: (hopefully) ;)
01:56 imirkin: we'll have to make other fixes for all this, but this is a start i suppose
01:56 imirkin: skeggsb: and presumably you didn't exactly have your 4k setup to test with when you were playing with the nva0, coz 4k screens didn't exist? :)
01:56 skeggsb: yes, i'
01:57 skeggsb: i'm fairly certain those were barely a glimmer
01:58 imirkin: shadow: i'm a bit surprised that you got a picture though, given the link training failures... weird.
01:58 imirkin: (with DP)
01:59 shadow: imirkin: with DP it's only after I try to use the Gnome Display Settings to use Single Display and it tires and fails (apparently) then reverts to mirrored
01:59 imirkin: shadow: ok. stick to HDMI first.
01:59 shadow: ok.
01:59 imirkin: could be that it only works with 4x162 and not 4x270
02:00 imirkin: 4x162 would be enough for the lower modes, i think. but not for the high native mode we were trying to do
02:00 imirkin: whiel that would fit into 4x270, i don't think the underlying hw can handle it
02:02 shadow: I'm compiling a vanilla 5.7.1 kernel which I didn't try before, and then any patches we want to try will roll a compile for that
02:03 imirkin: ok. add the 2 patches i pointed to.
02:39 shadow: imirkin: compiling with b54f8d8b_HACK_superclamp_to_8bpc.patch and bcd1d5f2_depth_only_supported_on_G94plus.patch I pulled from your git branch.
02:39 imirkin: cool
04:23 shadow: imirkin: vanilla 5.7.1 boot with DP-HDMI cable connected from system power on, and I see a legitimate output from the BenQ at the plymouth splash screen mirrored from laptop, and then extended from laptop also good output for gdm login, and goes "out of range" on BenQ at Gnome desktop
04:24 imirkin: shadow: yeah, coz it probably tries to pick a bs mode...
04:25 shadow: will be some time before kernel is compiled something went awry starting from clean sources
04:25 imirkin: shadow: pastebin xrandr --verbose after "it goes out of range"
04:28 shadow: imirkin: https://hastebin.com/zoqafuxepu.sql
04:29 imirkin: shadow: right, the stupid doublescan mode again
04:29 imirkin: shadow: xrandr --output DP-1 --mode 0xb3
04:35 shadow: imirkin: looks like https://i.imgur.com/A50M2Xx.jpg
04:35 shadow: normal-ish I guess
04:35 imirkin: shadow: that's good, right?
04:35 shadow: I think so
04:35 imirkin: yay
04:36 imirkin: so ... i dunno where those doublescan modes are coming from
04:36 imirkin: we should also be rejecting them, dunno why not
04:40 shadow: imirkin: yes if I hit Gnome Display Settings for extended desktop, the BenQ goes "short and wide", and I hit that 'xrandr --output DP-1 --mode 0xb3' again now it's usable at least for 1080p. Progress :)
04:41 shadow: compiling will take time I'll test those patches when possible
04:44 imirkin: shadow: those patches might help DP directly
04:44 imirkin: but it won't change the situation by much
04:44 imirkin: basically that 0xb3 thing isn't constant ... allocated dynamically
04:44 imirkin: i was just looking for a sub-165mhz mode
04:44 imirkin: in the dp-1 section
04:44 shadow: copy
04:45 imirkin: skeggsb: HDMI still goes through PIOR for that connector, right?
04:46 imirkin: skeggsb: or is PIOR only used for DP?
04:46 skeggsb: no, it uses the PIOR still
04:46 imirkin: ok, that's what i thought
04:47 imirkin: shadow: you probably won't be able to get the higher resolutions on that monitor with that laptop though
04:48 shadow: imirkin: good to know! So, the real bugs are wrong modes either way, and some funky DP cable behavior?
04:48 imirkin: shadow: well ... a few real bugs.
04:48 imirkin: shadow: in part, not sure what the hw allows for...
06:24 shadow: imirkin: I've got those two patches in and booted up, what should I be trying to test?
06:26 skeggsb: just don't breathe too heavily or it might break :P
06:27 shadow: FYI gnome display settings changing the BenQ to 1920x1080@60Hz works with the patches, if I try 1920x1080@120.02Hz the BenQ says out of range, and if I try 1920x1080@119.94Hz I get a "short and wide" image in black letterbox
06:28 skeggsb: we need to fix things up to reject those modes, there's definitely not enough bandwidth for them
06:29 shadow: ah okay. the display itself is only supposed to go to 100Hz so I'm surprised to see anything at supposedly close to 120Hz
06:31 shadow: it's 50, 59.93, 59.94, 59.96, 60, 119.94, 120.02 (Hz) in the list of gnome display settings. Nothing on the nose for 100Hz to try.
06:35 shadow: 1680x1050@69.88Hz looks normal in extend desktop but 1680x1050@74.89Hz only works in single display mode not extend desktop
06:36 shadow: if that kind of info is helpful. actually 1680x1050@74.89Hz in single display seems to drop out occasionally it might be near the limit
06:38 shadow: likewise 1920x1080@120.02Hz works in single display with some occasional dropout (monitor flashes black a few times trying to sync)
06:38 shadow: but the 1920x1080@120.02Hz is "short and wide"
06:43 shadow: skeggsb: ooh! DP cable (no HDMI) some of the modes are working now at 30Hz
06:43 shadow: more progress:)
13:57 karolherbst: imirkin: any idea why shared_mem size is a 17 bit value, not 16?
13:58 imirkin: coz it can be > 64k?
13:58 imirkin: dunno :)
13:58 karolherbst: yeah.. wondering
13:58 karolherbst: we had 16 bit in our struct
13:58 karolherbst: but inside nvidia QMD headers it's 17 bit
13:58 imirkin: our struct was a guess
13:58 karolherbst: I know
13:58 imirkin: i expect that nvidia knows what they're doing there
13:58 karolherbst: the x dim is also 32 bits not 31 :)
13:59 karolherbst: but we are quite sure we can only have 31 here actually
13:59 imirkin: (i.e. tenting their hands with an evil laugh, thinking those nouveau fools will be trying to make > 64k work, muahahha)
13:59 karolherbst: but 17 vs 16 is less of a "by chance" thing
13:59 imirkin: bits in the header != things actually work
13:59 karolherbst: :D
13:59 karolherbst: yeah.. but why 17?
13:59 karolherbst: they start the value being 16 bit aligned
14:00 imirkin: iirc there were some chips with 96?
14:00 karolherbst: just wondering.. maybe some special hw has more
14:00 imirkin: (96kb)
14:00 karolherbst: yeah.. let me check
14:00 imirkin: like the ever-popular GK210
14:00 karolherbst: SM61
14:00 karolherbst: and SM52
14:00 karolherbst: ohh wait.. that's maxwell..
14:00 karolherbst: I am looking at the fermi defs
14:01 karolherbst: SM37 is 112 kb
14:01 karolherbst: which is GK210 aka Tesla K80
14:01 karolherbst: so yeah.. it's that one :)
14:02 karolherbst: but SM52 with 96kb is common actually
14:02 karolherbst: so that's worth taking a look at imho
14:02 imirkin: ah ok
14:02 karolherbst: GM20X
14:02 karolherbst: 6.1 is GP10X
14:02 karolherbst: - GP100
14:03 karolherbst: fun
14:03 karolherbst: 6.2 has only 64 again.. beig gp10b
14:03 karolherbst: *being
14:03 karolherbst: and 5.3 as well being gm20b...
14:04 karolherbst: so maxwell 2nd gen and pascal - tegra and gp100
14:04 karolherbst: has 96k
14:10 karolherbst: mhh local size is 23 bit, but all hardware indeed only advertises 20
16:00 raket: Today the GTX780 (GK110) arrived. I'm using a Asus Rog Swift PG279Q, changing to 144hz (2560x1440@144hz via Displayport) refresh rate just turn the monitor black (although 120hz works fine which i'm happy with), with the nvidia-blob it works at 2560x1440@144hz, It's really not an issue. Anyone got a clue?
16:01 Lyude: raket: I can probably help, mind booting your kernel with nouveau loaded and `drm.debug=0x116 nouveau.debug=disp=trace log_buf_len=50M`, try plugging in the monitor then get me the full output from `dmesg`?
16:02 raket: brb reboot.
16:05 raket: Lyude: Done, where should i post the dmesg log? The monitor says 2560x1440@144hz but xorg just goes black
16:05 Lyude: raket: I usually use https://paste.centos.org/ but any pastebin works
16:09 raket: Lyude: the file is 6.7mb..
16:09 Lyude: raket: lol, I will just give you my rh email to send it to then
16:26 Lyude: raket: btw, how many times did you hotplug the display? just trying to make sense of what's what in your logs
16:27 raket: Ehm, i didn't hotplug it at all, when doing xrandr --rate 144 it just go black, on the monitor OSD it really says 2560x1440@144hz but nothing is displayed. (off-topic the monitor also support 2560x1440 at 165hz but it never worked with the blob either) so don't mind that)
16:30 Lyude: gotcha. oddly enough I'm not seeing any evo errors, but maybe this is one of those situations nvidia doesn't do a great job of validating display state on
16:30 Lyude: raket: btw-just to be sure, did you make sure the blob was actually running the monitor at 144hz?
16:30 Lyude: e.g. did the monitor see it that way
16:31 raket: Yeah, i can record the boot procedure and using the 144hz mode with the blob if you want. I guess it's possible to extract the modeline from the nvidia driver and try to use it with nouveau
16:34 Lyude: i doubt it's the modeline causing the issue so much as how we're programming it, but yeah - if you could get a trace of: boot up, add a marker (echo "About to run xrandr..." > /sys/kernel/tracing/trace_marker), and then run xrandr to set the blob to 144hz
16:34 Lyude: gonna try to look at the mean time to see if I can find anything funky in the evo commands we're sending
16:35 raket: i'll add 'echo "About to run xrandr..." > /sys/kernel/tracing/trace_marker' to the bootup procedure, do you need another log then dmesg when setting 144hz with the blob?
16:36 Lyude: raket: I think just the mmiotrace with the marker in the right place should be enough, mostly curious what the difference w/ the evo commands we're sending is
16:37 raket: Ok, brb, reboot with the blob
16:41 raket: Lyude: is there's something i need to turn in the kernel for /sys/kernel/tracing/trace_marker ? i have a debian kernel that works fine as well which i could use otherwise..
16:41 raket: It just says the file doesn't exist
16:41 Lyude: raket: what kernel version is that?
16:42 raket: 5.4.31
16:42 Lyude: huh, I guess just do two logs then: one with just the boot sequence, and another with both the boot sequence and changing the resolution
16:43 raket: # echo "About to run xrandr..." > /sys/kernel/tracing/trace_marker-bash: /sys/kernel/tracing/trace_marker: No such file or directory
16:52 raket: Lyude: did you mean /sys/kernel/debug/tracing/trace_marker ?
16:53 Lyude: yep, oops
16:53 Lyude: also bbiab, tending to my cat
16:54 imirkin: Lyude: did you look at the other person's issue with DP in the kernel bz?
16:55 Lyude: imirkin: planning on it today
16:55 imirkin: ok cool
16:55 imirkin: raket: fwiw a bunch of people have reported that 120hz refresh rate with 144hz screens. no clue why.
17:06 raket: Lyude: nothing gets logged to dmesg after executing: echo "About to run xrandr (nvidia)" && nvidia-settings -a currentmetamode="2560x1440_144 { AllowGSYNC=Off }" , where should i look?
17:07 raket: omg a typo, really meant echo "About to run xrandr (nvidia)" > /sys/kernel/debug/tracing/trace_marker && nvidia-settings -a currentmetamode="2560x1440_144 { AllowGSYNC=Off }"
17:08 Lyude: raket: we just need an mmiotrace, not dmesg
17:08 Lyude: https://wiki.ubuntu.com/X/MMIOTracing
17:08 Lyude: the marker is just so you can add a comment to the mmiotrace before you run xrandr, so I can tell where in the mmiotrace your gpu actually does the modeset
17:10 Lyude: so - boot, start mmiotrace and load the nvidia blob, then log into X, add the marker, then run the xrandr command to change the resolution, then finish the recording
17:21 Lyude: imirkin, skeggsb - btw, do either of you know if we have tools for tracing evo channel accesses from mmiotraces?
17:31 imirkin: Lyude: i think mmt will pick up the evo channel stuff
17:31 imirkin: but we don't really have tools to analyze it
17:33 Lyude: imirkin: alright, I should at least be able to guess where the buffer is hopefully and work from there
17:33 Lyude: i have a feeling maybe there's some special bits we need to set for high clock rates
17:34 shadow: imirkin: I left the extended desktop overnight and the system had some kind of problem there's a bunch of nouveau kernel message spam. I was able to move the mouse pointer briefly then that locked up, and the only thing I could get to work was SysRq so I did sync unmount reboot. (35M uncompressed, 2M download size) http://ai6fs.net/nouveau-test_with_two_patches-system_lockup.log.xz
17:38 shadow: otherwise, with a little shuffling of settings back and forth through gnome display settings, I can coax the system to extend desktop and DP cable is feeding the BenQ monitor a 3440x1440@59.97Hz native res signal which is working great
17:46 imirkin: shadow: what's the modeline precisely? (xrandr --verbose)
17:47 shadow: imirkin: https://hastebin.com/lasagetiqa.css
17:48 shadow: to be clear that's xrandr --verbose and I just did that while both laptop and external BenQ are at native res, things seem stable to me (except for that hiccup overnight)
17:56 imirkin: shadow: huh... ok
17:57 imirkin: so 320mhz works
17:57 imirkin: good info.
17:57 shadow: ok!
17:57 imirkin: shadow: glad it sorta-works
17:57 imirkin: my guess is that DPMS messed things up somehow? dunno.
17:59 shadow: yeah thanks for all the time to help with this :)
18:00 imirkin: np
18:20 Lyude: oooh
18:20 Lyude: raket: in the dmesg logs you gave me earlier did you ever try using 120hz?
18:21 Lyude: if not I may or may not have found your issue
18:28 Lyude: raket: also (sorry to keep bugging you!) but do you know what xf86-video driver you're using?
18:31 imirkin: would you expect that to make a difference from the modesetting perspective?
18:31 Lyude: imirkin: I would hope not considering it's just an sst display, but i figure it's worth checking
18:32 Lyude: especially since there's no evo channel errors I can see there
18:34 RSpliet: Lyude: also check whether there's any sign of the blob raising the clock in two stages (if at all possible). PLLs sometimes won't lock if the difference is too big, but can lock when done in stages.
18:35 Lyude: RSpliet: ahhhh, yeah that sounds quite possible-was thinking there'd be some weird limitation like that
18:36 Lyude: (if anyone's got a kepler 1 card + 144Hz 2K DP display we could get an mmiotrace from that)
18:36 RSpliet: Tbh I'd be somewhat surprised if this is the case. 650MHz isn't exactly blazing fast. But can't rule it out until you've tested it :-)
18:37 RSpliet: I don't suppose these per-head clocks are described in the PLL table in the VBIOS, are they?
18:39 Lyude: RSpliet: actually I was just mentioning in one of the rh channels that I was wondering if maybe there's per-head pll limits that we're not paying attention to. I -think- that would be the ones in https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/display/cl907d.h#L170
18:40 RSpliet: Looks entirely plausible!
18:40 karolherbst: wouldn't be the first time we don't know PLLs limits
18:40 RSpliet: Don't think we knew about many of these caps
18:40 Lyude: i think the last time I looked at that I was a bit confused because I couldn't figure out what increments they describe the clock limits in
18:40 Lyude: it's definitely not hz, at least I don't think?
18:40 RSpliet: Nah
18:40 karolherbst: but yeah.. reading out the caps should be helpful
18:41 Lyude: i've still got code for reading them out, I think that was really the only bit I was stuck on
18:41 RSpliet: I mean... the clock field is in KHz and they reserved 22 bits for that
18:42 Lyude: RSpliet: and the clk_max field for DP is 8 bits
18:42 RSpliet: There's also just DISPCLK_MAX by the way
18:43 RSpliet: Oh actually, that class does set the pixel clock in hz.
18:43 RSpliet: Good chance it's in 10MHz increments
18:44 Lyude: RSpliet: the clk_max field?
18:44 Lyude: i can hook up my kepler right now and give that a shot
18:44 RSpliet: All those 8-bit max clock fields
18:44 Lyude: cool, let's try then :)
18:45 RSpliet: I mean, that's just my initial guess. 255MHz max sounds like too little (by today's standards. Who knows, by 2008 standards that was fine), 100MHz increments sound too coarse-grain
18:46 karolherbst: I think when I was looking into that at some point I also came to the conclusion it's probably 10MHz steps
18:47 RSpliet: Oh wait, this class is way newer
18:48 RSpliet: GF119+
18:48 RSpliet: right, then defo 10MHz increments as my first guess.
18:52 RSpliet: Wonder how much these caps reflect HW limitations, and how much of them are fuse-backed so that they can sell Quadro cards that can achieve higher resolutions
19:03 raket: Lyude: https://wiki.ubuntu.com/X/MMIOTracing following this guide, with no nvidia driver, and doing startx (which loads nvidia) to change the mode to the monitor just goes black after quitting xorg and never get any picture from the console at all, machine totaly locks up. i made a mmio-trace log that was 650mb but i think i will get back to you guys when i have installed ubuntu (probably in a few hours)
19:03 raket: :-)
19:04 Lyude: raket: hehe, probably a good idea to xz it
19:04 Lyude: that usually shrinks it a lot
19:04 Lyude: raket: thank you by the way!
19:06 raket: xf86-video? <- that the nvidia blob i use or the nouveau driver i use for xorg?
19:14 Lyude: the second onbe
19:14 Lyude: *one
19:14 Lyude: if you just give me your xorg log from when you load nouveau I can figure it out
19:17 raket: Lyude: xf86-video-nouveau-1.0.16, btw i can try the mmiotrace stuff again, is it even neccesary to close xorg after the mmiotrace is done? because it seems it never returns to the console anyway
19:17 Lyude: raket: shouldn't be required I think
19:20 raket: Lyude: I got a quake1 (quakeworld) game in 10 minutes, and i'll be playing 2560x1440@120hz with nouveau (seems to be stable 1001fps anyway) - after that i will get back to you :-)
19:20 Lyude: raket: hehe, good luck!
19:25 imirkin: wasn't quake1 the one made for 320x240?
19:44 Lyude: RSpliet: bingo! I think your 10
19:44 Lyude: *10mhz guess was correct
19:44 Lyude: [ 12.400081] Lyude:nv50_sor_create:1717: sor-0006-0f44: max_clk=540000KHz
19:45 RSpliet: *claps hands* that's a bingo!
19:45 Lyude: also, here's our correct hdmi limit
19:45 Lyude: [ 12.399470] Lyude:nv50_sor_create:1717: sor-0002-0f42: max_clk=340000KHz
19:45 Lyude: imirkin: ^
19:46 RSpliet: Hope that'll help reject more modes upfront :-)
19:47 Lyude: definitely, i'm curious to see what this reports on raket's machine
19:59 imirkin: Lyude: for gm20x+, yes
20:00 imirkin: Lyude: it's fermi where the limit is questionable
20:00 imirkin: HDMI 1.x supports up to 340mhz, but most sources weren't able to actually hit that
20:00 imirkin: (at least not "to spec")
20:00 imirkin: there are reports of 297mhz working just fine on tesla boards
20:02 Lyude: imirkin: I was pointing out that we got sensible looking clock values from the max_clk stuff finally
20:02 Lyude: i think for the gf110 chips you saw that could do 340MHz this is the fix that's needed, since gf110 should have these caps as well
20:03 Lyude: no idea about tesla though
20:03 imirkin: none of them could do 340mhz
20:03 imirkin: they are limited to 225mhz by default
20:03 imirkin: but at least some had like 297mhz
20:03 imirkin: but i could never get proper docs on when/where that was the case
20:03 Lyude: ah-sorry, 297mhz I mean
20:03 Lyude: tldr I'm pretty sure this will fix it
20:03 imirkin: unlike the previous times when you were pretty sure? :)
20:04 imirkin: it's a tricky business, unfortunately.
20:04 Lyude: yes because these values actually look sensible
20:04 Lyude: iirc that was the only issue I hit last time
20:04 Lyude: if you've got any fermi cards like that I can write up some patches for you to tyr
20:04 Lyude: *try
20:05 imirkin: unfortunately not.
20:05 imirkin: what's the 540mhz limit for btw?
20:06 Lyude: imirkin: displayport
20:06 imirkin: hm
20:06 imirkin: that's gotta be wrong
20:06 Lyude: dang now i'm questioning that value
20:06 Lyude: yeah
20:06 imirkin: it's probably the per-lane value
20:07 imirkin: i.e. 540x4
20:07 Lyude: 5.4GHz yeah
20:07 imirkin: DP 1.1 was 1.62 / 2.7. DP 1.2 added 5.4
20:07 imirkin: i think DP 1.3 adds like an 8 or something
20:07 Lyude: yep
20:08 imirkin: oddly similar to PCIe speeds
20:08 imirkin: btw, that 340mhz is wrong for hdmi too -- it's probably 600mhz
20:08 imirkin: but 340mhz limit for non-tmds-divided
20:08 imirkin: (did i mention this stuff is subtle?)
20:08 Lyude: imirkin: btw, those limits I got from my gk104
20:09 imirkin: oh
20:09 imirkin: gk104 didn't do hdmi2
20:09 imirkin: hm. everything i've seen suggests the limit was 297mhz on kepler
20:09 Lyude: right, i am suddenly remembering all of the context around why I had issues with this
20:09 Lyude: RSpliet: ^ any idea btw?
20:09 imirkin: which *coincidence* happens to be 4k@30
20:10 Lyude: i think i'm going to bug nvidia about these values
20:10 imirkin: Lyude: oh, so apparently with "modern" blob drivers, they can do 4k@60 yuv420 on kepler over hdmi
20:10 imirkin: however there's _nothing_ in the published display classes that would suggest how
20:11 imirkin: Lyude: if you have the requisite hardware, good to at least get a mmio trace of that
20:11 RSpliet: Lyude: nah sorry, I only do the obvious stuff, not the subtleties
20:11 imirkin: maybe flipping between the @30 and @60 modes
20:11 imirkin: i'm a bit afraid that it requires doing something sketchy
20:12 Lyude: I might actually be able to test that at some point
20:12 Lyude: imirkin: more fun for me to implement then! :)
20:12 imirkin: like using a shader to pack a weird output surface
20:12 Lyude: oh no
20:12 Lyude: that's not fun nevermind
20:12 imirkin: lol
20:12 Lyude: i wanna go back
20:12 imirkin: might be that they forgot they had the bit in there
20:12 imirkin: and went back and implemented it. dunno
20:12 imirkin: originally they were saying it wasn't possible iirc
20:13 imirkin: (but "they" may have been customer support reading off published specs)
20:16 Lyude: interesting
20:16 RSpliet: Lyude: There are *quite* a few different caps in there. DISPCLK_MAX, DP_CLK_MAX, TMDS_LVDS_CLK_MAX, CRT_CLK_MAX, EXT_ENC_CLK_MAX, PCLK_MAX
20:17 Lyude: RSpliet: iirc the dispclk one we could ignore, I -think-
20:18 Lyude: maybe i'm wrong though, hm. i'll try writing up some code to show all of them
20:19 Lyude: RSpliet: btw, the ext_enc we can ignore - that's just for piors (which I'm not even sure exist on keplers, but i'm not sure they don't exist either), the crt_clk_max is probably for the dac, and i think the PCLK_MAX might actually be a per-head pixel clock limit
20:19 shadow: kernel: nouveau 0000:01:00.0: disp: ERROR 4 [INVALID_ARG] 84 [] chid 0 mthd 0c04 data 0089c20c
20:19 shadow: huh.
20:19 imirkin: so it still doesn't like that higher frequency
20:20 imirkin: that's 319750 * 2
20:20 imirkin: aka the clock you said worked fine
20:20 shadow: ah
20:20 shadow: will try flipping it down to 30Hz
20:21 imirkin: well ... if it works ... don't mess with success? :)
20:21 shadow: :)
20:23 imirkin: ultimately we have no clue how any of this works
20:23 imirkin: we just write random values to random places in memory
20:23 imirkin: and sometimes it pans out :)
20:23 imirkin: it's all about picking the appropirate random function :)
20:24 Lyude: do you need me to decode that error btw?
20:24 imirkin: i know what it says
20:24 Lyude: gotcha
20:24 imirkin: but that clock freq works for him
20:24 imirkin: so ... the error is wrong! :)
20:24 Lyude: oh really?
20:24 imirkin: (that's the "set the clock" method)
20:24 imirkin: (0x804 + 400)
20:25 imirkin: the "8" bit means something too, i forget what. but the clock value is 0x9c20c == 319750 * 2
20:25 imirkin: and he has a 319.75mhz mode set
20:29 RSpliet: The 8 bit means NV827D_HEAD_SET_PIXEL_CLOCK_MODE_CLK_CUSTOM
20:30 shadow: I'm happy to do any testing that is suggested
20:30 RSpliet: Judging by the other two being _25 and _28, I guess bits 22:23 just let you temporarily select a random low clock while you reconfigure the PLL - to prevent logic from being deprived from their clock pulses for too long
20:31 imirkin: we never use those
20:31 RSpliet: don't think we're missing out
20:33 RSpliet: NV827D_HEAD_SET_RASTER_VERT_BLANK_DMI_DURATION - nice to see that one confirmed as well by the way. Without setting that reg, the PMU on pre-GF119 doesn't know when VBLANK starts. Setting it allows flicker-free single-monitor DVFS :-D
20:33 raket: Lyude: see your mailbox for the mmiotrace!
20:34 Lyude: raket: awesome, thanks!
20:35 raket: Lyude: maybe time to update that mmio page, because xorg won't return the console after it closes. some kind of hardlock.
20:35 raket: :-)
20:36 Lyude: ah, yeah something in the nvidia blob probably changed
20:38 imirkin: skeggsb: have you had a chance to look into nouveau not loading anymore without firmware?
20:40 raket: imirkin: yeah it was made for 320x240.
20:40 raket: Lyude: hope you find something useful in these logs!
20:40 Lyude: raket: going to try decoding them now just to make sure they got captured correctly
20:43 Lyude: raket: yep-I see GPU activitty on there, thanks again
21:14 skeggsb: imirkin: nope, hasn't been particularly high on the priority list, i'll make a note and try today
21:15 imirkin: skeggsb: cool! i think a few people have pointed it out. appears to have worked OK in 5.5, broken in 5.6
21:16 skeggsb: people should use the fw anyway :P
21:19 imirkin: hehe
21:19 imirkin: well you saw that guy who can't for the life of him get it to load
21:19 shadow: do nouveau developers prefer users have the proprietary blobs loaded or not loaded?
21:20 shadow: referring to things like codecs for video playback
21:22 imirkin: nouveau developers don't really care
21:22 imirkin: G92's vdec is busted though
21:22 imirkin: so no vdec for you.
21:22 shadow: okay
21:23 imirkin: missing _something_ in getting it to turn on
21:23 imirkin: the firmware loads, non-vdec-decoding methods respond fine, but any time you try to pass actual video through it, the engine hangs
21:25 shadow: again fwiw Windows 10 fails entirely to drive the laptop display when pulling whatever driver it thinks is the correct one, and I was unable to get the vendor qualified driver to load since it is for Windows 7 and this GPU is end of life from NVIDIA... so this is a brick of hardware from official vendor support. Nouveau is the only path forward for old hardware like this.
21:26 shadow: it's not like the "latest and greatest" vendor supported OS or driver is any example to try to understand how to make it work better
21:29 imirkin: i expect blob should work fine on linux too
21:29 imirkin: the 340.x series should support your GPU
21:34 shadow: I couldn't get the NVIDIA Linux drivers to work (340.x legacy on Debian Buster).
21:34 imirkin: ah ok, weird
21:36 shadow: yeah I'd be happy to donate this laptop and keep it out of eWaste or find a purpose for it. Fixing up so that it drives output to the BenQ is great progress :)
21:37 shadow: non-NVIDIA GPU will be the daily driver soon as parts arrive
21:37 imirkin: good - that's really the best approach
21:38 imirkin: (not giving nvidia money)
22:00 Lyude: imirkin: looking at https://bugzilla.kernel.org/show_bug.cgi?id=207901 now btw
22:01 Lyude: wonder if it's just some aux bits we're not handling that no one hit before
22:01 imirkin: Lyude: yeah, dunno
22:01 imirkin: hopefully all the info is there. the person who filed it seems quite willing to try stuff / etc
22:25 Lyude: imirkin: does the kernel bugzilla not have any way of setting NEEDINFO on something/
22:26 imirkin: duno
22:26 imirkin: the fdo one did
22:28 Lyude: left them a message asking to try the nvidia blob
22:50 imirkin: Lyude: you saw the log with the additional debug info, right?
22:54 Lyude: imirkin: mhm, i'm curious to see how the blob handles those i2c aux "timeouts"
22:54 imirkin: probably "correctly" :)
22:54 Lyude: yeah-that's what I'm hoping :)
22:54 imirkin: you'll need a mmiotrace right?