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