00:29imirkin: gnurou: btw if you have any ideas about tk1 stability, would love to hear them. i played with it some more... same thing.
00:30imirkin: any time i start hitting nfs, it dies
00:30gnurou: imirkin: well basically my Jetson TK1 is very stable, although I haven't touched it recently
00:30gnurou: but I used 4.3 without any issue
00:30gnurou: have you tried with my kernel?
00:32imirkin: gnurou: no... but i have my own 4.4 kernel
00:32imirkin: gnurou: i had to use a post-4.3 kernel coz you changed the firmware locations iirc :p
00:36gnurou: well it's not hard to move these files around ;)
00:36imirkin: as long as you know what to call them :)
00:36gnurou: and you *may* want to use an out-of-tree Nouveau driver anyway
00:36imirkin: [and yeah, i could have looked it up... but i'm lazy]
00:36imirkin: yeahhhh.... that's step 2
00:37imirkin: anyways, nouveau's not at all involved in the crashes
00:37imirkin: i don't even have it loaded
00:37gnurou: and you don't even get a stack trace, right?
00:37imirkin: perhaps over serial or on the console
00:37imirkin: but i can't hook a monitor up
00:37gnurou: can I get the SHA of your kernel tree?
00:37gnurou: and you are using tegra_defconfig, right?
00:38gnurou: which config then?
00:38imirkin: gnurou: http://hastebin.com/bupalahowe.vbs
00:42gnurou: and how has this one been generated?
00:42gnurou: I'd suggest trying with tegra_defconfig - if that also doesn't work, please send me your kernel binary and I will boot it on my board
00:42imirkin: ok, next time i play around with it i guess
00:42gnurou: I'm using NFS too, so it should be easy to confirm
00:43gnurou: but if the crash happens as soon as you touch NFS, this means your boot does not even go to completion, right?
00:43imirkin: if past experience carries forward, i guess that should be in 4-5 months :)
00:43imirkin: nah, it boots fine
00:43imirkin: and NFS works
00:43gnurou: ark, I should probably try before that :)
00:43imirkin: but as soon as i do anything intensive, it dies
00:43imirkin: like "make" or even sometimes tab completion
00:43gnurou: ah, interesting
00:44imirkin: [why do i run make on that board? because cmake is an abomination that should be exterminated]
00:45imirkin: gr. i hate heuristics. they never work perfectly :(
00:47gnurou: well I have to run waf on the board myself to compile glmark2... because every single build system is an abomination that should be exterminated
00:50imirkin: say what you will about autoconf... it handles everything i've ever needed quite nicely and in a very regular manner
00:50imirkin: including cross-compilation
01:01karolherbst: imirkin: what what if cmake was there before autoconf, which would you prefer then ;)
01:01imirkin: karolherbst: the one that handles all the standard use-cases nicely
01:02imirkin: karolherbst: ./configure --help is *really* useful. and the fact that those options are always named in the same way. and the fact that you can cross-compile.
01:02karolherbst: well you can also crosscompile with cmake
01:02imirkin: it's not impossible
01:02karolherbst: it is
01:02imirkin: but it's a herculean effort
01:03karolherbst: I've done it several times
01:03imirkin: let me know when you get piglit cross-compiling.
01:03karolherbst: well you have to specify the compiler to be used yourself
01:03karolherbst: on which systems does piglit run?
01:03imirkin: on ones where you want to test GL
01:03imirkin: like... little ARM boards
01:03mupuf: imirkin; cmake is equally painful as autotools for cross compiling
01:04mwk: yeah, crosscompiling with automake is quite nice, as long as the package doesn't ask for funny tests performed by running compiled code
01:04imirkin: mupuf: autoconf makes it trivial to cross-compile unless you go out of your way to fuck it up
01:04imirkin: mupuf: with cmake you have to _really_ want it to be able to cross-compile
01:05karolherbst: imirkin: CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are usually enough
01:05mupuf: I used cmake to cross compile for some funky cpus (APS3) and had absolutely no problems
01:05karolherbst: except when you have to mess with paths
01:05karolherbst: or the project has bad path handling
01:05mupuf: karolherbst: yep
01:05imirkin: karolherbst: except this and except that and except that. do they make it easy to have the "excepts"?
01:06mupuf: imirkin: autotools is nothing but excepts :D
01:06karolherbst: no, but project always have messed up path handling
01:06imirkin: i.e. does the "except" end up including ~every project that uses cmake?
01:06mupuf: you just know them all :p
01:06imirkin: with autoconf, basically every project is cross-compilable
01:06mupuf: mesa's build system is the worst I ever had to deal with :D
01:06karolherbst: imirkin: haha, no :p
01:06imirkin: i run into a few every so often, but it's rare
01:06imirkin: mupuf: as a developer, or as a user?
01:06karolherbst: well known projects are usually cross-compileable
01:06imirkin: mupuf: i'm talking about as a user.
01:06karolherbst: which is also true for cmake projects
01:07imirkin: karolherbst: for big popular ones, sure. but any project using autoconf will work.
01:07imirkin: in a standard way.
01:07imirkin: (standard to the user)
01:07karolherbst: but finding the right libraries is a mess on cmake a bit, because it doesn't want to use static generated files for that, it can, but not many use this feature
01:07mupuf: imirkin: how about we have a look at what is happening with the cmake project you cannot cross compile?
01:07mupuf: because the discussion will go nowhere otherwise :D
01:07imirkin: mupuf: piglit.
01:08imirkin: mupuf: i tried for like an hour and couldn't make any progress.
01:08karolherbst: piglit doesn't even compile out of tree
01:08imirkin: this was like a year ago
01:08imirkin: or two
01:08imirkin: there was no easy --build --host options
01:08imirkin: and no --help to figure things out
01:10karolherbst: imirkin: and what happens when you simply specify CMAKE_C_COMPILER and CMAKE_CXX_COMPILER ?
01:10imirkin: karolherbst: iirc nothing good. i couldn't even get it to use distcc.
01:11karolherbst: maybe CMAKE_FIND_ROOT_PATH also has to be specified if it picks up the wrong libraries
01:15karolherbst: I try to cross-compile for mingw, but for that I have to update my toolchain agian for that :/
01:17imirkin: you don't have to solve it
01:18imirkin: i'm perfectly happy living with the knowledge that i hate touching any project that uses cmake :)
01:18karolherbst: nah, I just want to try out if the newest mxe branch works
01:18karolherbst: they ship a nice cmake toolchain file which you can simply use
01:30mupuf: cmake -DCMAKE_TOOLCHAIN_FILE=cmake_gcc_arm.cmake .
01:30mupuf: cmake_gcc_arm.cmake: http://pastebin.com/dDgjmcsE
01:30mupuf: that should do the trick
01:30mupuf: and you can reuse the toolchain for eveyr project, which is very neat
01:31mupuf: I would need to compile deps to test more
01:32karolherbst: I think the CMAKE_FIND_ROOT_PATH is a thing which gets wrong mostly :/
01:33karolherbst: this is maybe the most ugly part of cmake anyway
02:45karolherbst: mupuf: okay, so the pmu stuff is rock solid now
02:45karolherbst: mupuf: was testing my dyn reclock stuff for three days now and we don't have any problems with around 3 reclocks per second (alogorithm isn't perfect yet, but I think it is much better than my first ideas)
02:45mupuf: karolherbst: great to hear! One less issue :D
02:46mupuf: what did you change?
02:46karolherbst: being less smart
02:46karolherbst: well, I think the idea is quite nice actually
02:47mupuf: good is dumb .... err, dumb is good ! (https://www.youtube.com/watch?v=U7XVcqZodAM )
02:47karolherbst: the pmu just checks the load every 0.1 and saves the values where it requests a reclock on the host and only requests a new one when the values go more away from the target
02:47karolherbst: like if the target is 90
02:47karolherbst: and if it sees the load goes above 90 +-5 (safety margin) it requests
02:48karolherbst: if it requests at 70 and doesn't get any acks, it will only requests at 69 or below again, and so on
02:48mupuf: that will lead to a lot of interrupts
02:48karolherbst: why should it?
02:48mupuf: but better than before
02:48karolherbst: as long as the load is stable, no interrupt will happen
02:48mupuf: well, they are rate limited to 10Hz, so I guess it is fine
02:48karolherbst: well we could have a bigger safety margin though
02:49karolherbst: I have some troubles with clocking around the target
02:49mupuf: yes, we need to have something of the sort
02:49karolherbst: so it clocks up, load drops too far below the target, it clocks down, load increases too far above the target :D
02:49mupuf: I would not call it a safety margin
02:49mupuf: but the idea is right
02:49mupuf:tries to come up with a better name
02:50karolherbst: target range
02:50mupuf: that could be one concept, yes
02:50mupuf: but you know what I will tell you :D
02:50karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/5ba9c8a16f7b22a9c68485b6ba99f1e814e0e417#diff-5e5cb4582f6faff078d1cad6144b248a
02:50mupuf: You are getting ahead of yourself :D
02:50mupuf: We need a rig!
02:51mupuf: we cannot think about every case, we need data!
02:51karolherbst: ahh yes, I also count the downclocks situations on the pmu before sending a requests
02:51mupuf: repeatable cases
02:51karolherbst: so if the pmu notices too high load for 20 checks, then it requests a downclock
02:51karolherbst: I meant too low
02:51karolherbst: this should reduce the interrupts a lot
02:51mupuf: that is sensible, but again :D
02:52mupuf: we need a rig
02:52karolherbst: yeah I know
02:52RSpliet: mupuf: hysterisis threshold?
02:52karolherbst: mupuf: at least I can test it here locally a bit
02:52mupuf: karolherbst: how would you be able to tell if it is good or not?
02:52mupuf: RSpliet: it is not hysterisis in this case
02:52karolherbst: mupuf: well as long as the game doesn't run worse than full clock and nouveau uses lower clocks, I am happy
02:53mupuf: browsers will :p
02:53karolherbst: mupuf: I have to still implement >95% => full clocks thing
02:53mupuf: and you will always run worse than full clocks
02:53karolherbst: mupuf: for short loads for sure
02:53karolherbst: I tried to let the pmu check every second
02:54karolherbst: it was a nightmare :D
02:54mupuf: yep, I tried this on my nv86 laptop
02:54mupuf: back in the days :D
02:54karolherbst: mupuf: one issue thought: falcon timer
02:54mupuf: 10 Hz was ok
02:54karolherbst: imagine this: pmu collects the load data through its counters
02:55karolherbst: now, after it collected like 40% of the time until the new readout, there is a big relcock happening
02:55karolherbst: what do you think how bad will the data will be for this one readout?
02:56karolherbst: I am not quite sure this is a problem at all, but I couldn't tell my why it isn't one for sure
03:04karolherbst: I have a nice game with a really unstable load: https://gist.github.com/karolherbst/5583c69d2560f152885d
03:05karolherbst: I should fix that typo :D
03:16karolherbst: mupuf: also I have to increase the voltage a lot with this, seems like higher pstate, low cstate wasn't stable at all for me
03:17karolherbst: mupuf: even nouveau duty +5 wasn't enough, so I am at +10 now
03:17karolherbst: which is really close to what the blob does
03:22mupuf: yep, if you are reclocking that often in a game, this is a sign of a very bad policy
03:25karolherbst: mupuf: I guess that's the reason nvidia only downclocks after like 10 seconds or something
03:26gryffus: karolherbst: i did some further testing of the Fermi reclock
03:26gryffus: karolherbst: and i didn't get a single freeze in other app than Unigine
03:27karolherbst: mhh okay
03:27gryffus: so the freeze could be not at all related to the reclock
03:27karolherbst: any dmesg output on freeze with unigine?
03:27gryffus: apart from that it's rock solid for my system
03:27karolherbst: gryffus: I assume too low voltage would apply here too
03:27gryffus: karolherbst: hopefully i will be able to build some debug environment today
03:27karolherbst: but good to hear that it should work in theory
03:28karolherbst: gryffus: won't need any debug environment
03:28karolherbst: just dmesg output
03:28karolherbst: nouveau should start to print stuff after a few seconds
03:28gryffus: karolherbst: i will let you informed
03:28gryffus: karolherbst: yeah, but if i get the freeze i'm not able to switch VT's
03:28karolherbst: thanks for testing by the way
03:28karolherbst: gryffus: right, you would need to use ssh for this
03:29gryffus: karolherbst: yeah
03:52mupuf: karolherbst: nvidia is not super aggressive, yeah
03:52mupuf: but I would rather be too conservative than having people disable dyn clocking because it sucks on their applicatoin of choice
03:52karolherbst: mupuf: yeah I was thinking I do the super aggressive apporach first to really see how the algorithm works without using some hacks to reduce the reclocking stress :D
03:54karolherbst: mupuf: we could also do optimizations like: send pmu that we run on lowest/highest clocks, so that it won't sent request on low/high loads anymore
03:54karolherbst: but that will safe us only a few interrupts
03:54mupuf: just stop screwing around with ideas and actually make a rig to test them :D
03:55karolherbst: I can test it locally, I just need the software
03:55mupuf: you cannot consistently check the perf impact
03:56karolherbst: why not?
03:56mupuf: and having to write ASM, compile the kernel and reboot is not really what I call a good test
03:56mupuf: how do you make sure of the variance of your test?
03:56karolherbst: I run it a few times? and use apitraces?
03:56gryffus: karolherbst: got nouveau 0000:02:00.0: fifo: read fault at 0000fb5000 engine 15 [PCE0] client 01 [PCOPY0] reason 02 [PAGE_NOT_PRESENT] on channel 0 [001fe64000 DRM] and nouveau 0000:02:00.0: fifo: ce0 engine fault on channel 0, recovering... so far
03:56gryffus: with the freeze
03:57mupuf: apitraces are the worst, they use 100% of the cpu quite often
03:57mupuf: they are super helpful, but not designed for performance analysis unless you use perf counters
03:57karolherbst: ohh right
03:58karolherbst: k, anyway there is no other load on the gpu, so I might just run some benchmarks on it and compare the result, but then again, clocking to to max clocks isn't the problem :/
03:58mupuf: and even then, it screws with pwr management
03:58karolherbst: so all I can do now is to test some games which don't max out the gpu at all time :/
03:59mupuf: but how do you check the fps reading? Visually?
03:59karolherbst: one benchmark could be: run game benchmark vsynced at 60 fps and messure power consumption and rendered frames or something
03:59karolherbst: mupuf: steam overlay
03:59mupuf: this is really wrong, you are also missing out on the frametime
03:59karolherbst: I could also add some gallium hud stuff though
04:00mupuf: add a way to read the p and cstate then
04:00mupuf: so as you can correlate with any increase in frameitme
04:03mupuf: even then, having a set of benchmarks that you can after every test
04:04mupuf: and then comparing the performance would be much better
04:04mupuf: ezbench has a very nice mode for this
04:24karolherbst: mupuf: k
04:24karolherbst: mupuf: but actually exposing the clocks to mesa sounds like a good idea
04:24karolherbst: mupuf: does any driver do it so far?
04:24mupuf: karolherbst: maybe freedreno?
04:25karolherbst: mupuf: and I guess exposing power consumption to mesa is also a good idea
04:25karolherbst: but for this mesa could simply readout hwmon and this would be easy to implement for every driver
04:26karolherbst: I don't think we should start using driver specific paths here
04:50mupuf: karolherbst: yep, there would be no point
05:02karolherbst: mupuf: any suggestions to the clock interace? I don't think we should have that a single value thing, more like multiple clocks with an API to get the descriptions, same for memory, thought I think there won't be any architecture with different memory related clocks
05:03karolherbst: or just one API for all clocks with a type attribute
05:03karolherbst: + string description
05:03mupuf: core=4564 MHz, mem=4567 MHz, PCIe=blabla
05:32karolherbst: mupuf: I was more thinking about the different types of core
05:33mupuf: isn't that a little too much information?
05:37karolherbst: no idea
05:37karolherbst: but I would think that on fermi it makes sense to expose core and shader clocks
05:38karolherbst: the driver can still control which clocks to expose, but it should be possible to expore more than one
05:42mupuf: on tesla you mean?
05:42mupuf: on fermi, shader == 2 * core
05:44karolherbst: mupuf: ahh k, I thought I saw some exceptions to this
05:45mupuf: only on tesla
05:45mupuf: it is hardwired on fermi
05:45karolherbst: yeah then on tesla we might expose both
05:45karolherbst: or also on fermi, even if it's hardwired
05:46karolherbst: we shouldn't be too technically here I think
05:46karolherbst: nvidia-settings also reports both
05:46karolherbst: on fermi
05:50mupuf: well, this is architecture-dependent anyway
05:50mupuf: and shader is barely relevant on telsa since htere is no cstate
05:51mupuf: so, why not limit ourselves to core, mem and pcie?
05:51mupuf: we already get the main three
05:55RSpliet: should vdec be treated as a binary? :-P
05:57mupuf: RSpliet: ?
06:02karolherbst: I don't think exposing vdec clocks makes any sense at all
06:02karolherbst: because they are rather static overall
06:02karolherbst: and usually the same across all models
06:06RSpliet: depends on what you want to do with the information
06:06karolherbst: RSpliet: checking how good dynamic reclocking is
06:07RSpliet: different pstates have different vdec frequencies, and different videos (resolution, encoding parameters) could cause different load on vdec :-)
06:07karolherbst: RSpliet: yeah, but for me it is like 405 MHz on 07 and 540 MHz on 0a and 0f
06:07karolherbst: there isn't really much to it overall
06:08RSpliet: 25% perf difference? could mean the world in some cases :-D
06:08karolherbst: yeah, but if the load is like 95% video playback is still good
06:08karolherbst: and detecting this is trivial
06:09karolherbst: so the benchmark for video decoding is more like: play video and if you see artefacts or stutters, debug dyn reclocking and if you see the clock doesn't go higher fast enough, debug the thresholds a bit
06:09karolherbst: but I don't think looking at the clocks really helps here
06:09RSpliet: anyway, I can imagine some weird video's with very little I-frames and lots of P-frames where the load might bounce a bit
06:10RSpliet: don't know if exposure would help, but make sure you do the analysis before settling :-P
06:10karolherbst: the main issue will be that we clock higher fast enough
06:10karolherbst: but seriously
06:10karolherbst: that will only occur on 4k videos
06:11karolherbst: RSpliet: yeah, but looking at the clocks won't help here
07:11aboll: imirkin: sorry I don't know, you could ask at firstname.lastname@example.org
07:12aboll: imirkin: from looking at the changelogs it seems they're mostly uploading security fixes and from time to time they do an upload with misc. email@example.com fixes for the stable and old-stable debian releases
07:12aboll: imirkin: unstable and testing usually tracks the latest stable kernel
07:13aboll: imirkin: experimental usually tracks the latest upstream release candidates
07:14aboll: imirkin: the debian kernel team also provides newer kernel versions for the stable releases through debian-backports
08:44karolherbst: mupuf: so just to sum up the stuff I would have to do for the additional things for the GALLIUM_HUD, I would need to either add sysfs or nvif interfaces for the stuff on the nouveau side, add some nice gallium ground work for the independent parts, add all those GALLIUM_HUD stuff I want to have (clocks, voltage(s) maybe?, power consumption, and hook it all up with some gallium implementations (hwmon) or nouveau specific implementations (nvif), right?
10:33andril: i need help locating a driver for Debian 01:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/820M / GT 620M/625M/630M/720M] (rev a1)
10:34buhman: andril: are you using debian 6?
10:35andril: buhman, debian 8.2
10:35buhman: the driver is in your kernel
10:36andril: buhman, noob here can you be my jedi and guide me
10:38buhman: andril: GF117 should JustWork™; you might try asking in #debian for any debian-specific things that you aren't doing correctly.
10:38andril: cool i will do that
10:38buhman: andril: I also suggest explaining what you tried to do, what actually happened, and how this differed from what you expected
10:40andril: fresh install, does work just noticed outlines with Docky and minor graphical issues, asked for help and headed to debian for more advice - thanks
10:40buhman: O.o, so your original question wasn't related to your actual problem at all
10:41andril: a problem within a problem
10:48RSpliet: yo dawg
11:06smead: Hey all, I've just started using nouveau on FC23, on a dell with a mini displayport
11:07smead: Any magic tricks to light that output ? HDMI out works, but displayport seems to be a no-go
12:27imirkin: smead: what gpu? do you see anything in xrandr output?
12:27imirkin: smead: if it's a fairly new laptop, there might be some sort of DP-MST nonsense going on, which nouveau doesn't (yet) support
12:36Yoshimo: what do dp and mst mean in this case imirkin?
12:41sarnex: display port and multi stream transport i'd guess
12:42imirkin: good guess
12:43Yoshimo: DisplayPort could be yea, but the other thing doesn't ring any bells
12:43imirkin: it's a feature of DP 1.2
12:44Yoshimo: ah ok
13:49smead: imirkin: nvidia 1100 (it's a discrete card)
13:50imirkin: smead: that's not a model i recognize... lspci -nn -d 10de::300
13:54smead: imirkin: nothing back from that. I've got this though
13:54smead: $ lspci |grep -E "VGA|3D"
13:54smead: 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
13:54smead: 02:00.0 3D controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1)
13:55imirkin: ah. right. 3d controller. clever.
13:55imirkin: i was being clever with the :300 to avoid the hdmi device, but they outsmarted me
13:55imirkin: 3d controller is :310 or so? i forget
13:56imirkin: right, so when it says "3d controller" that usually means "no screens connected to this gpu"
13:56imirkin: what makes you think the mini-dp is hooked up to nvidia?
13:57smead: Well, nothing necessarily, other than it won't work
13:57imirkin: pastebin output of 'xrandr'
13:59imirkin: is your mini-dp not connected to anything?
13:59imirkin: or is something plugged in?
14:00smead: Ah crud, i pulled the cable before. One sec, sorry
14:00imirkin: also may i ask why you're driving your internal panel at 1600x900 instead of its native 1920x1080 resolution?
14:01smead: b/c KDE is aweful at making 1920x1600 useful :)
14:01karolherbst: "ls /sys/class/drm/" also helps to figure things out :)
14:01imirkin: karolherbst: one thing at a time.
14:02karolherbst: well this would answer your question
14:02smead: imirkin: of course, now it's going to work
14:03karolherbst: imirkin: by the way, shouldn't be the name be DP1-1 if it's from the nvidia gpu or something?
14:03imirkin: smead: it works ok now? sounds like it's hooked up to intel.
14:03smead: Yeah, it's working
14:03imirkin: karolherbst: no nvidia involved here.
14:03karolherbst: yeah I meant nouveau
14:03smead: Thanks for letting me waste your time :(
14:03imirkin: smead: for the record, all the displays are driven by your intel gpu, not nvidia.
14:04karolherbst: actually it makes sense to have those gpus recognizes as 3d controllers
14:04karolherbst: smart move
14:05karolherbst: smead: do you intent to use your nvidia gpu over prime by the way?
14:06karolherbst: mhh, but that gpu doesn't look that fast though
14:06smead: karolherbst: not necessarily. I primarily do database development
14:06karolherbst: k than don't even bother using it
14:06karolherbst: intel with open drivers should be faster
14:06karolherbst: hd 4600?
14:06smead: karolherbst: is that bumblebee that you're hinting at ?
14:07smead: ah, okay. I'll take a look in case I get antsy
14:07karolherbst: bumblebee usually uses the propritary driver
14:07karolherbst: you can also use it with nouveau, but that's waste of performance
14:07smead: My biggest issue is that I'm constantly plugging external monitors / projectors. Moving back and forth between meetings, etc...
14:08karolherbst: at least you got a sane design here
14:08smead: I seem to have issues with multiple monitors. KDE / sddm doesn't always detect the monitor disconnect. When that happens, I lose my task bar :)
14:09karolherbst: smead: qt5 5.4 installed?
14:09karolherbst: you _want_ to upgrade to 5.5, but then you need a patch otherwise vlc is a bit bricked
14:09karolherbst: with qt5.4 applications are crashing when the monitor setup changes
14:10smead: Oh, wow. I'm not sure, i'm new to dnf, so I'm not sure how to get the exact qt version
14:10karolherbst: open qt application
14:11karolherbst: open help
14:11karolherbst: about $application_name
14:11karolherbst: and then version
14:12smead: Tried dolphin and konversation, doesn't show the version in the about box. But... dnf info on qt5-qtbase shows 5.5.1
14:12karolherbst: I get something like that: https://gist.github.com/karolherbst/74ec233e28d0348300ed
14:12karolherbst: mhh k 5.5.1
14:12karolherbst: that shouldn't mess up the desktop when switching monitors :/
14:14smead: So, whenever I disconnect HDMI, The laptop still thinks there are two monitors connected. If I Alt+space and run 'xrandr', it'll move the windows back to the laptop screen, but, it'll *sometimes* leave the panel in no-man's-land
14:14karolherbst: mhh strange
14:14karolherbst: smead: I bet you have kscreen installed?
14:14smead: Should I remove that beastie?
14:15karolherbst: usually kscreen handles all that stuff
14:15karolherbst: maybe you should setup the resolutions up with kscreen once
14:15smead: ah, okay
14:15karolherbst: could help, but I have no clue here so you might want to ask in the right kde channel
14:15smead: let it think it's responsible
14:15smead: sure. Thanks for the assist!
14:26Lekensteyn: Got a new laptop laying around with a GTX 965M (GM204), is there anything you would like to test on it?
14:27karolherbst: Lekensteyn: wait until nvidia releases the signed firmwares
14:28vedranm: karolherbst: where is Torvalds when we need him
14:29Lekensteyn: karolherbst: can be a long wait right? In case you are interested, here is a full dmesg (didn't check whether an external monitor works) http://sprunge.us/GWFE
14:31vedranm: Lekensteyn: we have been waiting for a while already
14:31Lekensteyn: vedranm: already over a year iirc?
14:31vedranm: Lekensteyn: yes, I put my 970 away for now
14:37karolherbst: well there were some new patches from a nvidia guy
14:53Lekensteyn: could someone add the GTX 965M to the CodeNames wiki?
14:55imirkin: Lekensteyn: i guess maxwells have sprouted a lot of new names... should go through the pci.ids list and see what i can dig out of it
14:56Lekensteyn: can't run lspci, hangs due to an ACPI issue related to runtime PM :|
14:56imirkin: Lekensteyn: ah neat, there's a GM206M and GM204M GTX 965M versions
14:57imirkin: Lekensteyn: and apparently there's another pci-id range for GM204... probably a weirdo situation there too
14:59Lekensteyn: this one is a 13d9 as well (http://pci-ids.ucw.cz/read/PC/10de/13d9)
15:00Lekensteyn: the GM206M version appears to be a refresh (to be?) launched this month
15:23imirkin: Lekensteyn: anyways, i'm lazy. if you provide the text, happy to make wiki edits. or even to make you a wiki account.
15:25karolherbst: Lekensteyn: yeah, lspci will wake up your nvidia gpu
15:26Lekensteyn: imirkin: I'll have to research more for all variants, having a wiki account reduces the latency I guess :P
15:34imirkin: mwk: something to look forward to... there might be some funny 0/-0 differences between GF108 and GF119
15:35imirkin: (still need to do more analysis to figure out wtf is going on)
15:50mupuf: there is really something funky about this nvd9
15:50mupuf: [89051.615064] nouveau 0000:01:00.0: fifo: INTR 01000000: 00000005
15:50mupuf: got this with xomotic now
15:50mupuf: not only with heaven
15:50mupuf: thing is, I ran xonotic multiple times and only now does it crash
15:51mupuf: and i am back to SCHED error 14, after some time
15:58imirkin: hm, well, i've seen a few bugs complaining about SCHED errors and whatnot
15:58imirkin: i never have any clue what they mean
16:01imirkin: mupuf: if you should determine that it's some change in mesa, definitely let me know though :)
16:01imirkin: afaik i haven't broken anything but... heh. who knows.
16:01imirkin: i don't really put a lot of QA into the changes i push out
16:02mupuf: well, it would be hard to do real QA
16:02mupuf: but this is my goal here
16:02imirkin: yeah, that's why i don't do it :)
16:02imirkin: i do test them *a bit*
16:02imirkin: but that hardly catches all the various combinations
16:02mupuf: I need to add support for ... hw watchdogs
16:03imirkin: but i'd need actual resources to do actual qa
16:03mwk: imirkin: as in, positive/negative 0?
16:03imirkin: mwk: yes
16:04mupuf: my original idea is to at least have nv86 + nvd9 continuous testing running
16:04imirkin: mwk: there's a piglit test that passes for me on GF108 but fails for hakzsam_ on GF119, only when the result is 0x80000000
16:04mwk: I'll look into it if I can find my ancient GF100 gr rn code
16:04mupuf: then, it would be to plug whatever gpu we need in reator and ... letting it catch regressions on its own
16:04imirkin: could be some bit of init for all i know
16:04mwk: could be, yes
16:04mwk: quite likely
16:04mwk: perhaps the MUL_ZERO_WINS thing?
16:05imirkin: that's only for frag outputs no?
16:05mwk: one of its effects is making 0*anything a 0, -0 be damned
16:05imirkin: (for blending)
16:05mwk: no no no
16:05mwk: it's for every mul.f32 in a shader
16:05imirkin: oh, there's another one?
16:05mwk: or a compute program for that matter
16:05imirkin: what's it called?
16:05mwk: I'm not sure if it exists on GF100
16:05mwk: or where it could be
16:06imirkin: oh, you just figure it exists
16:06mwk: it does on G80
16:06imirkin: yeah, i know it does on G80
16:06imirkin: but G80 doesn't have FTZ
16:06mwk: but yeah, I'm not sure
16:06imirkin: which... isn't the same, but it's related
16:06mwk: there's a flag on GF100 mul instructions which looks like it could be that, called FMZ
16:06mwk: if so... I guess you're not setting it, and the hypothesis is wrong
16:07imirkin: yeah, FMZ flushes NaN to 0
16:07mwk: well, then no idea
16:07imirkin: we only set it for pow() lowering
16:07imirkin: (unless we're setting it by accident here)