00:00nyef: Pricy? Wouldn't surprise me. eBay, for starters. And then it's an MXM module, which probably costs a bit as well.
00:00imirkin: i tend not to pay more than $10 for gpu's on ebay
00:01imirkin: i splurged once and got one for $35 or so.
00:01imirkin: (the GT215 with GDDR5 vram, to try to figure out wtf it wasn't working with nouveau)
00:02nyef: Desktop or laptop cards, though?
00:05nyef: 980M is from about $670 - $980. Desktop type 980 is $200 - $500ish.
00:08imirkin: it's probably still by far and away my fastest card
00:08nyef: So, call it $450 for the MXM, plus $200 for the relatively-recent-card-ness?
00:09nyef: Hrm. Except that the MXM cost scales by recent-ness of the card.
00:09branau: imirkin yeah, I try to stay away from the testing stuff for the most part. I'm trying to learn C/C++ while working a full time job and having a gf so I have too little free time as it is to be debugging why stuff suddenly breaks :P
00:11imirkin: branau: good luck :)
00:11branau: haha thanks :P
04:37imirkin: skeggsb: looks like 2f693ef05fc8ca4627535a85900d8563b66032e9 in your tree never made it into the linux tree...
04:38imirkin: skeggsb: should probably run a diff to true it all up...
04:39imirkin: er wait. no. it's there. something's messed up in my local git.
04:53imirkin: genius. i had a *branch* called origin.
04:55imirkin: gr. and now 'git show origin' doesn't work anymore :(
04:56imirkin: (origin/master works of course)
04:58imirkin: this is such an old tree. i've probably screwed it up by now.
04:59imirkin: i think it started around 2.6.20 or so? maybe even older.
05:00nyef: Check the .git/config ?
05:00nyef: There may be something obvious different from a more-normal tree.
05:02imirkin: yeah, i've already poked around pretty extensively in there
05:02imirkin: in a moment of ineptitude, i had also previous named the upstream remote as "master" :)
05:02nyef: Impressive. (-:
05:03imirkin: i think it was my first "real" git tree
05:03imirkin: should probably just wipe it and start over.
05:05imirkin: for now 'git show origin/master' works - where is the "default" branch normally specified for a remote?
05:05nyef: Maybe remotes/origin/HEAD ?
05:06nyef: Alternately, it might be dependent on the *current* branch.
05:06imirkin: .git/remotes/ has a single file called 'origin'
05:06nyef: Should be a directory?
05:06imirkin: yeah, maybe that's it - i'm not on a branch atm
05:07imirkin: hm, in another tree, i don't have the remotes dir at all
05:07nyef: And "cat .git/refs/remotes/origin/HEAD" => "ref: refs/remotes/origin/master"
05:07nyef: (in my current mesa tree)
05:07imirkin: aha - yes
05:07imirkin: that's what i'm missing.
05:08imirkin: probably from before that was a thing :)
05:08nyef: Heh. Might well be.
05:10imirkin: did you get to play with windows yet?
05:10imirkin: and/or the intel gpu?
05:10nyef: Not yet.
05:10nyef: Spent the afternoon/evening working on my Forth system, for a change of pace.
05:13nyef: Before I can do the windows thing, I need to basically gut my current primary system, the one that I'm using now, as it's the one with the actually-good-and-working video card, and I'm not about to work without my main system, but the root disk happens to be buried such that I have to take the system almost completely apart to remove it.
05:13nyef: And the intel gpu thing is waiting on me taking a few (three?) mmiotraces for the lvds-vs-edp panel suspend thing and the DP hotplug thing.
05:14nyef: After which point, it's pull-the-card time, and the intel GPU should (in theory) appear.
05:14imirkin: heh, well don't kill yourself ;)
05:14nyef: Current plan is tomorrow.
05:15imirkin: my guess is that the packed frame thing works, just needs a bit more "magic touch" on the nouveau end of it
05:16nyef: Yeah, that's the impression I'm getting so far, but proof would be nice. (-:
05:16imirkin: so like ... how does that modeline come in?
05:16imirkin: is it 1920x1080 or 1920x2200 or whatever
05:16imirkin: and what kind of fb size do you get?
05:18nyef: It's exposed at 1920x1080, with DRM_MODE_FLAG_3D_FRAME_PACKING
05:18nyef: Or, well, one of the other base resolutions, but with that flag.
05:18imirkin: ok, and so ... you get a fb that's 1920x1080 as well?
05:18imirkin: and the system is supposed to flip them back and forth between both eyes?
05:18nyef: It's supposed to be larger, I think?
05:19imirkin: and not miss a vblank?
05:19imirkin: that sounds like a recipe for disaster...
05:20imirkin: if the fb is supposed to be larger, won't the surrounding logic reject that? or use the mode's width/height? i.e. what will cause the "other" eye to get scanned out?
05:20nyef: Frame packed video is supposed to be twice as tall plus an extra vblank period worth of blank space in the middle, still at the same frame rate (so twice the clocks required), and the TV/monitor sorts the stereoscopy out from that.
05:21imirkin: i understand the general idea
05:21imirkin: but if you're using a 1920x1080 mode. and telling the CRTC hw to scan out 1920x1080
05:21imirkin: then how will it ever scan out the "other" eye?
05:22nyef: Roughly, for a 60Hz mode, it gets transmitted as a 120Hz mode, but the blanking interval between the left and right images is "active" video rather than usable for transmitting other information.
05:23imirkin: not sure you're understanding my question
05:23imirkin: the modeline says 1920x1080
05:23imirkin: we program the crtc for 1920x1080
05:23nyef: Ah. I have no clue what the effective modeline is by the time all the 3D stuff happens.
05:23imirkin: at what point does the crtc know that "oh, this should really be 1920x2200"
05:24imirkin: ah ok
05:24imirkin: well - would be good to track down ;)
05:24nyef: That's plausibly what's going wrong, I just don't know yet.
05:25imirkin: so ... yeah. figure out what fb size you're getting from userspace, figure out what the modeline & co stuff says, etc
05:25imirkin: basically you have to be passing enough info for the hw to at least have a chance at getting it right :)
05:26nyef: Exactly. So my next steps, after running the test against the display panel, are to check exactly what the test program is doing for mode setup.
05:27nyef: ... and possibly see what the intel driver is doing with it as well.
05:27imirkin: yeah - we might not have docs, but we have others to copy from :)
05:40nyef: Looks like the userland computes the fb size based on the modeline and the 3D mode flags, and passes that to the kernel for allocation.
05:42imirkin: fb size != scanout size
05:43imirkin: i.e. you can have a large fb and scan out a portion of it
05:43imirkin: [this is how dual-monitor & co works]
05:43nyef: Okay, so is the scanout size set on the userland side or the kernel side?
05:44imirkin: it's one of the fb parameters iirc
05:44imirkin: i.e. the fb has a size, and then you specify the window in that fb that you want to scan out (which may be the whole fb)
05:47imirkin: hmmmm.... drm_mode_crtc has the x/y, but i guess the width/height are set by the mode?
05:48imirkin: (you can check include/uapi/drm/drm_mode.h for the ioctl info)
05:48nyef: Yeah, the CRTC gets the x/y for scrolling/panning purposes, but the width/height is a mode thing makes a certian amount of sense.
05:48nyef: I'm digging through the igt sources right now.
05:51imirkin: maybe? i'm a bit weak on all the uapi stuff, esp now with atomic
05:51nyef: No, that's fine. I'm expecting to be doing most of the digging anyway. (-:
09:57karolherbst: mupuf: what kind of kernel is currently installed on reator?
09:58mupuf: a kernel too old for compiling the latest nouveau tree
09:58karolherbst: yeah, I know that
09:58karolherbst: I was just thinking how far I have to rebase into the past
09:58mupuf: uname -a would tell you what you want to know
09:58mupuf: oh, should be the previous rebase
09:58karolherbst: I already did that, and the git tag didn't help
09:59karolherbst: ohh wait
09:59karolherbst: I have to remove the g ....
09:59karolherbst: okay... this will be fun, so I have to throw the atomic modesetting things out still
10:00bonbons: imirkin: hm, 4.9.5 with antiflicker patch gets stuck while loading nouveau (no idea yet who's at fault, could be some printk() at wrong time)
10:02karolherbst: mupuf: make: *** /lib/modules/4.7.0-rc5-NV-42542-gc11dea5/build: No such file or directory. Stop.
10:02mupuf: hmm, weird
10:03karolherbst: symlink points to dead location
10:03karolherbst: ls: cannot access '/lib/modules/4.7.0-rc5-NV-42542-gc11dea5/build/': No such file or directory
10:03karolherbst: /lib/modules/4.7.0-rc5-NV-42542-gc11dea5/build -> /home/mupuf/nvidia/linux-stable
10:03mupuf: well, sorry, did some cleanup
10:03mupuf: will fix it
10:03karolherbst: no worries
10:06mupuf: Receiving objects: 100% (5519403/5519403), 1.11 GiB | 46.45 MiB/s, done "D
10:06karolherbst: how slow
10:07bonbons: imirkin: netconsole disabled does not help, with netconsole last printk was: "nouveau 0000:02:00.0: DRM: allocated 1024x768 fb: 0x4000, bo dc972d10"
10:10mupuf: karolherbst: ok, will just recompile the new kernel
10:10mupuf: too many things missing
10:10karolherbst: 4.10 rc?
10:10karolherbst: or drm-next?
10:11karolherbst: gnurou: there? Do you have any secboot related patches pending or are they all in skeggsbs tree by now?
10:12karolherbst: mhh, last series seems to be in :) good
10:17karolherbst: mupuf: did you try to reboot reator?
10:18mupuf: still compiling the new kernel
10:18karolherbst: no, you aren't
10:18mupuf: yes I am :D
10:18mupuf: different machine
10:18karolherbst: ohhhh :D
10:18karolherbst: I see
10:53mupuf: karolherbst: I managed to botch the config
10:53mupuf: this will take a little more time
11:08karolherbst: mupuf: no worries, I still have my breakfast waiting for me :p
11:15mupuf: karolherbst: I wonder if the kernel is not plain broken
11:15mupuf: Will try one last trick
12:25MarcinWieczorek: Hi guys
12:25MarcinWieczorek: imirkin: Remember me? I came to tell you that everything is working ok
12:58karolherbst: mupuf: what's the status?
14:21karolherbst: mupuf: :D crap I was just compiling against a local compilation
14:21karolherbst: and the gcc update killed it
15:08branau: Howdy everyone!
15:09branau: imirkin, it seems I was a bit too soon to say that the nouveau drivers were working without problems for me :( I'm unfortunately unable to boot now unless I blacklist them. I don't think I updated anything or otherwise made configuration changes, but I restarted yesterday and suddenly couldn't even get to a console login
15:09branau: How would I begin debugging this?
15:10branau: I suppose dmesg would be a good place to start, right?
15:15karolherbst: branau: yes, check dmesg
15:17kwizart: hello, anyone knows can point me to the code where nouveau.ko (kms) probes for the hardware and if there is a mean for the code to "re-"probe, specially from userspace ?
15:18kwizart: (without using modprobe/insmod directly)
15:21bonbons: kwizart: maybe echoing into bind/unbind under /sys/bus/pci/drivers/nouveau/?
15:23branau: karolherbst woops, I guess I was mistaken. I can boot, but suddenly can't login. If I blacklist the module, then I can login no problem. Would I still want to check dmesg?
15:25branau: Hmm, can't even login on TTY2
15:25karolherbst: kwizart: you can always rebind devices to drivers, but maybe it would be better to tell us about any issues you have first, because usually devices should be detected automatically as long as they are supported
15:25branau: it's spitting out a couple of error messages here though:
15:26branau: MMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [kworker/3:2:208]
15:26branau: Seems to be repeating that over and over agin
15:27karolherbst: branau: do you have a mobile nvidia gpu by any chance?
15:27karolherbst: branau: also, the backtrace of the stuck thread would help
15:27branau: Oh wait, theres this: "nouveau 0000:01:00.0: pciL failed to adjust lnkctl speed"
15:27branau: karolherbst indeed, I've got a 950M
15:27branau: This is on a laptop
15:28karolherbst: branau: mhhh mhhh
15:28karolherbst: branau: backtrace pls
15:28kwizart: karolherbst, seems like /sys/bus/platform/drivers_probe might be something, I'm usually booting with nouveau (ksm) disabled with nouveau.modeset=0 (to use nvidia)
15:28branau: Let me reboot into a live USB, or try to SSH in as I can't do anything here
15:28karolherbst: kwizart: then you have to rmmod nouveau anyway
15:28kwizart: but if there is something broken (nvidia.ko isn't here) I want to fallback to nouveau
15:29karolherbst: kwizart: maybe there is a way to prefer a driver for a certain device
15:29kwizart: but if nouveau.modeset=0 is set on cmdline I guess the kms code will never probe, unless explicitely requested
15:30karolherbst: kwizart: efifb is a nice fallback though if you only care about using nvidia
15:30karolherbst: problem is, that nouveau and nvidia don't play nice together
15:30karolherbst: you will still get many issues starting X if nvidia isn't there
15:31karolherbst: so there is no real benefit in using nouveau until you fix your nvidia issues, because it wouldn't get you a working X
15:32kwizart: well, that's not about my single use-case, this is a packaging issue , so I would like a case that can work for any users
15:32karolherbst: not possible
15:32karolherbst: unless nvidia fixes their policies about X
15:32kwizart: more precisely, I want to fall back to using nouveau if the nvidia.ko isn't here
15:32karolherbst: yeah and this won't work
15:33karolherbst: you have two big issues you would have to workaround
15:33karolherbst: 1. xorg.conf setting up for nvidia
15:33karolherbst: 2. libGL.so pointing to nvidia libGL
15:33karolherbst: the second should be fixed by using libglvnd
15:33kwizart: karolherbst, I think hansg already made the job with the glx.so override module already in a sub-set of the nvidia outputsource configuration file
15:33kwizart: libGL is already using libglvnd (with glvnd enabled mesa)
15:34karolherbst: I see
15:34karolherbst: the problem about the kernel module files is, that you have to specify a probing order
15:34karolherbst: issue is, what will you do if nouveau is inside the initramfs, but nvidia isn't?
15:35kwizart: well, in this case the nouveau module will be loaded, which is better than a black screen
15:35karolherbst: yeah, but how do you switch to nvidia?
15:36karolherbst: if nvidia is installed on /
15:36karolherbst: not initramfs
15:36karolherbst: you have vesafb/efifb for not getting a black screen
15:36karolherbst: if you get a black screen with missing nvidia/nouveau, fix this first
15:37kwizart: I tought nvidia was conflicting with vesafb
15:37karolherbst: no idea, I am only using efifb
15:37kwizart: even efifb (at least not so long ago)
15:37kwizart: karolherbst, even with nvidia ?
15:37karolherbst: I think nvidia did a lot of drm and modesetting stuff in the past
15:38karolherbst: should be fixed by now
15:38branau: Hmm I've chrooted into my hard drive install from the live usb but there's no /var/log/dmesg nor /var/log/messages
15:38branau: Am I missing something?
15:39karolherbst: kwizart: mhh, there seem to be many reports regarding efifb and nvidia :/
15:39kwizart: karolherbst, okay, I will try, how to setup video=efi ?
15:39karolherbst: kwizart: no, just let it be there builtin afaik
15:39karolherbst: kwizart: I am only 100% sure it works with i915 without issues, because that's what I am using
15:40karolherbst: and i915 replaces efifb later in the boot process
15:41karolherbst: kwizart: I don't know why nvidia doesn't care that much about it, but nvidia userspace stuff adds a lot of pain in cases where something doesn't work as expected and this is really annoying
15:41karolherbst: and if nvidia has issues with loaded efifb, they should fix it
15:42karolherbst: there is no excuse to leave the user with a black screen just because they don't play nice with efifb
15:42karolherbst: but I think it should be fixed since 364 or something
15:42karolherbst: at least plymouth also works with nvidia since 264
15:43kwizart: karolherbst, plymouth with nvidia bundled with initramfs ? I tought plymouth needed patches for nvidia ?
15:44kwizart: or with efifb
15:46kwizart: I think nvidia only had enabled the modeset mode by default only recently
15:47kwizart: best would be to have userspace only drivers, of course
15:48karolherbst: what version of nvidia do you ship?
15:50kwizart: karolherbst, latest stable
15:51karolherbst: I am sure it will be fine with this
16:02bonbons: imirkin: the hard lockup on modprobe started somewhere between 4.2 and 4.4, going to see if 4.3 locks up, the will bisect on nouveau or drm subtree. The lockup seems to consitently happen pretty soon after allocating the framebuffer (maybe just before or during fbcon switch), as for working kernels that's the first thing logged following allocation (at drm.debug=0x0f)
16:03branau: karolherbst finally got dmesg to work: http://paste.fedoraproject.org/533678/48510082/
16:03branau: Seems that the trace is missing though
16:03branau: It seems that my laptop works fine until I try to login to gnome
16:03karolherbst: branau: try nouveau.runpm=0
16:04branau: karolherbst where do I put that?
16:04karolherbst: it's a kernel parameter
16:04karolherbst: I don't use fancy things like grub or so
16:04branau: Oh, gotcha
16:04karolherbst: so I wouldn't know
16:04branau: Let me reboot real quick
16:06mupuf: karolherbst: sorry, I got bored with this commit, it does not boot on my machine
16:06karolherbst: mupuf: so 4.9.5 it is?
16:06mupuf: I updated to 4.10-rc3
16:07karolherbst: good enough
16:07mupuf: I tried 4.9.5 and it does not compile nouveau
16:07mupuf: I only now updated to 4.10-rc3 on my desktop machine
16:07mupuf: I will test compiling nouveau on it
16:07karolherbst: of course 4.9 doesn't compile it
16:07mupuf: and if it passes, I will push!
16:07mupuf: 4.9 does not compile it ... because the headers are missing
16:08karolherbst: you won't be lucky with kernel releases most of the time
16:08mupuf: because arch's testing package does not ship them
16:08karolherbst: those arch guys....
16:08karolherbst: I already complained about a missing arm header
16:08karolherbst: and the maintainer basically said: you are on x86, you don't need arch headers, so we don't ship them
16:08karolherbst: *arm headers
16:09mupuf: there are separate packages for them, probably what he meant
16:09karolherbst: it was the linux-headers package
16:09mupuf: linux-api-headers has them. Not sure what the difference is
16:10karolherbst: maybe it includes all header files
16:10mupuf: no idea
16:10mupuf: reading the package description would help :D
16:10karolherbst: I don't get why linux/dma-fence.h should be missing in any case
16:11karolherbst: ohh wait
16:11branau: karolherbst I think that worked. I was at least able to log in to gnome now
16:11karolherbst: it was renamed in 4.10?
16:11karolherbst: or is something new
16:12mupuf: 4.9, yes
16:12karolherbst: mupuf: yeah, linux/dma-fence.h is new in 4.10
16:12karolherbst: it was linux/fence.h in 4.9
16:12mupuf: oh, right
16:12mupuf: I got fooled by the 4.9-rc4
16:12mupuf: but yeah
16:12mupuf: /home/mupuf/nvidia/nouveau/drm/nouveau/nouveau_drm.c:973:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
16:12mupuf: let's see if I can fix this
16:13karolherbst: 4.10-rc is better than a 4.9 kernel in any case
16:13karolherbst: and I will rebase master on 4.10 after the release
16:13karolherbst: so if somebody needs a working module tree for 4.10, just use mine
16:15mupuf: ok, .unload now returns a void
16:15mupuf: easy to fix
16:16mupuf: more errors though
16:18karolherbst: mupuf: would you mind to install the 4.10-rc kernel on reator already so I could try out my stuff? :D there should only be non critical warnings for nouveau anyway
16:18mupuf: sure, wait a sec
16:20karolherbst: mupuf: thanks
16:21karolherbst: one problem though: "Makefile:654: scripts/Makefile.gcc-plugins: No such file or directory"
16:21mupuf: hmm hmm
16:21mupuf: I have scripts to copy kernels from one machine to another, maybe something changed
16:21mupuf: let's see
16:22mupuf: try again
16:23karolherbst: "ERROR: Kernel configuration is invalid."
16:25mupuf: RRrrrr, why the fuck is it so annoying?
16:25mupuf: it has worked for *years*
16:29karolherbst: make a bug report
16:30mupuf: No space left on device (28)
16:30mupuf: simple explanation :D
16:30karolherbst: I only use 4GB :O
16:30karolherbst: will whipe the kernel tree
16:31karolherbst: mupuf: better now?
16:32mupuf: in /mnt, you can store more stuff
16:32mupuf: I have a NAS
16:32mupuf: with one SSD and one HDD
16:32mupuf: so, put stuff that does not need speed there
16:32karolherbst: says the one using 5.4 GB :p
16:33karolherbst: something is still odd though
16:34karolherbst: something is broken
16:34mupuf: yep, definitely broken
16:34mupuf: let's reboot
16:35karolherbst: ./arch/x86/include/asm/bitops.h:146:3: error: expected ‘:’ or ‘)’ before ‘CC_SET’
16:36mupuf: let's see if I have the same compiler on both ends
16:36karolherbst: it is something inside a asm volatile block
16:36mupuf: as for nouveau, struct drm_framebuffer really changed a lot
16:36stefanoz: hello guys
16:37stefanoz: imirkin , do you remember our discussion yesterday?
16:37stefanoz: Of course yes, and it is working
16:37karolherbst: stefanoz: the channel is logged
16:38stefanoz: Yes I saw
16:38branau: karolherbst thanks again for your help! I'm able to successfully boot and log into gnome again :)
16:38stefanoz: anyway, adding another struct for GP107 chipset is working
16:38karolherbst: branau: mhhh
16:38karolherbst: branau: well, but now your nvidia gpu is always on
16:38stefanoz: my GTX 1050ti now works
16:39karolherbst: stefanoz: "works" ;)
16:39branau: Ah so my battery life will be terrible then
16:39karolherbst: branau: yeah
16:39stefanoz: but at least I can use it with reasonable resolution
16:39karolherbst: branau: you should make a bug report
16:39branau: Well, gaming laptops aren't known for their amazing battery life anyways
16:39karolherbst: stefanoz: true, but efifb provides this as well
16:39branau: But I'd love to
16:39branau: How do I go about doing that karolherbst?
16:39karolherbst: branau: https://bugs.freedesktop.org/
16:40branau: The dmesg output from a little while ago?
16:40karolherbst: mhh, that wouldn't help
16:40karolherbst: you would have to paste the dmesg with the stacktrace of the stuck thread
16:40stefanoz: Should I provide a merge request or submit a patch?
16:41karolherbst: stefanoz: post the patch on the ML
16:41stefanoz: Its stupid i know
16:41branau: Hmmm so how can I get that stack trace if it locks up my computer each time?
16:41karolherbst: branau: pstore, netconsole, ssh
16:41karolherbst: we could check pstore
16:41stefanoz: karolherbst: sorry, ML stands for?
16:41karolherbst: branau: do you have a line with mount | grep psto
16:41karolherbst: stefanoz: mailing list
16:42stefanoz: ok thanks
16:42karolherbst: stefanoz: https://lists.freedesktop.org/mailman/listinfo/nouveau
16:42branau: karolherbst I do indeed
16:42karolherbst: branau: is the pstore directory empty?
16:43karolherbst: it usually only contains stuff when my kernel crashed for real
16:43branau: karolherbst yeah, it is
16:43karolherbst: so not sure about freezes
16:43karolherbst: branau: did you check your sys logger?
16:46branau: I'm running through journalctl now. I think I just found something
16:46karolherbst: --boot -1 helps ;)
16:46karolherbst: or whatever number you need
16:46stefanoz: yes, I am going to diff and post the patch
16:46karolherbst: stefanoz: good :)
16:47karolherbst: stefanoz: and state that you tested it on your 1050 ti
16:47stefanoz: yes of course
16:47karolherbst: sadly I am sure it would be too late for the 4.10 window now
16:47karolherbst: mupuf: any luck yet?
16:47mupuf: still checking what the heck is oging on
16:48mupuf: but on the other side, it looks non-trivial to use nouveau on this 4.10 kernel
16:48mupuf: struct drm_framebuffer got changed
16:49mupuf: the fix for nouveau should be in the tree though
16:49karolherbst: ohh it was changed after the merge
16:49mupuf: but it needs to be ported to the oot nouveau
16:49karolherbst: okay, then let's use 4.9 for now
16:50karolherbst: allthough that means we need a tree without the kms changes
16:50branau: karolherbst: https://paste.fedoraproject.org/533814/85103778
16:50karolherbst: which I have
16:50karolherbst: branau: perfect
16:50karolherbst: looks like a suspend issue indeed
16:50branau: Great, I'll go submit the bug report now
16:51karolherbst: branau: could you filter out everything else though?
16:51karolherbst: so just the kernel: lines
16:51mupuf: karolherbst: would using the linux-4.10 brnach OK for you?
16:51karolherbst: mupuf: it would
16:51mupuf: we could just use linux 4.10-rc3 as a base
16:51mupuf: and it should compile just fine
16:52karolherbst: what do you mean now?
16:52karolherbst: I thought you installed the rc3 kernel
16:52karolherbst: mupuf: better idea
16:52mupuf: it is drm-next
16:52karolherbst: ohh I see
16:52mupuf: which is based on a 4.10-rc3
16:52karolherbst: yeah, let's use plain rc3 then
16:52karolherbst: this is fine
16:52karolherbst: or we use skeggsb kernel tree
16:53mupuf: does he have one?
16:53karolherbst: check the branches
16:53mupuf: I see
16:53karolherbst: I think it is based on the lat PR against drm-next or so
16:53karolherbst: something weird though
16:54branau: karolherbst how's this? https://paste.fedoraproject.org/533827/14851039/
16:54karolherbst: mupuf: it's 4.9-rc4 with drm-next merged in
16:54karolherbst: + nouveau changes for 4.10
16:54mupuf: karolherbst: well, this one does not boot on my machine :s
16:54karolherbst: the linux-4.10 branch
16:54karolherbst: then plain 4.10-rc
16:55mupuf: let's try it, yeah
16:55karolherbst: branau: better, thanks
16:55branau: No, thank you!
16:55karolherbst: "ACPI Error: Method parse/execution failed [\_SB.PCI0.PGON] (Node ffff9c963b13f1e0), AE_AML_INFINITE_LOOP "
16:55karolherbst: was Lekensteyn the ACPI person? :D
16:56karolherbst: "ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PG00._ON] (Node ffff9c963b138f28), AE_AML_INFINITE_LOOP (20160831/psparse-543)"
16:56karolherbst: this sounds like something which could break a lot
16:59branau: karolherbst should I file this against xorg?
16:59karolherbst: branau: yeah
17:00branau: And for the version, I'm not sure what I'm looking for:
17:00branau: $ dnf list installed | grep nouveau
17:00branau: xorg-x11-drv-nouveau.x86_64 1:1.0.13-1.fc25 @fedora y
17:00karolherbst: branau: kernel version is enough
17:00branau: Ah, ok
17:02stefanoz: I had similar problem with ACPI
17:03karolherbst: stefanoz: how was it fixed?
17:03stefanoz: I just updated the BIOS
17:03karolherbst: mhhh, fair point
17:03Lekensteyn: karolherbst: w/o any context I guess this is the problem: https://bugzilla.kernel.org/show_bug.cgi?id=156341
17:04karolherbst: Lekensteyn: looks like it
17:04karolherbst: Lekensteyn: ask branau then
17:04branau: What's up?
17:05karolherbst: branau: talk to Lekensteyn about your issues :p
17:05branau: Ah ok, thanks!
17:05branau: Lekensteyn, what info can I give you?
17:05Lekensteyn: laptop model and acpidump (basically generated by https://bugs.launchpad.net/lpbugreporter/+bug/752542)
17:06Lekensteyn: but I am afraid that it would only help to confirm the problem and at most give a workaround
17:06Lekensteyn: I never really figured out how to solve it
17:07branau: Anything I could do to help out on that front?
17:09Lekensteyn: you can check the bugzilla link above and see if you have any ideas
17:10Lekensteyn: and if you are interested in a possible acpi_osi workaround that allows you to use power saving, check your acpidump
17:10branau: Alright, I'm getting that tar.gz file ready right now, so I'll keep reading while I'm waiting
17:10karolherbst: stefanoz: please use git send-mail
17:13stefanoz: I am not in git repo
17:13karolherbst: then at least use diff -u
17:14stefanoz: If needed, I will send back another one
17:22mupuf: karolherbst: ok, 4.10-rc3 works quite well even with master
17:22mupuf: now, let me chech why the fuck it does not compile on reator
17:28imirkin: bonbons: there was a major rewrite in kernel 4.3
17:28imirkin: bonbons: it wouldn't terribly surprise if if it didn't get *extensive* testing on nv1a... :)
17:28bonbons: imirkin: that's what I saw, just bisecting between 4.2 good and 4.3 bad...
17:28imirkin: bonbons: awesome :) hope you're using a separate box to compile
17:29bonbons: sure, otherwise it would take even longer
17:29imirkin: that rewrite series is largely bisectable though, so it should hopefully zero in on a pretty targeted commit
17:29imirkin: unlike some of the previous rewrites that were just one giant mega-commit
17:30bonbons: the compiling box is aging as well, but at least 4 times quicker and keep hot filecache :)
17:31bonbons: what's pretty sure is that hard freeze its related to/triggered by fbcon setup
17:35imirkin: or something that happens right after :)
17:37bonbons: well, with full debug enabled and netconsole the last line I get to see when it hangs is nouveau 0000:02:00.0: DRM: allocated 1920x1080 fb: 0x4000, bo ddc5acb0
17:37imirkin: although iirc fbcon is the last thing to be set up
17:37bonbons: when it does not hang the next line is from fbcon
17:37imirkin: so could be something in the fbaccel logic which insta-kills it
17:37imirkin: you could try booting with nouveau.nofbaccel=1
17:38bonbons: might be
17:38Lekensteyn: bonbons: a workaround is listed for you at https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-234494238 (ASUS X550VX -> acpi_osi=! acpi_osi="Windows 2009")
17:38imirkin: Lekensteyn: did you mean branau ?
17:38Lekensteyn: imirkin: yes, that was intended for branau (other B)
17:39Lekensteyn: tab-completion laziness of me
17:39bonbons: looks so, autocompletion on first char is bad ;)
17:39Lekensteyn: it works for imirkin (i) at least :-)
17:39karolherbst: it works for k as well :p
17:39karolherbst: ohh wait
17:39karolherbst: it doesn not
17:40Lekensteyn: karolherbst: for me it does!
17:40Lekensteyn: maybe your irc client doesn;t want you to talk to yourself
17:42imirkin: kwizart: the general idea is that boot-time stuff is handled by either vgafb or efifb depending on the type of boot. then the "real" driver takes over.
17:42karolherbst: Lekensteyn: mhh, maybe your client is smarter than mine
17:43branau: Lekensteyn: thanks, I'll give that a shot real quick then. Right now I was doing the nouveau.runpm=0 workaround but would this one allow me to switch between the two cards for better battery life?
17:44imirkin: kwizart: i briefly scanned over your messages, but it was unclear to me what you were trying to achieve. nouveau.modeset=0 allows the nouveau module to load without actually doing anything on load. it is functionally equivalent to the module not loading at all. not 100% sure if you could, after the fact, cause it to bind to a specific pci device - maybe. would have to check the code.
17:46karolherbst: branau: with runpm=0 you can still use your nvidia gpu with nouveau, but it won't turn off
17:46karolherbst: so it mainly idles
17:46karolherbst: sensors might give you even the current power consumption
17:47Lekensteyn: branau: with this workaround the ACPI interaction will not hang and you can indeed turn off the dGPU for better battery life and less heat
17:48Lekensteyn: my dGPU is only active when I have an external monitor attached (I don't need/use DRI_PRIME=1)
17:50imirkin: wow, we really suck at dota2 perf, on all card generations =/
17:50imirkin: i should probably have a look, as it's one of the few games i have access to
17:51karolherbst: imirkin: would be awesome, cause quite a few games use the same engine
17:51bonbons: imirkin: nofbaccel seems not to do the trick
17:52karolherbst: "quite a few" is that several now or only a handfull? :D
17:52imirkin: bonbons: hm ok, oh well
17:52imirkin: karolherbst: well afaik they updated it to use a totally new engine
17:53karolherbst: I see
17:53karolherbst: but it is just a newer source engine I guessed
17:53imirkin: could just be that it's doing something that's defeating our compiler
17:54imirkin: or could be that nvidia gets ahead by having some ext we don't support (e.g. bindless)
17:54kwizart: imirkin, indeed, I'm also using rd.driver.blacklist=nouveau for the module not been loaded, but seems from what you said that I could leave it loaded and bind only if the nvidia module fails to load for some reason
17:54karolherbst: imirkin: most likely the extension thing for lower overhead and so on
17:55imirkin: kwizart: check the code for what modeset=0 specifically does - whether it just stops the driver from actively probing, or whether it makes the probes succeed without doing antyhing. iirc it's the latter.
17:55imirkin: karolherbst: well, we're at like 40% of blob perf, whereas we should be at ... ~70%
17:55imirkin: karolherbst: it's doing relatively worse to other games
18:15karolherbst: imirkin: yeah, I saw
18:15karolherbst: but are you refering to the maxwell benchmarks?
18:15imirkin: kepler too
18:15imirkin: it did especially worse on maxwell, which leads me to believe it's some kind of shader-related failing
18:16karolherbst: mhh, CS:GO is also relativly bad
18:17imirkin: it's within tolerance
18:17karolherbst: not for me :p
18:17karolherbst: anything below 80% is bad
18:18karolherbst: zcull could be a wonderfull gsoc project
18:32bonbons: still bisecting, but apparently one of pm/gr/fifo/disp/dma/cipher conversions...
18:32imirkin: i'm gonna go with gr or disp.
18:33imirkin: if it were fifo, things would be bad for everyone, you don't have cipher. i guess dma? not sure what that is actually...
18:34bonbons: dma is commit bd70563f015a5204c62a52a87a35c32377940187
18:34imirkin: right, i just mean i don't really know what dma is
18:35imirkin: oh, if those stupid dma objects. yeah, probably not that one.
18:35imirkin: [definitely do the bisect for real...]
18:35imirkin: i'm just placing bets =]
18:35bonbons: still doing so, not so many rounds left :)
18:54bonbons: gr and fifo left for last round
18:57mupuf: karolherbst: since I ran out of space, something must have gone wrong during an update or something
18:57mupuf: not supposed to happen, but hey, possible
18:57mupuf: so I am reinstalling all the packages, we'll see
18:57karolherbst: makes kind of sense
18:57mupuf: because even trying to recompile the kernel on reator yields the same result
18:58karolherbst: mupuf: I guess it could be that the gcc update messed up
19:02bonbons: imirkin: bad one is gr, c85ee6ca79590cd51356bf24fb8936bc352138cf
19:03imirkin: (sort of)
19:04bonbons: now finding out what is the bad part of that not so small commit is another matter...
19:05imirkin: i already looked at it pretty carefully
19:05imirkin: one thing i'm confused by is that the tile_prog stuff no longer gets called
19:05imirkin: skeggsb: --^
19:05imirkin: oh wait, nm
19:05imirkin: it is.
19:08imirkin: yeah dunno. it all seems above-board to me =/
19:08bonbons: any way to get some more info at when it gets stuck, e.g. where to spree some printks?
19:08imirkin: i'm a bit confused by the fb/base.c change...
19:09imirkin: oh no, that one makes sense too...
19:12imirkin: bonbons: this is a single-cpu system, right?
19:12bonbons: it is
19:13bonbons: (kernel compiled with CONFIG_SMP is not set)
19:13imirkin: ok, so the issue happens when fbcon turns on
19:13imirkin: which effectively creates a new channel/etc
19:15mupuf: karolherbst: same same
19:15mupuf: what the bloody fuck is going on here? :o
19:16bonbons: following events would be: "fbcon: nouveaufb (fb0) is primary device", "[drm:drm_crtc_helper_set_config]", "[drm:drm_crtc_helper_set_config] [CRTC:25] [FB:39] #connectors=1 (x y) (0 0)", ...
19:17imirkin: bonbons: here's a fun little exercise - could you build with CONFIG_SMP=y and see if that fixes everything?
19:17bonbons: sure, can do so
19:23branau: karolherbst: Lekensteyn well, I ended getting the acpi workaround to work, and everything seems to be working as expected. Thanks again for your help :)
19:36mslusarz: bonbons: if imirkin's suggestion won't help, I guess you could mmiotrace nouveau before and after this commit and compare what changed
19:39mupuf: karolherbst: this is so odd
19:39mupuf: 4.8 compiles normally
19:41mupuf: testing 4.9
19:43mupuf: same for 4.9
19:46mupuf: no idea why make prepare fails :s
19:46mupuf: let's try something else
20:11bonbons: imirkin: CONFIG_SMP=y makes no difference
20:12bonbons: mslusarz: any idea how to mmio-trace until a box freezes hard?
20:12imirkin: bonbons: hm ok. let's hope skeggsb will have an idea of what could be wrong with that commit.
20:13imirkin: bonbons: would you mind applying my change to a working kernel and seeing if it hurts anything?
20:13imirkin: it should apply all the way back to the dawn of time with minimal conflicts, if any
20:14mslusarz: bonbons: oh, I was not aware it freezes like that
20:16bonbons: imirkin: sure, it's building right now
20:17bonbons: I'm trying on top of commit preceding the bad one (13de7f462902d1a452d501cdb2d06ef02cabbfff), that way it's quick to compile
20:17mslusarz: but still, looking at last writes before freeze and comparing them to known working might give some clues
20:18imirkin: i'm guessing that it's more of a driver problem. dunno.
20:19mslusarz: mounting your fs with -o sync should increase a chance of catching everything
20:20karolherbst: mupuf: odd
20:20bonbons: imirkin: in case it helps, display is still in VGA text-mode though with the last lines of output only partially rendered
20:21imirkin: bonbons: you mean the bad kernel?
20:32karolherbst: mupuf: I think I got the issue
20:37karolherbst: mupuf: try gcc-5
20:39karolherbst: mupuf: there is no definition for CC_SET
20:41karolherbst: mupuf: the arch/x86/include/asm/asm.h file was missing some stuff :O
20:49mupuf: karolherbst: I recompiled the 4.10 on reator
20:49mupuf: took ~1h
20:49mupuf: I am installing it now
20:49karolherbst: ohh okay
20:52mupuf: took forever, but here it is, a new kernel
20:52mupuf: and nouveau compiles on it
20:55mupuf: sorry it took so long
20:55mupuf: you are set now though
20:55mupuf: going to bed, see you!
20:55karolherbst: and thanks
20:58bonbons: imirkin: no visible degradation with your patch under fbcon (applied on top of 13de7f462902d1a452d501cdb2d06ef02cabbfff)
20:59imirkin: bonbons: ok cool. mind running X and just seeing if anything obvious goes bad?
21:02bonbons: imirkin: will take some time as userspace is not up do date (X server tool older for modesetting DDX but more recent than nouveau DDX)
21:03imirkin: bonbons: ah ok. well don't worry too much about it. it didn't cause everything to fail, that's a start.
21:04bonbons: well, userspace packages are mostly compiled, though need to be installed (not just as slow as compiling on build host them but still) - it's some just that has to be done anyhow
21:23karolherbst: I don't get the PMUn reset after sec boot... the hell
21:32karolherbst: mwk: what do I have to do to fully reset a falcon?
21:33imirkin: karolherbst: probably toggle the PMC bit with a short wait in between
21:34karolherbst: ohh I think I know what is wrong
21:34karolherbst: only the gr is using that falcon helper library
21:34karolherbst: I guess it makes sense to port the PMU over as well
21:34imirkin: yes, only gr is so far
21:48imirkin: does anyone here use btrfs?
21:48karolherbst: I used to use it
21:50imirkin: why do you no longer use it?
21:50karolherbst: because I got filesystem corruptions and kernel crashes due to sudden kernel crashes caused by nouveau development :)
21:51imirkin: ok, so basically it's still too immature?
21:51karolherbst: I tried to remove an old gentoo-sources package
21:51karolherbst: but my kernel crashed
21:51karolherbst: so I got annoyed
21:51karolherbst: imirkin: well, btrfs is fine as long as you have no fs corruptions
21:52imirkin: so is tmpfs :p
21:52mangix: karolherbst: sorry didn't see your message. my laptop is a clevo p870dm
21:52karolherbst: imirkin: https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing,%20Vault%202016_0.pdf
21:52karolherbst: imirkin: the table says it all :p
21:52imirkin: i like xfs too.
21:53imirkin: ext4 did well though
21:53karolherbst: I think they basically fuzzed the block device
21:53Tom^: i stopped using btrfs when i realized 3 out of my 4 ssds compresses its data anyways
21:53Tom^: hence its a moot point doing it again at FS level :p
21:53karolherbst: but used linux in usermode
21:53Tom^: and i got weird latency issues on various tasks
21:55imirkin: ok yeah. so btrfs is out. i'll stick to xfs.
21:56Tom^: use only btrfs if you want its nifty features
21:56Tom^: not for its stability or speed imo
21:57karolherbst: btrfs can speed up HDDs a lot
21:57karolherbst: by doing compression
21:57karolherbst: I had peak transfer rates of around 350MB/s with HDDs and btrfs
21:57imirkin: not a problem.
21:57Tom^: you could just aswell raid0 xfs or ext4 :D
21:58karolherbst: I could
21:58imirkin: i plan on largely storing compressed files on it in the first place
21:58karolherbst: but compression also reduces used disc space by around 25%
21:58karolherbst: I see
21:59karolherbst: ohh there is still the one glsl bug I reported :D
22:02Tom^: one thing i sort of found interesting but never got the time to test was its snapshot feature
22:06bonbons: imirkin: X with modesetting driver looks fine running evince without desktop environment (xorg-server-1.18.4, mesa-12.0.1)
22:07imirkin: bonbons: ok, thanks for checking!
22:15nyef: Today sucked, drastically. And I still don't have access to my primary disks. But the word is "Ivy Bridge", and the frame-packing modes work with my PS3 display.
22:16imirkin: nyef: ok, good to know
22:17nyef: So, it's not the panels, it's very probably not the hardware at all, it's very probably nouveau.
22:19karolherbst: imirkin: ohh wait, the PMU is indeed ported already
22:34imirkin: nyef: so the simplest thing would be to peek at the various display regs when nvidia sets such a mode
22:34imirkin: getting traces of disp stuff is non-trivial unfortunately
22:34nyef: I don't even know how to persuade the blob to try and set such a mode.
22:36karolherbst: the pmu stays stopped no matter what I try
22:45karolherbst: imirkin: do you think I need to change anything else besides initializing the PMU subdev _after_ the gr engine?
22:45imirkin: it probably needs to be flipped back into LS mode
22:45karolherbst: you mean NS
22:45imirkin: karolherbst: have you tried toggling the engine's PMC bit?
22:45imirkin: er, wtvr.
22:45karolherbst: not yet
22:48karolherbst: imirkin: and there is no switch for it
22:49karolherbst: imirkin: it is done somewhere within the instruction execution part of the falcon itself
22:50karolherbst: I think the only way of getting into LS mode is to have a signed HS firmware which puts the falcon into LS mode :D
22:50karolherbst: not quite sure about this part though, cause we don't have this situation yet
22:51imirkin: you've looked at ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html right?
22:51imirkin: not that it's some super-detailed document ;)
22:51karolherbst: it is pretty much useless
22:51snkcld: glxgears on my intel iris pro gives me 8k fps... but when i use DRI_PRIME=1, thus using nouveau, i get about 3k... does that sound right?
22:52snkcld: i understand that nouveau is not as fast as the nvidia driver, but i am just curious if perhaps there is some setting i could enable to be able to better leverage my video card
22:52karolherbst: imirkin: basically the falcon put itself into HS mode whenever the next instruction is partly or fully within a page marked as signed and secure code
22:52imirkin: snkcld: doesn't sound wrong. glxgears + prime basically measures bus bandwidth...
22:52karolherbst: imirkin: it isn't triggered by jumps or bras or anything like it, but whenever the instruction execution engine notices that the now to execute instruction is part of signed code
22:53snkcld: i noticed this messaged on the nouveu site: "Dec, 2016: Improved reclocking support for GKxxx and GM10x merged into Linux 4.10-rc1", and i am running "4.10.0-rc4+", so i was hoping that my nvidia card would be better
22:53imirkin: snkcld: lspci -nn -d 10de:
22:53snkcld: imirkin: that is interesting. i am not completeyl sure what you mean by that though
22:53karolherbst: imirkin: even returning from an interrupt handler into signed code triggers it and all the signature fun begins
22:53imirkin: snkcld: i mean that looking at things that say more than "100fps" is not a measurement of performance of the gpu.
22:54snkcld: imirkin: ah yea, yea ok
22:54imirkin: snkcld: but rather of some incidental component along the display path
22:54snkcld: imirkin: youre saying that the bottleneck could be the bus
22:54imirkin: snkcld: in this case, most likely the pci bus bandwidth to get the images from one gpu to the other
22:54karolherbst: mhh, the PMC thing indeed disables the PMU fully
22:54snkcld: imirkin: because with DRI_PRIME, it has to copy the data from the secondary gpu to the primary ,correct?
22:54imirkin: snkcld: yes.
22:55snkcld: so if i boot up using my nvidia card instead of intel (since vgaswitcheroo doesnt work on retina mbps) then perhaps i would see a better result
22:55imirkin: snkcld: that said, reclocking isn't automatic - if you want higher clock rates, you have to flip them yourself.
22:55snkcld: imirkin: flip them?
22:56imirkin: snkcld: there's a file, /sys/kernel/debug/dri/*/pstate which shows you the options, current state, and writing to it causes states to change.
22:56karolherbst: the hell :/ what is wrong with that pmu
22:56snkcld: also, this is strange, but when i boot my mbp with the nvidia card selected (gpu-switch -d), i see 4 copies of my gdm login screen... each in a quadrant of the monitor!
22:56snkcld: very weird. i have no idea what is going on lol. but its like... 1/4 of my screen i can see is working perfectly well, but the screen is really small
22:57snkcld: and theres 4 copies of the screen lol
22:57snkcld: any idea what might be going on there? this is only shown when i start gdm. my virtual consoles work perfectly well
22:57imirkin: snkcld: never heard of such an issue.
22:58karolherbst: those IBUS faults on maxwell2 are most likely PMU related
22:58snkcld: imirkin: i do not see the pstate files for the nvidia card at that location
22:58snkcld: oh, sorry
22:58snkcld: i do see them, my apologies
22:59snkcld: when i cat pstate, what is the indication that tells me which one is current?
23:00snkcld: AH. there was none, so i assume its "automatic"... when i echoed a value into it, it became obvious which was current
23:00imirkin: AC is the current state
23:00imirkin: the * is there to fool you into thinking that it's the line with the * that's active. but it's really the last line which shows the current state.
23:01snkcld: imirkin: http://pastebin.com/raw/fJU9ssAS
23:01snkcld: as you can see in the first example, there was no AC
23:01snkcld: do you mean DC?
23:02imirkin: yeah - coz you're not plugged in?
23:02imirkin: anyways, that should be good - you should get better perf, although i dunno if it'd get reflected in glxgears.
23:02snkcld: oh, hah, yea
23:02karolherbst: imirkin: :D I found a workaround
23:02snkcld: well, when now my FPS are way worse lol
23:02snkcld: 340 fps, instead of 3k :)
23:03imirkin: that shouldn't have happened - you should have had even higher pcie bandwidth
23:03snkcld: and it causes the machine to hang for a second or so and the mouse doesnt respond lol
23:03imirkin: can you check dmesg for anything going obviously wrong?
23:03snkcld: quite a few of these
23:03snkcld: asynchronous wait on fence nouveau:glxgears:7ef452f3 timed out
23:03karolherbst: imirkin: suspend after performing secboot.....
23:04imirkin: snkcld: that shouldn't happen...
23:04snkcld: imirkin: what is fence?
23:04snkcld: and async wait?
23:04snkcld: i have a custom configured kernel, fwiw
23:04karolherbst: snkcld: try 4.10
23:04snkcld: i am on 4.10.0-rc4+
23:05karolherbst: imirkin: https://github.com/skeggsb/nouveau/commit/b3816f34944ad4824d345b98c323a30710f492d4 ?
23:05karolherbst: another issue?
23:05snkcld: it looks like the "asynchronous wait on fence" message is inside the i915 driver
23:05karolherbst: I know
23:05karolherbst: wait a second
23:05karolherbst: I know what is causing it
23:06snkcld: it looks like if i select _any_ except for 07 (the lowest) then it behaves like this
23:07snkcld: "like this" being... the gears spin for like, a second, but then the mouse etc do not respond
23:07snkcld: but after another second or so i can move the mouse and ctrl+c quickly before the hang again
23:07karolherbst: ask in #intel-gfx then
23:07snkcld: (and i get the message)
23:08snkcld: karolherbst: is that to me?
23:08snkcld: ok i asked there, thanks
23:08karolherbst: imirkin: okay, so something isn't reseting the pmu right without calling the fini stuff... but putting the machine into suspend and waking it up again leads to the pmu to be started with the nouveau code
23:08karolherbst: and I can reclock without issues
23:11imirkin: did you try frobbing pmc?
23:12snkcld: fwiw: when i set the pstate to the highest, but i enable vsync, it works amazing. in fact, i dare say it works better than the intel graphics. my metric is how well it renders the video game im playing though
23:13snkcld: i think the vsync limits how much its copying data on the bus... so the gpu can operate at a high state, but its on the bus only 60 times a second? so it doesnt occup the bus too much?
23:13snkcld: it seems that if you are offloading GPU... you need to make sure vsync is on so that your GPU doesnt hog the bus... does that make sense?
23:15karolherbst: imirkin: top three commits: https://github.com/karolherbst/nouveau/commits/maxwell2_playground
23:15karolherbst: then a suspend
23:15karolherbst: and the gpu is ready to use for reclocking
23:16karolherbst: should be actually fine on mobile systems where the gpu is suspended anyway
23:16karolherbst: will figure out what is missing to reset the pmu to be able to use it without suspending though
23:16imirkin: karolherbst: what are you testing on btw?
23:17imirkin: ah ok
23:18karolherbst: that one pmu commit is to prevent freezes inside the kernel when the PMU doesn't respond
23:18snkcld: is there any way i can have nouveau.pstate automatically increased/decreased with the load/
23:18imirkin: snkcld: there is no automatic reclocking at this time.
23:18imirkin: snkcld: however the gpu should suspend itself when it's not used
23:18snkcld: imirkin: so even if i leave it on 07, the fastest, i should not be too worried about power consumption?
23:19imirkin: i believe in your case 0f is the fastest. but yeah, it should be fine, while you're not playing games.
23:20snkcld: sorry, thats what i meant, 0f
23:20karolherbst: I really should get my last reclocking patches landed :(
23:20karolherbst: they fix so many annoying issues for mobile chips
23:21karolherbst: snkcld: the gpu will be set to default clocks again after resuming though
23:22snkcld: unfortunately that does not look to be hte case
23:22snkcld: so, GPU on, set to 0f, the fastest, my machine draws ~55W
23:22snkcld: when nothing is using DRI_PRIME=1
23:22karolherbst: check the clients
23:22snkcld: i can confirm nothign si using the card because i am able to turn it off via vgaswitcheroo
23:23snkcld: as soon as i turn it off, the power drops down to ~30W
23:23snkcld: turning it back on, it jumps up to 55ish
23:23karolherbst: it should be set to dynoff
23:23snkcld: where can i confirm dynoff?
23:23karolherbst: it should be the default
23:23karolherbst: you don't need to manually turn off the card via vgaswitcheroo
23:23snkcld: (i hate to bother you, but i am actually interested in contributing to this part of the kernel, whic his why i am trying to understand all this)
23:24karolherbst: I have a nice issue for you then :D
23:24snkcld: thats great!
23:24karolherbst: but not now
23:24karolherbst: have to sleep
23:24snkcld: ok :)
23:24snkcld: well, firstname.lastname@example.org
23:24karolherbst: snkcld: https://trello.com/c/fndxUee1/92-clock-gating-fermi
23:24imirkin: snkcld: is your kernel built with runtime pm?
23:24snkcld: imirkin: uh, whats the CONFIG_ naem?
23:24imirkin: snkcld: don't remember... CONFIG_RUNTIME_PM? :) might not existing anymore, i forget
23:24karolherbst: snkcld: install envytools
23:25imirkin: snkcld: do you have a vgaswitcheroo file?
23:25imirkin: in debugfs
23:25snkcld: i do
23:25karolherbst: snkcld: nvapoke 0x20200 0x60 27722455
23:25karolherbst: this should reduce the power consumption as long as the gpu is turned on
23:25snkcld: i use vgaswitheroo and it works well to turn off the background gpu
23:25karolherbst: not much, but a little
23:25snkcld: karolherbst: trying that now
23:25imirkin: mmmm ... should be automatic. unless your platform doesn't support it.
23:25snkcld: currently at 55W, with fastest pstate turned on, will run that command now:
23:26karolherbst: snkcld: is your gpu listed in sensors?
23:26snkcld: shoot, i dont have nvapoke
23:26snkcld: karolherbst: yea
23:26karolherbst: also its power consumption?
23:26snkcld: sorry, i apologize, i do _not_ see nvidia in sensors
23:27snkcld: coretemp-isa-0000, and applesmc-isa-0300
23:27snkcld: i measure power consumption by looking at powertop
23:27karolherbst: ohhh I see
23:27snkcld: i am not changing any other factors though, the only thing i cahnge is enabling /disabling the card via switcheroo
23:28snkcld: GPU ON+0f = 55W, GPU ON+07=~40W
23:28karolherbst: anyway, have to sleep now
23:28snkcld: GPU OFF via vgaswithcer oo ~30W
23:28karolherbst: good night
23:28snkcld: ah, karolherbst thanks
23:28snkcld: imirkin: where can i find envytools
23:28snkcld: oh, found it
23:30snkcld: that nvapoke command seems to have brought the power usage down from 55W to 50W
23:31imirkin: snkcld: can you pastebin the contents of the switcheroo file?
23:31snkcld: imirkin: sure
23:32imirkin: ok, so there's no automatic switching
23:32imirkin: so you have to flip it on and off yourself =/
23:32imirkin: silly macs.
23:32snkcld: yea, the retina doesnt have that
23:33snkcld: something about the gmux and the DDC or EDID? i have no idea lol
23:33snkcld: i have been emailing lukas wunner to try to understand, and he's great at explaining, but i just cant wrap my head around it lol
23:33snkcld: imirkin: how can you tell from that
23:33snkcld: *from that output, that i do not have automatic switching?
23:33imirkin: it says DIS instead of DynOff or DynPwr
23:35snkcld: i thought DIS meant discrete?
23:35snkcld: are you saying it indicates the power management type?
23:37imirkin: it would automatically switch on/off if you had an acpi-based method
23:38snkcld: maybe i should just get rid of this thing and get a regular laptop
23:38snkcld: i mean, whats the point developing for gmux, whenever optimus is more common?
23:39snkcld: no one else uses a hardware mux for graphics, right? i should focus on optimus i would think