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