18:31 mangix: Does anyone run DisplayPort 1.2 devices? I can't seem to get my monitor to 165Hz with nouveau
18:33 imirkin: mangix: at what resolution? seems like a lot of bits...
18:33 mangix: imirkin: 2560x1440
18:33 imirkin: let's see ... max data rate is 17.28gbit/s
18:33 mangix: I know the monitor supporta it. I think a 960 does as well
18:34 imirkin: yeah, looks like that fits. 13.5gbit/s based on a back-of-the-envelope calculation
18:34 imirkin: probably some overhead in there, but should still be comfortably fitting in there
18:34 mangix: I'm currently running it at 60Hz
18:35 imirkin: what gpu btw?
18:35 mangix: 100Hz shows flickering and a dim display
18:35 mangix: GTX 960
18:35 mangix: kernel 4.19
18:35 imirkin: unfortunately i won't be of much help
18:35 mangix: I have a feeling it's running at DisplayPort 1.1 mode or something
18:36 imirkin: some monitors have a setting for that
18:36 imirkin: do we reject the modeline? or what doesn't work?
18:36 mangix: I can set it just fine. But it doesn't work on the monitor correctly
18:37 imirkin: i wouldn't be extremely surprised we mess something up with higher rates
18:37 imirkin: i don't know that a lot of people test those scenarios
18:37 imirkin: most screens can't run above 60
18:38 imirkin: i know you've been in here before, but i don't remember -- are you a developer?
18:38 mangix: nope
18:38 imirkin: k. and probably nvidia RE + kernel isn't the *best* place to start that journey... =/
18:38 mangix: just another user who refuses to use stock Nvidia drivers
18:39 imirkin: so ... we should have working HDMI 2.0 support on gtx 9xx+
18:39 mangix: I really feel that it's running at DisplayPort 1.1. No idea how to test.
18:39 imirkin: does this work on windows or nvidia blob?
18:40 mangix: I believe so
18:40 imirkin: anyways, if the monitor has an HDMI input, you may be able to get 144hz
18:40 imirkin: dunno about 165
18:40 mangix: it works on my Vega 56
18:40 imirkin: with the same monitor?
18:40 mangix: Linux and Windows
18:40 mangix: yes
18:40 imirkin: like the literally identical monitor, or another copy of it?
18:40 mangix: identical. I only swapped out the GPU
18:41 imirkin: ok. so then the monitor settings are fine.
18:41 imirkin: does the monitor support 10 or 12bpc?
18:42 imirkin: (just double-checked, looks like with hdmi 2.0, you can do 2560x1440@100 without shenanigans.
18:42 mangix: I...don't think so.
18:42 mangix: No idea how to check
18:42 imirkin: 144hz requires 4:2:2 modes, which nouveau presently doesn't enable support for
18:43 imirkin: was it marketed as an "HDR" monitor?
18:43 mangix: nope
18:43 imirkin: then probably not
18:43 imirkin: (or "deep color")
18:43 imirkin: oh wait, i lied. it should be able to do 2560x1440@144hz. it can't do that at 10bpc.
18:44 mangix:goes to get an hdmi cable
18:44 imirkin: does the monitor have a hdmi 2.0 input?
18:45 imirkin: you'll need kernel v4.20+ for that btw :(
18:46 mangix: i believe it does
18:47 mangix: and bummer. guess i need to compile a new kernel
18:48 mangix: no signal on hdmi. bummer
18:48 imirkin: well, it should at least kinda work with 4.19
18:48 imirkin: just not with the higher modes
18:48 imirkin: should max out at 297mhz iirc
18:49 mangix: not 340?
18:50 imirkin: no
18:50 imirkin: it's keyed to kepler's capabilities, which max at 297 afaik
18:50 imirkin: the standard itself allows 340, but that doesn't mean the hw can do it
18:51 karolherbst: mhh, I think maxwell2 might even allow 340 though
18:51 karolherbst: at least at some point they added the fields so that it's easier to query
18:51 imirkin: maxwell2 allows 597mhz
18:51 karolherbst: with HDMI2, sure
18:51 imirkin: (or maybe 600, tbh i didn't fully test it)
18:51 imirkin: which we support now.
18:51 karolherbst: ahhh
18:51 karolherbst: you added the support for it I guess?
18:51 imirkin: and yeah, even without scrambling it probably supports the full 340
18:51 imirkin: yes, in v4.20
18:52 karolherbst: cool, kind of missed it
18:52 mangix: speaking of clocks
18:52 imirkin: it's not that interesting :)
18:52 karolherbst: and yeah, I think without scrambling maxwell2 should support 340
18:52 karolherbst: imirkin: well, for users it is
18:52 karolherbst: :p
18:52 mangix: I'm running an old school dual-link DVI setup at 403.997Mhz pixel clock on Windows :)
18:52 imirkin: karolherbst: who's crazy enough to be using nouveau at 4k...
18:52 mangix: imirkin: I used to do so...
18:52 karolherbst: uhm... I've tested it at some point though
18:53 imirkin: mangix: for hdmi, we have a hdmimhz kernel param which overrides any limits
18:53 imirkin: for dual-link we limit it to 330mhz though
18:53 imirkin: (165mhz per link)
18:53 karolherbst: ohhhh... I remember that I still have that interlaced fix on one of my branches..
18:54 karolherbst: should really finish that at some point
18:55 karolherbst: imirkin: for reading out the max clocks: https://github.com/karolherbst/nouveau/commit/d837208d5e6b805ce8444b3511fd4cbacf9af9ce dunno how much of that you had to add
18:55 mangix: imirkin: stock drivers on Windows used to do that. Then they removed the limit around the time 700 series came out i think
18:56 imirkin: karolherbst: oh whoa. i wonder if it's accurate. the thing in the vbios was def a lie.
18:56 karolherbst: it should be more accurate
18:56 imirkin: karolherbst: i just kept hard-coding
18:56 karolherbst: I've ran that through some GPUs
18:56 karolherbst: even reported 297 for kepler
18:56 imirkin: karolherbst: there were some fermi GPUs which supported 297
18:56 karolherbst: or well 300 or something
18:56 imirkin: but in the vbios it said 225
18:56 karolherbst: yeah.. but I think this field is fermi+...
18:56 karolherbst: not 100%
18:57 karolherbst: 0x957d... is something
18:57 imirkin: you mean kepler+?
18:57 karolherbst: + that werido fermi
18:57 karolherbst: yeah
18:57 imirkin: 957d is ... ... i never remember
18:57 karolherbst: anyway.. we have to read out the caps to check for interlaced support
18:57 imirkin: 957d = gm200+
18:57 karolherbst: I have a GPU where it's supported through HDMI, but not DP
18:57 karolherbst: and a TV with interlaced mode :)
18:58 imirkin: 907d = gf119+
18:59 karolherbst: ohh 0x95 was gm200+
18:59 karolherbst: yeah.. well
18:59 karolherbst: but there was something for earlier gens
18:59 karolherbst: I really have to look into it again
19:06 mangix: hohow do i figure out the displayport version used?
19:11 imirkin: not sure there's a way
19:11 mangix: I removed the nouveau xorg driver. Didn't help.
19:11 imirkin: that would only hurt
19:12 karolherbst: mangix: that stuff is implemented in the kernel anyway
19:12 karolherbst: also the version is just attached to some document describing something, but on a hardware level it's all just functioanlity you could bundle as "DP 1.2" but there is no "hw, do DP 1.2 plz"
19:13 imirkin: well, it's about allowable bandwidth
19:13 imirkin: and DP 1.2 has the crazy slices thing for MST
19:13 imirkin: so i think there's some amount of actual DP 1.2 vs 1.1 selection
19:14 imirkin: not sure.
19:14 mangix: well, the modesetting driver has worked well with nouveau for me
19:14 karolherbst: sure, but the hw couldn't care less about a version number, so either the hw complies and a driver could make displays complying to the same spec work or not.
19:14 imirkin: yeah, it'll just be slower.
19:14 karolherbst: and uses more VRAM
19:15 mangix: The slower part I have not seen
19:15 karolherbst: slower == needs more resources
19:15 imirkin: well, GL emulating weird 2d operations
19:16 imirkin: vs just doing the 2d ops directly via the 2d class.
19:16 imirkin: if you have a full-screen compositor, it probably doesn't much matter
19:16 karolherbst: modesetting is great if the driver dev doesn't care about a high efficient 2d acceleration path
19:16 mangix: makes sense
19:16 imirkin: well, also our GL driver greatly increases chances of hangs :)
19:16 karolherbst: :)
19:17 imirkin: so best to avoid it where possible.
19:23 karolherbst: imirkin: heh.. that inputPatchSize field is nowhere used
19:24 karolherbst: from nv50_ir_prog_info
19:24 imirkin: probably something calim added originally and i didn't use in the TCS bringup
19:24 karolherbst: well, it's "used" but never written to
19:24 imirkin: uh oh
19:24 karolherbst: "tcp->tp.input_patch_size = info_out->prop.tp.inputPatchSize;"
19:24 karolherbst: uhm, info-> in the current code
19:25 imirkin: but input_patch_size doesn't get used either
19:25 karolherbst: yeah.. just checked
19:25 karolherbst: git grep output was big enough, so I assumed it was :)
19:25 karolherbst: mhh, I will just remove that field then
19:25 karolherbst: I was just wondering if it was there for a reason and if you might know about it
19:26 imirkin: the tcs input patch size is controlled by a method
19:26 imirkin: not by a shader header thing
19:26 karolherbst: okay :)
19:28 mangix: hmmmm just had a thought. My laptop with a GTX 980 can do 4K-60Hz with nouveau. It uses eDP, so 1.2 definitely works
19:28 mangix: it's not working here though.
19:29 imirkin: dp 1.2 definitely works with nouveau, yeah
19:30 karolherbst: mangix: the bad thing about hardware is, that every hardware is different
19:31 karolherbst: this includes displays violating the specs or cables being a little broken and stupid and crappy displays
19:31 karolherbst: and sometimes things are just slightly different so some stuff simply doesn't work
19:35 mangix: right. it's working in Windows and with Vega 56 Linux/Windows.
19:35 mangix: it might be some oddity with the EDID
23:39 karolherbst: imirkin: mhh, this splitting up nv50_ir_prog_info struct is more annoying than I initially thought :/ we have this driverPriv field for nv50, just because it does more inside the assignSlot helpers than nvc0 and I kind of hoped there would be less places where we need the input and output data inside codegen itself :/
23:39 karolherbst: current version: https://github.com/karolherbst/mesa/commit/580eff1fcbe196248e68cbeb3f7c345b43f90bef
23:40 karolherbst: maybe we really should only save selected fields, but this will be a horror to maintain
23:40 imirkin: =/
23:40 karolherbst: and I'd rather have one struct we just save fully
23:43 karolherbst: driverPriv is only used in assign_slots.. so maybe we can just rework that a little, make nv50_ir_prog_info_out packed + explicit padding (if needed) and just save the entire struct - pointers
23:44 karolherbst: or maybe just memset to 0 and don't pack, would be enough to not end up with random bytes