00:26nyef: Hello all.
01:20imirkin: nyef: how's it going?
01:21nyef: I've been getting back to kernel hacking again.
01:21imirkin: the 3d stuff is pretty much where you left it :)
01:22nyef: Just putting together an initial stab at getting eDP panel power to work on resume.
01:22nyef: Mmm. The 3d stuff is all "fix the userland" or "reverse-engineer the IR emitter code".
01:23imirkin: well - more like make userland aware
01:23nyef: Yeah, turns out that you can force the eDP to re-power by attaching something to the HDMI port, or probably the external DPort.
01:23nyef: Clearly not a big issue for anyone with a laptop.
01:23imirkin: although if you have access to an HDMI 2.0 source *and* sink, it'd be awesome to get the higher freqs working
01:24imirkin: so far, we only have people with one of those, never both
01:24nyef: I have no idea if I have an HDMI 2.0 source at all. I doubt I have an HDMI 2.0 sink.
01:25imirkin: GM20x support HDMI 2.0
01:25imirkin: as for sinks, you just need a new-enough TV
01:25nyef: ... I think that the most recent thing I have is a GM10x.
01:25imirkin: that's the boat i'm in :)
01:25imirkin: but i have a new(ish) TV with HDMI 2.0
01:26nyef: Oh! And there's something wrong with google maps on mcp89.
01:26karolherbst: imirkin: do you mind if we start requiring C++11 for nouveau?
01:26nyef: It renders fine until it hits idle state, and then suddenly it's all black background and outline text.
01:26imirkin: karolherbst: i've been avoiding it thus far, but if there's a compelling reason, sure
01:27imirkin: or if all the other mesa c++ users agree on deciding to require c++11 tree-wide
01:27karolherbst: clover and swr already require C++11
01:27imirkin: yeah, but no one uses those
01:27imirkin: i guess the same could be said of nouveau...
01:27karolherbst: well those are explicit
01:27karolherbst: but yeah
01:27karolherbst: I mean the meson build defaults to C++11 anyway
01:28karolherbst: I think the autotools one as well
01:28imirkin: that was not previously the case, but i suppose something coudl have changed
01:28imirkin: the original reason to avoid c++11 was to support netbsd/etc gcc 4.2
01:28imirkin: which is why i use tr1/* etc
01:29imirkin: if that's all gone, then i don't much care
01:29imirkin: but c++11 would have to be rolled in carefully
01:29karolherbst: well right, but I care more about the core language features
01:29karolherbst: like for range loops
01:29imirkin: ehhh wtvr
01:29imirkin: those save like 1 line
01:29imirkin: barely worth it
01:30karolherbst: well, much nicier writing (e : arr) instead of (i; i < sizeof(arr)/sizeof(*arr); ++i) :)
01:30karolherbst: and then fetch the element
01:30imirkin: like i said... "ehhh wtvr"
01:30imirkin: the high level point stands
01:30imirkin: when all of mesa requires c++11, happy to use it in nouveau
01:30karolherbst: but on the other hand we can't be taken hostage just beacuse some distribution doesn't ship a C++11 compiler....
01:31imirkin: and when you say "we" you really mean "i"? :)
01:31karolherbst: no, we
01:31imirkin: i don't feel a particular need to use c++11 things
01:31karolherbst: we in a more general sense
01:31imirkin: but in practice, you're the only one who wants to do it?
01:32karolherbst: well, there isn't much C++ code in mesa
01:32imirkin: only like the glsl ir
01:32imirkin: and r600/sb
01:32imirkin: and st_glsl_to_tgsi
01:32imirkin: clover/swr aren't used by anyone
01:32imirkin: so they don't count either way
01:33imirkin: the things i list are used by everything (except r600/sb, which is used by all r600 users, of which i think there are a lot)
01:33imirkin: if mesa, as a project, wants to move to requiring c++11, happy to start using it in nouveau
01:33imirkin: until then, i'd rather not.
01:35karolherbst: imirkin: I pushed some of pendingchaos' patches btw
01:36imirkin: i've been working 12+hr days, so not a ton of time for foolishness =/
01:37karolherbst: imirkin: mind taking a quick look at this patch? It looks fine to me, but maybe there was a good reason the code is at it is right now: https://patchwork.freedesktop.org/patch/227794/
01:37karolherbst: not that it would hurt much anyway
01:41imirkin: oh yeah, i'm sure that's fine
01:42imirkin: i haven't looked at the context
01:42imirkin: but assuming that it's all semi-reasonable, that was just an omission when adding bindless
01:42imirkin: or maybe not even bindless
01:42imirkin: either way... an omission :)
01:47karolherbst: then I push that one as well
02:32marcheu: imirkin: on my gtx 660, the windows driver gives me 4K@60Hz... I don't know if it does this for all kepler
02:32marcheu: I have no idea why, the specs says it shouldn't be supported
02:33imirkin: marcheu: over HDMI? or over DP?
02:33marcheu: yeah HDMI
02:33marcheu: this card is supposed to be HDMI 1.4...
02:33imirkin: maybe 4K@60 4:2:0? dunno
02:33imirkin: the max pixclk for kepler is usually 297MHz
02:33marcheu: yeah the pixels are small, so I've been meaning to take a magnifier to see if that's the case
02:35marcheu: but then can it convert to YUV on the fly at scanout?
02:35imirkin: well, at encode time
02:35skeggsb: yeah, it can, i hacked up enough to convince my monitor into yuv mode and still had a rgb fb
02:35marcheu: I just need to find a magnifier :)
02:36imirkin: something in my math isn't quite working out...
02:36imirkin: 3840 * 2160 * 1.5 * 60 = 746M
02:37imirkin: that's clearly way too much
02:38marcheu: it's a pixel clock, whcih is in rgb pixels
02:38imirkin: that's the number of *bytes* per second required for 4K@60
02:38marcheu: for example using vtotal and htotal
02:38imirkin: oh, so div-by-3?
02:38marcheu: you get 594MHz
02:38marcheu: btw the 4K blanking is very long :)
02:38imirkin: ok. so then that's only 249MHz
02:39imirkin: even allowing for various bs, that should fit in 297MHz
02:39marcheu: anyway it woudl be nice to have this on linux
02:39marcheu: sadly the linux binary driver doesn't do it
02:39imirkin: yeah, selecting that stuff would be neat
02:39imirkin: we know how to do it
02:40imirkin: just ... APIs for making it happen are ... unclear
02:40skeggsb: well, we could certainly automagic this stuff for fitting modes in where they'd otherwise be rejected
02:40marcheu: ah, I thought there was a need to RE something off the windows drv
02:41skeggsb: nah, we've got enough info, particularly with the display stuff nvidia released, to make it work
02:42marcheu: ah cool
02:43nyef: First attempt to auto-repower eDP panel post-resume... failed. It re-powered, but doesn't display anything, and forcing an HPD IRQ doesn't help.
02:47nyef: ... Probably screwed something up in relation to HPD causing the panel to no longer detect as connected somehow.
03:15nyef: Hunh. No wonder forcing the HPD IRQ didn't work. My TV isn't plugged in. Oops.
05:22drathir: hi guys any idea about nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid ? or WARNING: CPU: 2 PID: 287 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:207 gf100_vmm_flush_+0x14e/0x190 [nouveau] ?
05:23drathir: or does even 01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1) supported ?
10:12RSpliet: drathir: GP108M should work, but support isn't great (as in, we're dependent on NVIDIA-provided firmwares)
10:12RSpliet: The first warning is harmless (pointer to TMDS table is often invalid in laptops with both integrated and discrete graphics)
10:13RSpliet: the second one is more concerning. Is that with a 4.17.3 kernel?
11:10drathir: RSpliet: works kinda it detect but throw nmi_watchdog errors with ouveau E[ DRM]Pointer to flat panel table invalid which unable to log off or access to alt+ctrl+1 console, for test with backlisted nouveau on uhd620 looks working fine...
11:13drathir: ofc under xfce4 looks like not causing visable problems, just hang at logout and switch to alt+ctrl+f2 console... temporally wil keep it blacklisted, but im amazed so fresh card still get even if not full but support... great job...
11:54imirkin: skeggsb: anything to worry about? WARN in nvif_vmm_put - https://hastebin.com/utojaqaces.go
13:03RSpliet: drathir: Well, the first GP108 was released mid 2017, so not exactly new. You might want to paste a full log and share the URL here. Probably file a bug if you're still experiencing this with kernel 4.17
14:57karolherbst: imirkin: how can I mark series on patchwork as obsolete or accepted? I would like to clean up my serieses
16:09pendingchaos: karolherbst: when signed in, there should be an area marked "Patch Properties" above the commit message on the page for any of your patches
16:09pendingchaos: on pages like https://patchwork.freedesktop.org/project/mesa/patches/, there is a similar area at the bottom of the page
16:09pendingchaos: not sure if it's supposed to be used for these things though, perhaps you're just meant to archive it or something
16:14karolherbst: pendingchaos: ahh, right thanks. I kind of only really looked at the series pages
22:50karolherbst: imirkin: mhh, that not uniquely defined thing happens inside handleTEX when converting from TGSI
22:51karolherbst: "Instruction *insn = proj->getUniqueInsn();"
23:48RSpliet: karolherbst: I'm leaving these warnings for you to take a look at: https://hastebin.com/woveyiyocu.cpp
23:49RSpliet: If these values are supposed to be signed, we might need a bios_s16() function/macro to make sure we can't accidentally mess up stuff like sign extension. If not, please label these struct members as unsigned
23:49RSpliet: mupuf: ^ I think some of them are fan related as well