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