02:36 ylwghst: Hello
02:36 ylwghst: I set logind.conf to ignore lid switch of my laptop.
02:37 ylwghst: Theres stll something which turns screen off and then again off if i close or open the lid.
02:57 ylwghst: Can I somehow change what happens if I close lid?
03:43 ylwghst: Hello
16:02 jolar2: karolherbst: I am sorry I have not submitted the patch yet. I will be able to do so today if is not too late.
16:20 karolherbst: jolar2: yeah, no worries
18:20 jolar2: imirkin_: You are probably right, but my memory did not fail me either. It just seems that sometimes when I boot with computer in dock and start X, the system hangs.
18:21 jolar2: imirkin_: but... even if that is the case, I still think this patch is a step in the right direction, since it actually possible to use the external displays of the dock
18:21 jolar2: since it actually makes it possible*
18:25 imirkin_: not sure what "this patch" is tbh
18:27 jolar2: accepting 3d controllers and not only vga controllre in nouveau_fbcon_init
18:27 jolar2: I removed the check as per your suggestion
18:27 imirkin_: ah yeah ok
18:27 imirkin_: there might actually be a better thing to do
18:27 imirkin_: but that'll definitely be part of the solution
18:28 imirkin_: that check is definitely bogus
18:29 jolar2: ok, I will send the patch to the ML now
18:29 imirkin_: well
18:29 imirkin_: i think it was there for a real reason
18:29 imirkin_: despite its bogosity
18:29 imirkin_: i mean - go ahead and send
18:29 imirkin_: but skeggsb - do you remember why we did that?
18:30 imirkin_: was it for those accelerator boards which had DCB's but not display hw?
18:30 imirkin_: or was it for some dual-gpu case with that situation?
18:30 imirkin_: we ought to be able to condition it on whether display init succeeded or not
18:31 karolherbst: imirkin_: well it was added like 4 years ago, maybe it will be fine
18:32 imirkin_: or maybe we can spend 5 minutes and order the code properly
18:32 karolherbst: any ideas?
18:32 imirkin_: here is the question - what happens if DCB has connectors but e.g. display is fused off
18:33 imirkin_: we definitely handle that elsewhere
18:33 imirkin_: try to create a disp and it fails
18:33 imirkin_: will we still try to create a fbcon?
18:34 imirkin_: if so, that's bad.
18:34 imirkin_: if not, then it's all already fine and working
18:35 imirkin_: someone just has to read the code a little
18:36 jolar2: :)
18:50 josef_: ok I have sent the patch
18:52 josef_: imirkin_: if you can hack the hotplug code, I can test it with the docking station.
18:53 buhman: does that drm-git/nouveau-git live distribution still exist?
18:56 buhman: https://nouveau.pmoreau.org/ ah; that's so hard to find on google
19:00 Lyude: Hey so I know which debug level can get me mmio tracing for nouveau in dmesg but what subdev should I be looking at, devinit?
19:01 tobijk: imirkin_: an fbcon is now created when an actual monitor is attached, thus we do not create one on empty fused-off connecotrs anyway :>
19:02 tobijk: karolherbst created a guard against that speicifc change :)
19:13 tarragon: now I am scared to play games :(
19:13 tarragon: when's nouveau threading gouing to be stable?
19:14 josef_: i played like three or four dota 2 games without problem on an optimus system (DRI_PRIME=1)
19:14 josef_: not scared at all
19:14 tarragon: josef_: which kernel?
19:15 tobijk_: tarragon: most games do not use threaded rendering
19:15 josef_: 4.13.9 maybe
19:15 josef_: or 4.12.12
19:15 tarragon: something wrong with 4.13.10
19:15 josef_: ok
19:15 tarragon: mm.. I should try wine then
19:16 tobijk_: tarragon: meaning is: rendering things from different threads, most games have one rendering thread some other threads for other stuff
19:19 tarragon: lol, what's Tanenbaum's $$$ cut from running MINIX on every Intel's ME???
19:19 Lyude: nothing
19:20 tarragon: Lyude: yeah right.
19:20 Lyude: but i just realized this is nouveau and that's a weird question to ask here
19:20 tarragon: win win situation for a researcher.
19:20 tarragon: oh oops
19:20 tarragon: my bad
19:29 Lyude: karolherbst: well turns out that regression I thought I saw ended up being that I had accidentally made it so that nouveau was unconditionally enabling clockgating, using the set of mmio packs for fermi instead of kepler ones whichh was causing the random gr init errors
19:29 Lyude: good news: I guess I know the answer to whether or not we can break things like that with BLCG
19:29 karolherbst: Lyude: ough...
19:30 karolherbst: well
19:30 karolherbst: Lyude: you can even disable engines instead of setting them to auto, this also breaks stuff ;)
19:30 Lyude: hehe
19:36 Lyude: btw, do we know if the CG_CTRL registers (like PTHERM.PGRAPH_CG_CTRL @ 0x20200) do anything on their own seperately from BLCG
19:49 tobijk_: meh, it looks like we are pretty stupid when we want to store immediate values
19:51 tobijk_: karolherbst: do you have a patch for this kind of optimization (it looks like something you already thought of)
19:51 tobijk_: https://hastebin.com/iganamimox.pl
19:51 buhman: when I do `DRI_PRIME=1 glxgears` I get https://ptpb.pw/x52k
19:53 tobijk: buhman: is that a plain DRI2 system or do you have DRI3 available?
19:54 buhman: that's whatever https://nouveau.pmoreau.org/ is
19:55 buhman: tobijk: how do I determine this?
19:55 tobijk: buhman: make sure the nouveau kernel module is loaded
19:55 tobijk: dmesg
19:56 tobijk: (as this is pmoureaus build it most likely got DRI3) :)
19:56 buhman: dmesg says nothing about dri, but /var/log/Xorg.0.log says DRI2 is being used for nouveau and i965
19:57 tobijk: buhman: looks for nouveau in dmesg
19:57 tobijk: ignore my DRI comment
19:58 buhman: https://ptpb.pw/7EAC
19:59 tobijk: module looks fine as well
19:59 tobijk: it is loaded
20:00 tobijk: not sure, mybe the build is really missing those .so
20:00 buhman: mesa seems to be providing them?
20:00 tobijk: it should
20:00 buhman: should they exist somewhere besides /usr/lib/xorg/modules/dri?
20:01 tobijk: buhman: just try LD_DEBUG=libs DRI_PRIME=1 glxgears
20:02 tobijk: and see if LD finds those libs
20:02 buhman: ah yeah
20:02 buhman: so that mesa-git build is just broken
20:02 buhman: archlinux-upstream mesa works fine
20:09 buhman: what does it mean when I try to write to pstate and it returns "function not implemented"
20:14 Lyude: Ok wow. so the CG control registers definitely make a huge difference on their own even without blcg. like, enormous.
20:18 karolherbst: Lyude: if you get 20% in total I am happy :)
20:18 Lyude: karolherbst: what if I told you it's way more then 20 :)
20:19 Lyude: more like, 40% running glmark2 on max perf with just those cg registers
20:19 karolherbst: ahh, I was talking about being fully idle
20:19 Lyude: (I was testing this because I wanted to make sure keeping normal clockgating in it's own commit wasn't meaningless and it looks like it isn't)
20:19 Lyude: karolherbst: yeah
20:19 karolherbst: Lyude: okay, so that just means we aren't using much of the GPU in the end
20:19 Lyude: fully idle it makes like, 10W diff
20:19 karolherbst: which is a relief
20:20 Lyude: karolherbst: nice
20:20 karolherbst: Lyude: that's still a lot?
20:20 Lyude: i know! :D
20:20 karolherbst: well, I need to test those patches at some point on my GPU
20:20 Lyude: that's just kepler1 too, about to go back to kepler2 to resume slcg
20:20 karolherbst: because on idle I had a 1W difference to nvidia
20:20 Lyude: vs. nvidia I have no idea
20:20 Lyude: i'm just comparing before gating vs. after
20:21 feaneron: when i try to "echo 0f > pstate" and the gpu is off, it gets stuck forever (already reported this situation before)
20:21 feaneron: looks like the debugfs function to set the state makes no checks to see if the status of the gpu is off
20:22 karolherbst: feaneron: yeah, we know
20:22 karolherbst: feaneron: and I have patches
20:22 karolherbst: and currently working on those to get them merged
20:22 feaneron: oh. sorry for the noise...
20:22 karolherbst: no problem
20:23 feaneron: i was working to get that fixed. where can i find your patches?
20:24 feaneron: at least to compare what i wrote against what someone who knows what's doing did
20:28 karolherbst: feaneron: https://github.com/karolherbst/nouveau/commit/6a77db9908bbde2c72c31e562d4e96f9c562b761
20:29 feaneron: thanks
20:30 feaneron: (i thought that would have been sent through a mailing list)
20:30 karolherbst: well yeah, it was
20:35 feaneron: awsome. so with that code we'll have a debugfs file for boost too
20:39 feaneron: hm... looks like 4afe0ff4 enables clocking for maxwell, does that mean nvidia released the signed firmwares?
20:39 Lyude: no, there's maxwell1 and maxwell2
20:40 Lyude: maxwell1 we can reclock without firmware, that's not the case for maxwell2
20:40 Lyude: or rather, I think the only thing we can't touch are the fans on maxwell2?
20:40 imirkin_: Lyude: the mmio reads/writes tracing got removed
20:40 imirkin_: josef_: i'll try over the weekend
20:41 imirkin_: Lyude: maxwell2 requires signed firmware to touch fans
20:41 Lyude: cool, 5 points for me :)
20:42 imirkin_: the actual reclock works fine
20:42 imirkin_: but it's tricky to get our firmware uploaded in there too
20:43 feaneron: Lyude: i think commit https://github.com/karolherbst/nouveau/commit/4afe0ff44924f enables clocking for maxwell2. But it requires NvFanless=true
20:43 feaneron: not sure what the NvFanless var means
20:43 karolherbst: Lyude: well right, you can just grab my branch and use it on maxwell2 farily safe
20:44 Lyude: oh sweet
20:44 Lyude: also right, I almost forgot to push those new slcg registers to envytools
20:45 Lyude: karolherbst: just to confirm because pushing to upstream things makexs me nervous, it IS ok for me to push new register definitions that I've come up with and actually verified to envytools rnndb, right
20:46 imirkin_: feaneron: not upstream yet. NvFanless is supposed to mean that the fan isn't controlled by the gpu
20:46 imirkin_: Lyude: yes, if you're reasonably sure, go ahead. if you're not, open a pull request.
20:46 tobijk: karolherbst: any comments to the immediate store question above?
20:48 karolherbst: Lyude: there is no harm in pushing wrong stuff, you just confuse everybody using those tools
20:48 karolherbst: tobijk: didn't see it, wait
20:48 karolherbst: mhhh
20:48 karolherbst: this totally looks stupid
20:49 feaneron: imirkin_: thanks. so only a subset of gpu fans are controlled by the EC after all?
20:49 tobijk: yep, but before i start, only wanted to make sure you didnt already fix it
20:49 imirkin_: feaneron: generically, laptops have system-controlled fans, desktops have gpu-controlled fans
20:50 feaneron: no, wait. i'm wrong
20:50 karolherbst: tobijk: okay, I think here is what happens: multiple users have the same "source" but for each we do the spilling
20:50 imirkin_: not 100% true, but ... approximately.
20:50 feaneron: yeah
20:50 karolherbst: tobijk: so what we need to do is like to just spill a value once and reuse it everywhere
20:50 karolherbst: but mhh
20:51 karolherbst: this should already work like that
20:51 karolherbst: tobijk: are there writes to those locations as well?
20:51 tobijk: karolherbst: let me check...
20:53 tobijk: karolherbst: i only find the st's to those locations
20:54 tobijk: oh not right, later on there is this kind of thing: 146: ld u64 $r0d l[$r2+0xf0] (8)
20:54 tobijk: yet 0xf0 is 0 (as the others are)
20:55 karolherbst: tobijk: you know what confuses me? there is no reason to spill a 0x0
20:55 karolherbst: imirkin_: is it possible to do $r63d?
20:55 karolherbst: that would be a fun thing to do
21:01 tobijk: karolherbst: actually for the first both, we should just do ld u64 $r0d l[$r2] (8) instead of ld u64 $r0d l[$r2+0xf0] (8), as they are 0
21:01 tobijk: not sure for the other values
21:02 tobijk: but beeing more clever about the movs would be nice as well
21:11 imirkin_: karolherbst: yes
21:12 karolherbst: nice
21:14 karolherbst: imirkin_: could it be that we spill 0x0 as well? it would be weird, but I don't know for sure
21:14 imirkin_: there's a lot of diff ways that we'll end up spilling 0's
21:34 mupuf: Lyude: yeah, more regs!
21:36 Lyude: ye :)
21:42 Aristar: hmm so far that pesky QT/KDE compositing is working with GLES2, OGL3.3 and 2.0 were buggy and only certain apps have driver blacklists
21:43 Aristar: like the nouveau detection in qupzilla really should go upstream to chromium, though needs more checks for gpu model since i'd imagine some function moreso than others
21:45 Aristar: noticed these flags: --disable-accelerated-video-decode --disable-gpu-memory-buffer-video-frames --enable-threaded-compositing --disable-webrtc-hw-encoding --num-raster-threads=1 --disable-gpu-compositing
21:46 Aristar: (though i think threaded-compositing is overridden)
21:47 Aristar: though in this case QTWebEngine is using webkit backend and not khtml i believe
21:50 Aristar: chromium/chrome in particular has had a lot of issues with nouveau, though i wonder wtf hacks google does on their devices using nvidia/nouveau
21:52 Aristar: but with intel announcing partnering with AMD to provide cpu+gpu solutions, i'd imagine many might switch to that. i tihnk it's kind alike their current iris pro SKUs which have an extra die on package, while maybe still keeping the standard iGPU in the cpu die
21:53 Aristar: (kind of expected intel to go to AMD to re-license their GPU patents since the forced nvidia lawsuit back in 2011 is expiring, which one of the settlements was intel got some important gpu licensing)
21:54 Aristar: (but didn't expect them to actually make any SKUs with actual radeons on-chip)
23:01 imirkin_: cyndis: fyi skeggsb rewrite the whole VM subsystem
23:01 imirkin_: so perhaps somewhere in there GP10B took a dive
23:01 cyndis: imirkin_: yes, it seems to :)
23:01 cyndis: *so
23:02 imirkin_: allegedly it should be a fully bisectable series
23:02 cyndis: yeah, i'll probably try bisecting soon
23:02 imirkin_: cyndis: btw, is there a marketing name for GP10B?
23:02 imirkin_: (like e.g. GK20A was the TK1)
23:02 cyndis: it's just that we need some out-of-tree patches and there has been other breakage recently so bisecting might be non-trivial
23:02 cyndis: TX2
23:03 imirkin_: ah ok, cool
23:03 cyndis: i'm trying to get some nightly testing going on for GPU stuff for tegra boards
23:04 cyndis: it was surprisingly simple to write a small program to submit stuff :)
23:05 imirkin_: piglit should be easy too
23:05 cyndis: i wanted to have something headless since our display driver is still not in
23:06 cyndis: and with future chips we might have gpu up before display
23:06 imirkin_: piglit should be fine
23:06 imirkin_: with gbm
23:06 imirkin_: no display required
23:06 cyndis: ah, ok, i should try it
23:06 imirkin_: PIGLIT_PLATFORM=gbm run-the-piglit-stuff
23:07 cyndis: thanks, i'll try it at some point
23:07 imirkin_: generically, nouveau is pretty conformant
23:08 imirkin_: but not quite there with actual passing of CTS
23:09 cyndis: i remember trying it a long time ago with nvidia.ko and crashing everything.. :)
23:10 imirkin_: lots of piglit failures with nvidia
23:10 imirkin_: some are questionable bugs in nvidia driver, others are legit bugs
23:10 imirkin_: i used to report things... someone pointed me at an email address where competent people replied
23:10 imirkin_: but eventually that fizzled out
23:11 cyndis: such it is
23:12 cyndis: btw, is there on any off chance any volta-related work going on?
23:12 imirkin_: can i get one at Best Buy?
23:12 cyndis: no :)
23:12 imirkin_: okay then.
23:12 cyndis: but you couldn't get a GP100 there either and AIUI you had one
23:12 imirkin_: even if there were, i suspect it would not be publicly-talk-about-able
23:12 cyndis: makes sense.
23:13 imirkin_: but i don't get fancy new GPUs, so i dunno. although gnurou sent me a TK1. that was nice of him.
23:14 imirkin_: (unfortunately the board seems to die a horrible death as a result of network activity, which is unfortunate for my nfsroot setup...)
23:14 Tanriol: Hello! Does anyone have a reasonable understanding of what needs to be done to make HDMI audio work if it does not?
23:14 cyndis: i think i'll be looking at adding volta support eventually for tegra
23:16 imirkin_: Tanriol: hdmi audio works
23:16 imirkin_: [generically speaking]
23:16 pmoreau: cyndis: With some firmware support? O;-)
23:17 imirkin_: Tanriol: oh, do you have one of those laptops that don't expose the audio subfunction?
23:17 cyndis: well.. we have released tegra firmwares previously, i would expect that to continue :e
23:18 Tanriol: imirkin_, on my laptop it does not :-( Thinkpad P50, GM107GLM [Quadro M1000M]
23:18 cyndis: i haven't followed the other firmware discussions so i don't know the status with those
23:18 imirkin_: Tanriol: yeah i think that's true of a bunch of people... can you pastebin the output of 'lspci -nn -d 10de:' ?
23:18 imirkin_: cyndis: the gist is that nvidia hasn't provided pmu firmware for any GM20x+ that are capable of reclocking.
23:18 pmoreau: True. I don’t remember if the Pascal tegra got even its PMU firmware released or not.
23:19 imirkin_: cyndis: and for others, the tendency is to release that firmware *way* late... as an example, GP108 firmware is still not out.
23:19 imirkin_: nor do i have any expectation of it ever appearing.
23:19 cyndis: yeah, i know they are missing. but i haven't looked at internal discussions about it.
23:20 imirkin_: cyndis: i'm sure they were along the lines of "our thousand-strong engineering team can't compete with the nouveau guys. let's sabotage them by not providing reclocking firmware!"
23:20 cyndis: he, clearly :)
23:21 Tanriol: imirkin_, do you need one from a fresh boot? Right now the audio function is visible after trying the rescan hack, but usually it's not.
23:22 Tanriol: https://pastebin.com/S0Pxckiu
23:23 imirkin_: Tanriol: ok yeah
23:24 imirkin_: i just wanted to confirm that you had that issue
23:24 imirkin_: Tanriol: would you be capable of testing kernel patches if i had them? (i don't)
23:26 imirkin_: (basically a bunch of people have reported the issue, but no one's shown up who's willing to test patches, and without that, i'm not planning on spending the time to write them)
23:26 Tanriol: Sure. I've tried some printf-oriented debugging... the "multifunction" bit is not set on the initial boot or when resuming from suspend, it appears after the first time "nouveau 0000:01:00.0: DRM: resuming console..." appears.
23:27 imirkin_: yeah
23:27 imirkin_: the pci subsystem needs to be told about the multifunction-ness
23:28 Tanriol: I've tried adding a PCI quirk, but seems that the vendor ID can't be read at the enumeration time either...
23:28 imirkin_: this is what bjorn said: https://lists.freedesktop.org/archives/dri-devel/2017-October/154510.html
23:30 imirkin_: Tanriol: can you add yourself to https://bugs.freedesktop.org/show_bug.cgi?id=75985 ?
23:32 Tanriol: Done.
23:33 imirkin_: Tanriol: not quite... you wrote a comment, but didn't add yourself to the cc list
23:34 Tanriol: Oops, sorry, expected that to be automatic.
23:37 imirkin_: thank you
23:37 imirkin_: i will attempt this over the weekend