00:07 RushPL: how to disable GPU power via nouveau? I've got `/sys/class/drm/card1/device/power/control` here. The only two options that work are `auto` and `on` for me :P is there some magical value for off?
00:19 imirkin: RushPL: are you on a laptop?
00:19 RushPL: yes but nvidia is not wired to any output.
00:19 imirkin: RushPL: as long as you have vga switcheroo enabled, the gpu should power itself off in that case
00:20 RushPL: please explain vga switcheroo
00:20 imirkin: it's a kernel config option
00:20 imirkin: CONFIG_VGA_SWITCHEROO if i recall
00:20 imirkin: or something similar if i don't
00:23 RushPL: rushpod:/home/rush # cat /sys/kernel/debug/vgaswitcheroo/switch
00:23 RushPL: 0:DIS: :DynOff:0000:02:00.0
00:23 RushPL: 1:IGD:+:Pwr:0000:00:02.0
00:23 RushPL: can I force it off?
00:23 imirkin: DynOff means "off"
00:23 imirkin: until you try to use it, at which point it'll resume
00:24 imirkin: e.g. via DRI_PRIME=1, or some other mechanism
00:25 RushPL: I see, I thought that my power usage of 20W meant that the Nvidia chip is on
00:25 imirkin: unfortunately there's no great way to super-confirm it
00:25 imirkin: because doing something like lspci will wake it right back up
00:26 imirkin: you could use powertop to figure out where that power is going
02:33 mark4: i need help. im currently using nvidia-drivers but the most recent version that supports my video card forces me to stay on kernel 4.1.x which is unacceptable to me
02:33 mark4: problem is, this machine is hybrid and the nvidia card has NO access to the display port other than thru the intel pile of shit
02:36 airlied: stay on kernel 4.1 is probably the only good answer
02:37 airlied: assuming you want to keep the performance of the binary drivr
02:38 mark4: if i get back to work ill look into replacing this laptops graphics card for an ATI. it mignt be am option
02:38 mark4: though it might not
02:38 mark4: if not i just consign this machine to lower performance gaming
02:38 mark4: it only cost slightly under $3000
02:39 mark4: does nouveau support hybrid graphics where the nvidia GPU has NO direct access to the display port?
02:41 airlied: it's more nouveau doesn't support the power management that makes it faster than the intel
02:41 mark4: being worked on?>
02:41 mark4: i dont care if i take a performance hit right now
02:42 mark4: as long as IT WORKS and with recent kernels
02:42 mark4: not one thats a year old
02:42 imirkin: mark4: which gpu do you have?
02:42 mark4: which in one year will be two years old
02:43 imirkin: airlied: with karol's branch, reclocking works pretty well actually
02:43 imirkin: airlied: been that way for ~6 months or so
02:43 mark4: 01:00.0 VGA compatible controller: NVIDIA Corporation GM204M [GeForce GTX 965M] (rev a1)
02:43 imirkin: mark4: ah yeah, nouveau won't get you good perf. but it'll suspend the gpu for you... probably.
02:43 mark4: imirkin, probably doesnt give me confidence
02:44 imirkin: mark4: note that this is a very new gpu, so i'd be surprised if latest kernels weren't supported
02:44 mark4: the latest kernels are NOT supported
02:44 mark4: the most recent kernel that supports it is 4.1.x
02:44 mark4: which is a year old
02:45 imirkin: that's plainly not the case.
02:45 imirkin: nvidia blob supports more recent kernel versions.
02:45 mark4: if this is a NEW gpu why do new drivers NOT support it
02:45 imirkin: they do. however this is not the proper place to ask about that. ask in the nvidia forums or whatever.
02:45 mark4: the most recent version of nvidia-drivers that supports this card is 358.x
02:45 airlied: sounds like a distro problem
02:46 imirkin: anyways, starting with kernel 4.6, nouveau has very basic acceleration support for GM20x, assuming you get the non-free firmware
02:46 mark4: oh. actually the problem is nvidia-drivers PLUS kernel version
02:46 imirkin: however there's no reclocking or anything of that sort
02:46 imirkin: so perf should be quite low
02:47 mark4: well im going to TRY switch to nouveau. if that doesnt work i know kernel 4.1.x and 358.x work :/
02:47 mark4: the problem i foresee is getting the modesetting working :(
02:58 imirkin: mark4: if you want reliable open-source support, definitely go with AMD next time.
03:04 mark4: imirkin, it was not an option on this laptop
03:04 mark4: nouveau has improved by leaps and bounds over the last year
03:05 mark4: im using it on this non hybrid laptop and can even play wow now
03:23 mark4: ok now i have nouveau installed and with 4.6.4 its doing the same thing that nvidia did
03:23 mark4: desktop -> solid black display -> desktop -> solid black repeatedly
05:17 mark4: reverted to kernel 4.5.3 which worked with nvidia drivers but rebuilt kernel for nouveau
05:17 mark4: i no longer have the entire screen flicking back and forth between a visibile desktop and a black wall
05:17 mark4: now only the bottom inch and a half of the display does so
05:18 mark4: opened a terminal and the flicking back and forth has stopped sort of
05:19 mark4: my cairo dock at the bottom has a little tick that flickers back and forth between two of the icons docked to it
05:19 mark4: like a little underscore cursor but not the cursor
05:19 mark4: i dont think nouveau is even playing any part in this display
05:20 mark4: i think this is pure intel garbage
05:21 mark4: i killed X and did a startx from an ssh session into the box
05:21 mark4: Could not find provider with name modesetting
06:14 s0be: Is nouveau PM still hoarked in linux next?
08:41 Lekensteyn: s0be: in what sense? Do you have a modern (2015+) laptop?
08:42 s0be: yep
08:42 s0be: somtime post rc3 my system stopped booting -next due to a RCU deadlock in the PMOps path to Nouveau
08:43 Lekensteyn: s0be: please try https://lists.freedesktop.org/archives/nouveau/2016-July/025607.html
08:44 s0be: just the 1 patch? I'm only seeing 4/4
08:44 Lekensteyn: the ordering is somehow messed up, if you click through you'll see all of them
08:44 s0be: ahh, 1-3 weren't in reply to 0/4
08:46 Lekensteyn: for your convenience https://git.lekensteyn.nl/peter/linux/log/?h=nouveau-acpi-v3
08:48 s0be: already git apply'd em
08:48 s0be: but thanks
08:49 Lekensteyn: what laptop do you have btw?
08:49 s0be: lenovo p50
08:51 Lekensteyn: would you mind generating a tarball as described at https://bugs.launchpad.net/lpbugreporter/+bug/752542?
08:52 s0be: no problem, where do you want it attached?
08:53 Lekensteyn: ideally that bug, but if you don't have a LP account you can link it here (or mail it to me) and I'll put it on
08:53 s0be: No problem to create a LP account, will do that.
08:54 Lekensteyn: thanks in advance :)
08:54 s0be: Lenovo has been dropping new bioses pretty regularly for this system, I'm 1 rev behind right now, fyi.
08:58 s0be: man, LP keeps timing out
08:58 Lekensteyn: if you posted once, do not retry
08:58 s0be: haven't gotten the comment box to appear yet
08:58 Lekensteyn: ah, that bug is probably not a best-case scenario for LP :P
09:00 s0be: there, uploaded
09:05 Lekensteyn: got it, thanks. The patches should work for you
09:05 s0be: nice, just waiting for a VM to finish a build, then will shut the vms down and reboot into the new kernel
09:17 s0be: k, rebooting. bbiaf
09:23 karolherbst_work: Lekensteyn: any ETA for those patches?
09:24 Lekensteyn: karolherbst_work: I'm ready, I'm waiting for acks from other devs and for Dave (or whoever is temporarily in charge while he is having vacation) is picking them up ;)
09:24 karolherbst_work: nice
09:24 karolherbst_work: I think I can test both methods on my system :)
09:25 Lekensteyn: the HDMI audio issue is a non-issue now, so there is no blocker now
09:25 karolherbst_work: either entire bus is off, or only the card is off
09:25 karolherbst_work: Lekensteyn: so, fixed by no use case available?
09:25 karolherbst_work: *existent
09:25 Lekensteyn: fixed by does not occur normally
09:25 Lekensteyn: which is good enough
09:25 Lekensteyn: if you really need it and do a remove/rescan, then you know what you are doing and a workaround is available
09:25 karolherbst_work: would be too much effort for like 0.01% of all users anyway :p
09:26 Lekensteyn: 0.01% of the 0.1% users :p
09:26 karolherbst_work: ohh wait
09:26 karolherbst_work: you mean the audio device still disappears
09:26 karolherbst_work: :/
09:26 karolherbst_work: well, that should be fixed though
09:26 Lekensteyn: it does not "disappear", it just does not appearnormally
09:27 karolherbst_work: mhhh
09:27 karolherbst_work: on resume always rescan the parent port?
09:27 karolherbst_work: or is a _remove_ technically required
09:27 Lekensteyn: there is no rescan on resume
09:27 Lekensteyn: I don't think that the remove is techncally needed, but without it the rescan does not show the audio device
09:27 karolherbst_work: could work if there would be a rescan
09:28 karolherbst_work: either on the resumed device or the parent thing
09:28 karolherbst_work: depends on the topology I guess
09:28 Lekensteyn: that sounds contradicatory, but on Windows I don't see the video device disappearing
09:28 karolherbst_work: Lekensteyn: I think it might be a sysfs API thing, that's why I am asking
09:28 Lekensteyn: would have to ask linux-pci if this is normal behavior
09:29 karolherbst_work: Lekensteyn: the video device disappears though. The kernel has to cache, that it was there at least once
09:29 karolherbst_work: Lekensteyn: turn off gpu, remove gpu => gpu is gone for good
09:29 karolherbst_work: I mean remove over sysfs ;)
09:29 Lekensteyn: video dev disappears when it is in D3
09:29 karolherbst_work: does the bus disappears too?
09:30 karolherbst_work: rephrase
09:30 karolherbst_work: does the bus go into suspend, too?
09:30 Lekensteyn: yes it will
09:30 karolherbst_work: mhhh
09:30 karolherbst_work: I think it is a kernel thing in the end
09:30 karolherbst_work: if the bus is off, there won't be any answers if something is there
09:30 karolherbst_work: so the kernel won't find any devices anyway
09:31 karolherbst_work: so it has to remember, that something _is_ actually there
09:31 Lekensteyn: but on systems using this PR3 (win8+), the PCIe port is responsible for toggling the power
09:31 Lekensteyn: so once the PCIe port powers the link, the video device is accessible again
09:31 karolherbst_work: right, and when you resume the bus, you have to rescan I think
09:31 Lekensteyn: for the video or audio device?
09:31 karolherbst_work: both
09:31 karolherbst_work: just rescan the bus
09:31 karolherbst_work: if the bus was off
09:32 karolherbst_work: at least this is something that might work in the end
09:32 Lekensteyn: I think that the nouveau driver has to do something first before rescanning (to enable the audio port when a HDMI link is detected)
09:32 karolherbst_work: I doubt it though
09:33 karolherbst_work: mhh maybe it has to
09:33 karolherbst_work: the gpu wakes up in a pretty messed up state
09:33 karolherbst_work: and it has to be posted by nouveau
09:33 Lekensteyn: there is this magic 0x1B function of the DSM method which seems related to enabling audio
09:33 Lekensteyn: yes that could also be the trigger
09:33 karolherbst_work: yeah, doing that over ACPI should be the cleaner variant
09:33 karolherbst_work: because, a driver might not be there
09:34 karolherbst_work: if nouveau causes a device to disappear, nouveau has to trigger a rescan, but if runpm does it, runpm has to rescan and enable everything needed
09:34 karolherbst_work: or add callbacks for stupid stuff like that
09:35 karolherbst_work: runpm_resume_subdevices or so
09:36 karolherbst_work: but I think rescanning the bus isn't a bad idea in general
09:36 karolherbst_work: maybe somebody turned of the bus, and a new device is plugged in on that bus in the meantime
09:37 s0be: Lekensteyn, something added in -next on the 20th stopped it from booting on my system entirerly, and it's too late at night to dive into finding it. Will test the 19th tree with the patch tomorrow.
09:38 Lekensteyn: s0be: that is unfortunate, have a good rest and see you later then
09:38 inglor: How is nouveau support for 10XX cards? (too soon to ask?)
09:38 karolherbst_work: inglor: it should have very basic support
09:39 karolherbst_work: the most basic possible I guess
09:39 inglor: I was expecting - Not supported yet.
09:39 karolherbst_work: well
09:39 inglor: as to buy one it's really a problem now with no stock
09:39 karolherbst_work: you should be able to use the modesetting ddx
09:40 s0be: Lekensteyn, ooh, have a 7/15 tree sitting here I know boots, patched and building
09:40 s0be: (was running it with nouveau blacklisted)
09:40 inglor: ok, thanks for now 690 covers me anyway
09:40 Lekensteyn: s0be: fun :) you could build just the nouveau module and test
09:41 s0be: I don't keep that many trees laying around
09:42 Lekensteyn: are you using linux-next as daily driver?
09:42 s0be: no
09:42 s0be: 4.6 right now as my daily driver
09:42 s0be: but my skylake gpu is glitchy as heck on it
09:43 s0be: and I'm too lazy to battle merging all the drm trees onto a kernel to get the newer work
09:44 Lekensteyn: could it be the intel ddx that is glitchy? on my SKL I also experience a panel that sometimes turns black after DPMS/suspend, but that is "fixed" by triggering DPMS again (error is about DP link training failing)
09:44 s0be: my glitches are actual screen glitching in chrome
09:45 Lekensteyn: are you using the modesetting DDX or the intel one?
09:45 s0be: intel
09:45 Lekensteyn: try modesetting
09:45 hakzsam: inglor, 3D is working on GP100, but only basic support on GP104 (no firmwaare yet)
09:47 s0be: final test of the night, 7/15w/patch
09:49 Lekensteyn: drumrolls...
09:49 s0be: Worked, thanks
09:49 s0be: DRI_PRIME and all tested
09:51 s0be: still doesn't like the _DSM method in my acpi tables, but that's not fatal at least
09:52 Lekensteyn: you mean the type (Buffer vs Package)? That is harmless
09:52 s0be: yeah
09:53 Lekensteyn: apparently Nvidia's Windows driver (or specification) was buggy and specified the type to be Buffer while the ACPI spec requires Package
09:54 s0be: so it warns once and falls back?
09:54 Lekensteyn: so firmware developers decide to adapt to what the driver does and ignores the spec here because adhering to the spec would break the (older?) drivers
09:54 s0be: business as usual then
10:39 drathir: mornin/evenin...
10:39 drathir: guys when nouveau blacklisted the optimus detection is automagically disabled?
10:53 Lekensteyn: drathir: optimus is a software feature, so if you disable nouveau "optimus" won't work. But it does not mean that the limitations are magically gone
17:33 amfern: pwd
17:37 Lekensteyn: /home/amfern
17:38 Calinou: /home/amfern/Music/Cool 90s Music/Very Nice/Awesome/BSOD_If_You_Enter_This_Folder/pron
17:42 amfern: kek
17:47 amfern: do you need help with https://bugs.freedesktop.org/show_bug.cgi?id=94990
17:49 imirkin_: amfern: what's the issue precisely? unfortunately multiple people have commented on that bug, making it very difficult to tell what the real issue is
19:03 amfern: black screen and fifo: read fault at 00ffb90000 engine 1f [] client 03 [DNISO] reason 0d [REGION_VIOLATION] on channel -1 [0000000000 unknown]
19:06 amfern: it began after adding secure boot and continued with missing firmware files, now after the firmware is successfully loaded, it fails on something else with fifo read errors in the log
19:07 imirkin_: "on something else" isn't extremely specific
21:01 mupuf: YEAH! Life is strange is on Linux!
21:01 hakzsam: yep
21:02 imirkin_: ?
21:02 mupuf: imirkin_: it is a very cute game
21:02 imirkin_: ah
21:02 mupuf: only saw it on youtube
21:03 mupuf: but it just got ported on linux, by feral
21:03 imirkin_: k
21:03 mupuf: the first episode is free
21:03 imirkin_: gotcha
21:03 imirkin_: does it work with nouveau? :)
21:03 mupuf: well, no idea yet
21:03 mupuf: downloading it right now (bought the 5 episodes)
21:04 mupuf: will check intel first though
21:04 imirkin_: i see how it is.
21:04 imirkin_: anyways, i think they're open to providing keys if stuff is broken. although i guess i'll be able to get the first episode for free.
21:06 mupuf: yep
21:07 imirkin_: heh. on windows, recommended GTX 260 (nva0). on linux, recommended 7xx series.
21:10 imirkin_: sounds like a gamified version of the butterfly effect
21:11 mupuf: HEHE
21:11 mupuf: yeha
21:11 hakzsam: is there a way to have a list of expected fails with piglit?
21:27 mupuf: hakzsam: what the fuck would this mean?
21:28 mupuf: you mean, fails from the common code?
21:28 mupuf: I can run piglit on the same commit on my hsw
21:28 mupuf: that should help you do this
21:28 imirkin_: hakzsam: i believe janesma has a setup like that with jenkins
21:28 imirkin_: hakzsam: what you really want is to generate the summary output taking those expected fails into account
21:28 hakzsam: mupuf, having a list of tests which are expected to fail but which don't appear in the report
21:29 imirkin_: hakzsam: normally i just look at a diff of two runs to see what change
21:29 mupuf: imirkin_: yes, that;s the way to go
21:29 mupuf: janesma's system is doing just this
21:29 hakzsam: imirkin_, yeah, usually I do the same thing, but I would like to improve it
21:29 mupuf: but since it does not run twice, it keeps track of the fails and what introduced them
21:30 mupuf: hakzsam: then I would suggest ezbench :D
21:30 hakzsam: hehe
21:30 mupuf: it would check it out for you and tell you which commit introduced what, if you give it enough time
21:31 hakzsam: yeah, that would be nice
21:31 mupuf: so, life is strange seems to work
21:31 imirkin_: mupuf: is your tk1 properly set up btw? i might want to try getting the astc_sliced_3d ext working.
21:31 mupuf: there are some weird reflections, but it seems expected
21:31 mupuf: imirkin_: well, it is ... provided you add this little patch for GBM
21:31 hakzsam: mupuf, nouveau or intel?
21:32 mupuf: intel
21:32 imirkin_: mupuf: huh? i just use WAFFLE_GBM_DEVICE -- iirc this works fine.
21:32 hakzsam: okay
21:50 mupuf: imirkin_: well, not really no
21:50 mupuf: there is a fencing issue
21:51 imirkin_: mupuf: huh ok. i thought it worked last time i tried it.
21:51 mupuf: and sometimes, it does not exit
21:51 mupuf: just waiting a minute to timeout
21:51 mupuf: as for the game, it seems fine
21:52 mupuf: some z fighting here and there, but I guess that's what a cheap port brings you :)
21:52 mupuf: AA would help here
21:52 mupuf: but my hsw would not like this :p
21:54 imirkin_: mupuf: on nouveau or i965?
21:56 hakzsam: imirkin_, btw, do you plan to look at the BGRA regression today?
21:56 imirkin_: no... did you bisect it to my change?
21:56 imirkin_: also does it happen on kepler?
21:57 hakzsam: nope, but it's pretty obvious :)
21:57 hakzsam: can't test on kepler
21:57 hakzsam: imirkin_, I will bisect and send you the relevant info
21:57 imirkin_: try reverting my commit
21:57 imirkin_: nah, just revert my commit and see if that fixes thing
21:57 hakzsam: sure
21:58 hakzsam: I just didn't investigate on that one
21:58 hakzsam: [not even tried a revert]
21:58 imirkin_: if that fixes, i'm going to check on my kepler
21:58 imirkin_: and if i can repro the issue there, i'll try to fix it
21:58 imirkin_: otherwise i'll just make it not do that on fermi and move on
21:58 imirkin_: as it's likely an issue in the state validation
21:59 imirkin_: or something else i won't be able to debug without playing with it
22:01 hakzsam: imirkin_, reverting 8e7893e - nvc0: add support for BGRA8 images fixes bin/mesa_pack_invert-readpixels
22:01 imirkin_: cool
22:01 imirkin_: iirc that piglit had some sort of issues
22:01 imirkin_: when nha's thing landed
22:02 hakzsam: okay
22:02 imirkin_: st/mesa: fix readpixels regression with MESA_pack_invert
22:02 imirkin_: hm
22:03 hakzsam: but that one is not the only regression
22:03 hakzsam: for example /home/hakzsam/programming/piglit/bin/pbo-read-argb8888 -auto
22:03 imirkin_: k
22:03 imirkin_: can you reply to the email with that patch and mention what fails?
22:04 hakzsam: sure, ok
22:04 imirkin_: also, out of curiousity, does it help if you run them with -fbo -auto?
22:09 mupuf: imirkin_: on i965
22:10 mupuf: hakzsam: can I plug the gm2xx now?
22:10 mupuf: karolherbst asked for it a while ago
22:11 hakzsam: imirkin_, no
22:12 mupuf: hakzsam: gm2xx?
22:12 hakzsam: mupuf, your call
22:13 hakzsam: mupuf, reator is off
22:13 hakzsam: replace the gm107 please
22:13 hakzsam: because two maxwells is useless :)
22:14 mupuf: oki
22:15 hakzsam: mupuf, I will probably launch piglit this night
22:15 mupuf: want to keep a fermi?
22:15 mupuf: I can put any other card
22:15 hakzsam: fermi yes
22:15 hakzsam: still need to fix some regressions
22:16 mupuf: cf then, to add datapoints
22:17 mupuf: actually, c0 and gm206
22:18 hakzsam: cool
22:18 mupuf: because we never tested the c0 and it was a bit of a rocky start for fermi
22:18 hakzsam: err, no
22:18 hakzsam: can plug the gf119?
22:18 hakzsam: or gf114?
22:18 mupuf: why?
22:18 hakzsam: because if the c0 is weird I won't see the regressions?
22:19 hakzsam: I just don't want to change the card all the time also :)
22:19 mupuf: I see
22:20 mupuf: # modprobe mouveau
22:20 mupuf: modprobe: FATAL: Module mouveau not found in directory /lib/modules/4.6.0-rc7-NV-29194-g7c10ddf
22:20 mupuf: reload_nouveau.sh did work
22:20 karolherbst: there is a reload nouveau script...
22:21 karolherbst: why didnt anybody tell me :D
22:21 mupuf: well, src/nouveau/drm
22:22 mupuf: anyway, hakzsam I would rather have you run piglit on the c0 and me plugging the gf119 when leaving tomorrow morning
22:23 hakzsam: mupuf, okay
22:23 mupuf: and check out if you manage to get anything out of this maxwell too :)
22:25 hakzsam: I won't run two piglits at the same time :)
22:27 mupuf: you can run them back to back ;)
22:28 hakzsam: are you using reator?
22:28 mupuf: nope, go for ity
22:30 hakzsam: okay
22:39 hakzsam: it's running
23:12 hakzsam: piglit is sooooo long
23:13 hakzsam: more than one hour for a full run now