04:12misasja: pmoreau: please stop it, everyone knows you don't win debates against me, please stop that bullying and arrogancy, face it easily that i had the point and without troubles let's just move on
05:28frobos: I'm running mesa 12.0.2 on gentoo succesfully, with OpenGL 4.3 and direct rendering. I'm trying to chroot into a 32bit installation with mesa 12.0.2 x86. I can connect to the running X server, but glxinfo informs me that only OpenGL 2.1 is available. What am I missing?
08:29karolherbst: :) https://travis-ci.org/karolherbst/nouveau/jobs/160632860
08:38pmoreau: Does anyone understands how the RA works, mainly the liveness computation part for now?
08:38pmoreau: The liveness of %68 doesn’t look correct to me, but I can’t find where it does go wrong, nor why: https://phabricator.pmoreau.org/P104#694
08:39pmoreau: karolherbst: Nice!
08:40karolherbst: it works :D
08:40karolherbst: the archive is just massivly big
08:40karolherbst: my tests from yesterday produces a 1.2GB copy of the linux tree ...
08:40karolherbst: not being able to clone --depth 1 $commit_hash is annoying to deal with :/
08:42karolherbst: mhh, with the bare way I save around 100mb and always have a clean repository... have to do for now
08:44karolherbst: new build with using the cache: https://travis-ci.org/karolherbst/nouveau/builds/160633848
08:44karolherbst: and actually building the kernel
08:44karolherbst: ohh, I think it will fail cause there is no bc installed....
08:45karolherbst: the heck is going on
08:55karolherbst: seems like --separate-git-dir doesn't leave the bare repository allone :/
08:55karolherbst: but I also don't want to reclone
09:19karolherbst: much better now: https://travis-ci.org/karolherbst/nouveau/builds/160637046 :)
09:19karolherbst: no idea if we really want to use ccache though
09:20karolherbst: it speeds up the limit a lot, but it may give false negatives
09:20karolherbst: I guess tweaking the kernel config is the better way to go
11:45hakzsam: imirkin, waiting for reviews
13:02mupuf: karolherbst: yeah!
13:02mupuf: this is great!
13:06karolherbst: fun is stuff like that now: https://travis-ci.org/karolherbst/nouveau/builds/160651167
13:06karolherbst: I need a way to sanely specify what I need in the kernel config without having to care about what kernel version it is and for any random config which might be added removed
13:09Tom^: karolherbst: there is modprobed-db to keep track of kernel modules https://wiki.archlinux.org/index.php/Modprobed-db
13:09karolherbst: Tom^: you have no idea what Iam talking about :p
13:09Tom^: nope, not the slightest.
13:10karolherbst: this is for CI and build testing
13:10karolherbst: like you push a random branch on github and travis-ci should check what is the current drm commit your tree is based on, clones drm-next, checks out the commit, merges nouveau in it and builds the kernel
13:10karolherbst: and I also plan to do that for various configurations as well
13:11karolherbst: but for that we need some way to configure .config without any user input
13:14mupuf: karolherbst: I have just this
13:14mupuf: make oldconfig
13:15mupuf: this is the trick I use for ezbench
13:15Tom^: orbea: btw i got an 780ti and also occasionally get system freezes while playing cs:go , never had the time to see if it errors or if im even able to ssh in because it always happends in a matchmaking game.
13:15mupuf: my bad
13:16mwk: whee, one more weirdo edge case and I can push first NV3 PGRAPH hwtests
13:16mupuf: mwk: move on, have you?
13:16mwk: not really yet, there are still things on NV1 I'll have to finish before moving further
13:17mwk: but yeah, I decided to start working on NV3 in parallel
13:18mwk: esp. since a lot of things left on NV1 todo have nothing in common with later cards
13:20mwk: but I figured I'd at least look at NV3's context now
13:21mwk: I might try loading/saving NV4's context as well once I'm done with this commit, but that'd involve getting my 3.3V AGP machine up and running, which is a massive pain
13:22mwk: the thing is so old, it can't run i686 software, I have to use an ancient debian version that's still compiled for i486
13:24mupuf: mwk: OMG
13:25mwk: luckily my NV3 is a PCI specimen, so I don't have to go through this bullshit now
13:29karolherbst: mupuf: thing is, I do start from scratch though
13:29mupuf: karolherbst: ?
13:29karolherbst: well I could provide .config files through the repository, but that is a bit ugly
13:29karolherbst: so I have no .config file for now
13:32karolherbst: though I could do defconfig; mod .config file; olddefconfig
13:32mwk: mupuf: even if I can boot that machine, there's about a 50% chance that it won't be able to compile envytools because of compiler version or some other bullshit
13:32mwk: I have a feeling this whole thing will end with a custom-bootstrapped gentoo install
13:32mupuf: very possible
13:33imirkin: karolherbst: you can generate a new config with make defconfig foo
13:33imirkin: karolherbst: where foo is a file with your CONFIG_* enables
13:33karolherbst: mhh I tried that but failed
13:33mwk: I actually had one before, but something horrible happened to it and I replaced it with the crazy debian
13:33imirkin: karolherbst: well it's something like that
13:34imirkin: karolherbst: it's definitely a thing that exists and people use. so there's gotta be a way to make it work :)
13:34imirkin: karolherbst: did you have CONFIG_FOO=y in there? or just CONFIG_FOO?
13:34karolherbst: I tried that with allnoconfig actually...
13:35karolherbst: nope, doesn't work with defconfig either
13:35karolherbst: make defconfig CONFIG_DRM_NOUVEAU=m
13:35karolherbst: "# CONFIG_DRM_NOUVEAU is not set"
13:40imirkin: karolherbst: ok, maybe not 'defconfig' then. but something.
13:48karolherbst: mhh this seems to work kind of: https://travis-ci.org/karolherbst/nouveau/builds/160661837
13:48karolherbst: what does ".config:4045:warning: override: reassigning to symbol DRM_NOUVEAU" mean though
13:49karolherbst: ahh, just that the value was there twice
13:49karolherbst: this way indeed seems to work
13:49karolherbst: and all new enabled configs get the default value
13:49karolherbst: well rather available
13:50karolherbst: maybe I also disable the worst things like net support, cause that compiles a lot
13:54dbacc: hey! I solved my first problem with DP connection. I'm using Reverse PRIME to use that display. I'm having huge (performance) problems when I try to use a 2 desktop/screen solution (LVDS1 + DP1). Sometimes when I set some configuration with xrandr I get messages like core dumped ...
13:54karolherbst: "drivers/gpu/drm/nouveau/uapi/drm/nouveau_drm.h:30:17: fatal error: drm.h: No such file or directory" ... nice :D
13:54karolherbst: I guess that's indeed wrong
13:57karolherbst: I guess we should at least test a debugfs=y/n compile and a 64bit=y/n
13:57karolherbst: anything else which might be good? hwmon?
13:58imirkin: dbacc: if you're using 'DP1', you're not using reverse prime...
13:58karolherbst: dbacc: changing pstate might help due to low pcie/memory bandwidth
14:00pmoreau: imirkin: `addLiveRange` will only extend livei if `being != end`, however that variable, as it is used in the first insn of the block (and is defined before that), will end up with `begin == end` and therefore never extend the range…
14:01dbacc: imirkin: accroding to archwiki it is? I set xrandr --setprovideroutputsource nouveau Intel .
14:01pmoreau: Is it really what is supposed to happen?
14:01imirkin: dbacc: pastebin xrandr output
14:01karolherbst: dbacc: are you sure your displays are connected to the nvidia card?
14:01karolherbst: it might be that all your ports are actually wired to intel
14:01dbacc: karolherbst: to what should I change pstate?
14:01imirkin: pmoreau: interesting.
14:02karolherbst: dbacc: first we should clarify where your ports are wired to, regardin pstate: anything higher should do, but mind that it may be unstable before kernel 4.9
14:04dbacc: imirkin: I mean dp-1-1 of course -.- http://pastebin.com/z012X1yg
14:05karolherbst: k, then it is indeed prime
14:05karolherbst: dbacc: what gpu do you have?
14:05imirkin: ok, that makes more sense then
14:05dbacc: karolherbst: pretty sure my displayport is wired to my nvidia... it is NVS4200 in a lenvo T420
14:05karolherbst: mind that reverse prime is heavily pcie bottlenecked and nouveau defaults to 2.5 GT/s for now
14:06karolherbst: dbacc: okay, that should be able to do at least 5.0GT/s
14:06karolherbst: it is fermi though, so reclocking is disabled
14:06imirkin: but no reclocking enabled
14:07karolherbst: we could do it by hand with envytools though and at least verify if that indeed helps
14:10dbacc: what is strange that, if LVDS1 is off then performance is worse. So reclocking might help?
14:10karolherbst: that is a bit strange though
14:11karolherbst: changing pcie speed will help for sure, but it shouldn't be the difference hetween fine and real bad, but more like find and not that much fine
14:12imirkin: the nvidia gpu just draws whatever the intel ddx passes to it
14:12imirkin: this is how reverse prime works
14:12imirkin: among other things, reverse prime causes a software cursor to be used, which isn't great
14:12imirkin: this is fixed in Xorg 1.19 apparently
14:16pmoreau: imirkin: Yup, manually setting the liveRange from [bbBegin, use_insn->serial) to [bbBegin, bbEnd) for that specific variable made RA not overwrite that register, and the program runs fine rather than hanging my laptop. :-)
14:17dbacc: imirkin: hmm, arch is still on 1.18.4... this doesn't explain why it's worse when LVDS1 is off, right?
14:17dbacc: I'm going to try a different desktop, maybe kscreen is messing up something.
14:19karolherbst: mhh kscreen shouldn't have anything to do with that though
14:19karolherbst: and if anything is bad with reverse prime I would blame X anyway all the time
14:20dbacc: karolherbst: it is strange however that certain xrandr commands do not work, whereas using the 'display configuration module' gives me at least some output. Positioning of the windows is horrible.
14:21dbacc: that might not be the primary cause of troubles
14:21karolherbst: no, but the module is usually smarter than puttin rangom flags to xrandr
14:21karolherbst: the entire reverse prime situation is painful, cause it is implemented in a painful way afaik
14:22karolherbst: it is even considered a "hack" of dri2, which won't work with dri3 or wayland
14:23dbacc: if I don't place my lvds screen in the lower left corner of my screen then the DP screen is not usable at all... anyway, seems like I will have to revert back to bumblebee
14:25karolherbst: for performance you want that anyway
14:26karolherbst: well using nvidia that is
14:26karolherbst: nice, successful build: https://travis-ci.org/karolherbst/nouveau/builds/160667155
14:27dbacc: karolherbst: will there be any solution in the future using nouveau?
14:28karolherbst: dbacc: what do you mean?
14:29imirkin: dbacc: i think you want to be talking to the intel guys...
14:29imirkin: nouveau just takes what intel gives us
14:30imirkin: a bunch of people run into issues
14:30imirkin: while a bunch of other people don't
14:30karolherbst: mupuf: 64bit/32bit build: https://travis-ci.org/karolherbst/nouveau/builds/160668942
14:30imirkin: sadly i have no clue what distinguishes one group from the other =/
14:31dbacc: oh, okay, that's sad. I really like using linux. But using optimus is a pain. And I don't want to reboot every time I have to connect an external display;)
14:31karolherbst: uhhh each matrix entry gets its own cache :O
14:31dbacc: hmm, so it's not about which ports are hardwired to which card?
14:32imirkin: dbacc: people with otherwise identical hw configs afaik
14:32imirkin: some have issues, others don't
14:32imirkin: it's a software stack thing
14:32imirkin: but ... who knows what the active ingredients are
14:33imirkin: dbacc: on the bright side, many such laptops have a toggle in the bios to disable the nvidia gpu
14:33imirkin: dbacc: in some cases, you lose the ports. in other cases, there's a hard mux thing that flips them over to the intel gpu
14:35dbacc: I tried. They are just not working anymore. However, I also wanted to be able to use 3 displays which definitely needs the nvidia gpu :(
14:36imirkin: you'll also want a git checkout of the nouveau ddx for that if you're using xorg 1.18
14:36imirkin: we had a little oopsie in the released version
14:36Hussam: hi. I bought a 730GT (kepler). previous card is 630GT (fermi). by default it uses DRI2.
14:36Hussam: I tried DRI3 but it caused issues
14:36imirkin: Hussam: with kwin i take it?
14:36Hussam: Xorg was not as stable.
14:37dbacc: imirkin: alright, thanks!
14:37Hussam: Is this something I can ignore?
14:38imirkin: dri2 works and is the default...
14:38Hussam: I'm thinking for the future :)
14:39Tom^: we need to start a whiskeyfund so we can get imirkin to install gnome/kde to figure out the DRI3 issues.
14:40imirkin: ahahah, i don't think there's enough whiskey in the world to make me do that
14:40Hussam: and /sys/kernel/debug/dri/0/pstate says 0f: core 1006 MHz memory 5010 MHz AC DC *
14:40imirkin: Hussam: what about the AC: line?
14:41imirkin: that's the one that reflects reality
14:41Hussam: That wasn't there under the Fermi card :)
14:41imirkin: (or DC: if you're not plugged in)
14:42Hussam: I mean I am getting good clock speed now.
14:42imirkin: right, but double-check that you actually are
14:42imirkin: what does AC: say?
14:43imirkin: AC: core 1005 MHz memory 5009 MHz
14:43imirkin: that's the one that's actually a reflection of reality
14:44imirkin: the * is just there to confuse you :)
14:44karolherbst: it matters with 4.9
14:44Hussam: I am booting with nouveau.config=NvClkMode=15
14:44karolherbst: Hussam: mind you, that before 4.9 the thing might be pretty unstable
14:44imirkin: hehe ok
14:44karolherbst: it may crash whenever you put load on it
14:44Hussam: google says that puts me on high clock speed
14:45karolherbst: imirkin: yeah, we default to base clocks with 4,9, so the last line might show different clocks actually
14:45imirkin: well, it puts you into perf level 0x0f
14:45imirkin: which in your case is the high perf level
14:45imirkin: (15 decimal == f hex)
14:45Hussam: If I remove that, will it auto adjust according to my load?
14:45imirkin: you're fine
14:46imirkin: if you run into issues, do what you did before - upgrade ;)
14:46Hussam: I am on 4.8rc6 now.
14:46imirkin: anyways, perf with that card should be half-decent. i suspect that we'll be within a factor of 2 from nvidia blob perf
14:47karolherbst: so real test for multi build now: https://travis-ci.org/karolherbst/nouveau/builds/160670740
14:47imirkin: but usually better
14:47imirkin: a few games are known to hang, but as long as you stay away from those, things should generally work well.
14:47karolherbst: yeah, should be more like 70%
14:48Hussam: The main difference so far is gnome-shell uses less CPU on NVIDIA 370.44 driver. But much less than it did on the Fermi card.
14:48imirkin: karolherbst: is The Witcher 2 still fubar without the buffer storage thing?
14:48karolherbst: imirkin: "fubar"?
14:49karolherbst: well, last time I chcked the issue is still there with buffer storage
14:49karolherbst: was like a month ago or so
14:49imirkin: Fucked Up Beyond All Recognition
14:49karolherbst: well it ain't that bad
14:49karolherbst: some camera angles are without issues
14:49imirkin: like the one where you stare at the sky?
14:50karolherbst: or the ground
14:50imirkin: Hussam: if it's a fanless card, make sure to monitor temperature
14:50imirkin: Hussam: we don't auto-downclock if it gets hot
14:50Hussam: it has a fan.
14:50karolherbst: imirkin: the gpu does
14:50imirkin: karolherbst: yeah, but the gpu's idea of auto-downclocking is "shut down"
14:50Hussam: sensors says: temp1: +48.0°C
14:51karolherbst: it ain't
14:51imirkin: so it won't burn, but it's also not a great user experience ;)
14:51karolherbst: it actually "downclocks"
14:51karolherbst: two stages
14:51karolherbst: first stage: half clock
14:51karolherbst: second stage: 1/8 clock
14:51karolherbst: third stage: shut down
14:51Hussam: 48c with a game running is not bad
14:51imirkin: the hw does this itself?
14:51karolherbst: imirkin: clock signal blocking I thing
14:51karolherbst: ask mupuf, he found it
14:52karolherbst: there are like some thresholds
14:52imirkin: i thought it had to be activated "manually"
14:52karolherbst: 98°C/102°C/106°C or so
14:52karolherbst: imirkin: well, the vbios tells us how
14:52karolherbst: it is withing a script within the vbios
14:52imirkin: ah ok
14:53karolherbst: we have no idea if it is set up for maxwell2 though
14:53karolherbst: hard to find out, cause we can't even fake the temperature
14:53imirkin: mwk: should this do what i think? http://hastebin.com/xiligokeyu.nginx
14:54mwk: imirkin: I think so, yes
14:54imirkin: i.e. add 4 to $r6:$r7 ($r6 is low word)
14:54Hussam: Next upgrade won't be for months :) Other stuff need upgrades first.
14:55imirkin: Hussam: i meant kernel when i said upgrade
14:55Hussam: ah :)
14:55imirkin: kernel v4.9 should have karol's various improvements to reclocking
14:55imirkin: which may or may not affect you
14:55Hussam: just in time for the LTS kernel.
14:56karolherbst: most likely they will, cause he will get lower clocks anyway :D
14:56Hussam: why lower?
14:56imirkin: coz karol hates you
14:56karolherbst: hihger clocks are part of a DLC you can buy
14:57Tom^: there isnt a 40$ Nouveau season pass?
14:57karolherbst: we plan one, but the first 5 aren't included and after the season pass comes out, it is just for the next two things, which are 4$ each
14:57karolherbst: but the pass is 60$ of course
14:58karolherbst: Hussam: we default to boost clocks with 4,9
14:58karolherbst: Hussam: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
14:58karolherbst: search for nvboost
14:58pmoreau: Sadly, you can’t preorder the season pass along a new GPU… We should talk with NVIDIA about that!
14:59Tom^: karolherbst: you mean default base clocks
14:59karolherbst: Tom^: what are those?
14:59karolherbst: like if there would be more than one base clock
14:59Hussam: Ok, so I use NvBoost instead.
15:00karolherbst: mind that some gpus don't have different boost levels at all
15:00karolherbst: depends on the vbios
15:00karolherbst: I already see those user coming inside this channel and complain about "AC line does show lower clocks than 0f"
15:00Hussam: And NvClkMode will not work?
15:00karolherbst: it still will
15:01karolherbst: those are two different things
15:01karolherbst: NvBoost just limits the highest clock which can be set
15:01Hussam: I understand now. thank you.
15:02karolherbst: the point of 0 is, that no matter what load you put on the card, it won't ever exceed power budgets and won't overheat like ever
15:02karolherbst: with higher boost leves, you can have workloads where the fans can't keep up with, even at full speed
15:05mupuf: karolherbst: yeepee!
15:05mupuf: getting there!
15:05karolherbst: mupuf: yeah, with 4GB aws storage used :D
15:06mupuf: do they charge for it? What is the limit?
15:06karolherbst: they don't charge for public projects
15:06karolherbst: they just say stay reasonable
15:06karolherbst: I will ask them though about this
15:06karolherbst: maybe they know a good solution
15:06karolherbst: I don't think cloning every time is nice, because it stalls the build quite a lot
15:09mupuf: yeah, it is a little big :D
15:11karolherbst: uhh, I forgot to echo those config flags into .config...
15:11karolherbst: silly me
15:21karolherbst: mupuf: "1 hr 59 min 16 sec" without the cache...
15:31kugel: airlied: thanks for your prime hw cursor work
15:31kugel: Hans de Goede too (dont know your irc nick)
15:32karolherbst: mupuf: "34 min 52 sec" with the cache ;)
15:32karolherbst: no, file cache
15:32karolherbst: caching the git tree I otherwise have to clone
15:32imirkin: kugel: hansg. he's only very rarely in this chan.
15:32kugel: I'm right now running reverise prime on xorg git using my egpu setup
15:32karolherbst: mupuf: I can add ccache though
15:32karolherbst: yeah, why not
15:33kugel: half a year ago it didnt work because of cursor flickery
15:34kugel: karolherbst: I'm on your kepler reclocking v6 branch. I had a crash yesterday that didn't occur again. want a picture of the backtrace?
15:35mupuf: karolherbst: what are you compiling btw?
15:35kugel: unfortunately the complete bt was cut off but it's somewhere in nv50_crtc_cursor_*
15:35mupuf: just linus' tree?
15:36imirkin: mupuf: btw, while you're fixing your led support, should probably also take care of the case where led support isn't built in. you end up declaring a bunch of functions instead of making them inline.
15:36karolherbst: mupuf: nope, drm-next tree + nouveau
15:36mupuf: imirkin: hmm, there was a reason
15:36imirkin: mupuf: specifically https://github.com/skeggsb/nouveau/commit/7ffeb1d32676033f738b0491fd62b2c148da6df4#diff-5498975b27c2b12d3163fd24db81ddd1R51
15:36imirkin: (also, those return's are completely unnecessary)
15:37imirkin: under no situation is this a correct thing to do.
15:37karolherbst: imirkin: this is the proper way to do things though
15:37imirkin: if this "fixed" something, then you're in serious trouble.
15:37karolherbst: read the kernel guide lines about config options ;)
15:37imirkin: karolherbst: static inline = fine.
15:37imirkin: all the lines below = wrong
15:37karolherbst: ohh static inline
15:38mupuf: yeah, makes no sense why _init would be OK but not the others
15:38mupuf: as for the empty returns ... yeah, this is useless
15:38imirkin: [believe it or not, i do occasionally know what i'm talking about]
15:39imirkin: as-is, it declares a bunch of different copies of those functions in each compilation unit that includes that header
15:39karolherbst: yeah, got it
15:39karolherbst: I thought you were talking about those stubs in general
15:40imirkin: mupuf: i'm guessing that the suspend/resume/fail stubs can just be plain removed
15:40imirkin: since their usage should probably go inside a #if as well
15:40kugel: karolherbst: https://ibin.co/2vOu2NOCFTdR.jpg
15:40imirkin: but if you do need them, then declare them at the usage site
15:40imirkin: not in the header
15:41karolherbst: kugel: as I thought, not my fault
15:41kugel: kernel 4.7.4 from arch linux + your _v6 branch
15:41mupuf: imirkin: you are missing the point, it would seem
15:41mupuf: the idea is to avoid having #if in the code
15:41mupuf: instead, it is just a stub
15:41imirkin: mupuf: that's a nice idea. what you have is broken.
15:41karolherbst: yeah, #if in the code is just plain ugly
15:41kugel: karolherbst: do you know that crash? What's the story about it?
15:41mupuf: in what way?
15:41karolherbst: imirkin: it gets constant fold out anyway
15:42imirkin: mupuf: you're declaring a fresh nouveau_led_suspend() function in each object file.
15:42imirkin: karolherbst: how?
15:42karolherbst: imirkin: cause compiler is smart
15:42imirkin: it has external linkage
15:42imirkin: compiler can't just remove functions like that
15:42karolherbst: sure it can
15:42imirkin: what prevents it from removing "printf()" in glibc?
15:42karolherbst: I am sure making those static inline won't change a thing
15:43imirkin: do a build, look at nm output
15:43imirkin: of the object file
15:43mupuf: well, static inline is definitely the way to go
15:43kugel: pamaury: hey :-)
15:44pamaury: kugel: key, how are youy doing ? Funny I am still hanging in #nouveau when I don't have an nvidia card anymore
15:45imirkin: the only case where that won't work is if you were trying to pass function pointers around
15:45imirkin: which you aren't
15:45imirkin: that's the case where you would have had to add a #if in the code
15:45imirkin: as the code stands right now though, slap a static inline on there and be on your way (and nuke the silly returns)
15:46kugel: pamaury: I'm alright. You're too? I'm hanging here because i'm trying to make my eGPU setup work nicely in linux
15:46kugel: which I'd say just happened
15:46mupuf: imirkin: yeah, done and tested
15:46pamaury: Good, trying to keep rockbox afloat but I don't have as much free time to hack as before
15:47karolherbst: imirkin: nope, no change
15:47karolherbst: imirkin: adding static inline produces equal binaries
15:47karolherbst: well "equal"
15:47imirkin: what are you comparing?
15:47karolherbst: nm and size
15:47imirkin: oh, yeah
15:47imirkin: doesn't matter for that
15:47imirkin: but look at any of the *.o files that #include nouveau_led.h
15:48karolherbst: still the same
15:48imirkin: does nm spit out a list of functions?
15:49imirkin: do you have CONFIG_LEDS enabled?
15:49karolherbst: I see
15:49kugel: pamaury: also little time here, and I've foudn other fun projects to work with. since my dayjob is about embedded rockbox isn't as fun anymore. which is actually sad :(
15:49mupuf: that was a fun one :D
15:50karolherbst: imirkin: well no I won't bother anymore, static inline is the right way anyway, I just assume gcc might be smart/dumb enough to opt that away for various reasons...
15:51karolherbst: gcc also inlines things not marked as "inline"
15:51karolherbst: at least I enabled that for the kernel
15:51pamaury: kugel: yeah mke sense, which other projects are you working on ?
15:51imirkin: karolherbst: but how could it remove them? how does it know that those functions aren't there "for real"
15:51imirkin: to be used by some other object?
15:52karolherbst: you sould never ask why a c++ compiler does things ;) you wouldn't stop finding questions for "odd" behaviour
15:52kugel: pamaury: geany and glib (gobject introspection), plus a personal arduino+wifi project
15:52karolherbst: compiler might even optimize code away, which change stuff
15:52karolherbst: no idea if they do it for C though
15:52karolherbst: but I assume they do
15:53imirkin: karolherbst: no, it's all well specified.
15:53mupuf: karolherbst: so, have you submitted your patch to revert the coherent patch?
15:53karolherbst: mupuf: nope :/
15:53karolherbst: I should
15:53mupuf: apparently, it impacts reator too now
15:53karolherbst: I thought pinging like three times might be enough
15:53mupuf: since I updated the kernel :D
15:53karolherbst: yeah I know
15:53karolherbst: it breaks things randomly
15:53Hussam: How do you tell how much video memory is in use on nouveau?
15:53imirkin: Hussam: cat /dev/random
15:54pamaury: kugel: ah nice
15:54imirkin: [we take patches]
15:55Yoshimo: does Intel offer something like GL_NVX_gpu_memory_info to know how much memory the card has?
15:55karolherbst: afaik only amd does
15:56imirkin: Yoshimo: GLX_MESA_query_renderer
15:56karolherbst: I thought he meant free memory
15:56imirkin: note that intel gpu's don't have vram
15:56imirkin: and i'm not sure that the edram thing is reported anywhere useful
15:56karolherbst: it is a cache anyway afaik
15:56karolherbst: also used by the cpu
15:58mupuf: imirkin: the edram is a giant cache
15:58mupuf: the only thing you can tell the hw is : cache these pages or not
15:59karolherbst: I thought it was even an transparent cache?
15:59mupuf: it is
15:59karolherbst: I see
15:59mupuf: it is shared with the CPU too
15:59karolherbst: yeah, I am aware
15:59mupuf:wishes he had an iris pro at home :D
16:00glennk: have they made more than three of them?
16:00karolherbst: I wished intel would sell more mobile cpus with those iris
16:00mupuf: glennk: iris pro? Sure, they are well sold on some mobile platforms
16:00karolherbst: but maybe it won't sell for bs reasons
16:00karolherbst: like "intel" sucks, better get a nvidia 920m
16:01glennk: last i checked the edram power consumption wasn't ideal for a mobile device
16:01karolherbst: glennk: sure, cause an nvidia/amd gpu comes for free
16:01glennk: i mean at the same total consumption you can get a significantly faster nv/amd gpu
16:01mupuf: hakzsam: in the talk, it would be nice to tell when we got the firmwares for the GM2xx
16:01karolherbst: I highly doubt that
16:01mupuf: and to tell what is stalled
16:01karolherbst: glennk: keep in mind, you have _two_ gpus turned on
16:02hakzsam: mupuf, pmoreau is working on that
16:02mupuf: because right now, it is reclocking and fan management that stalled
16:02hakzsam: yeah, that part can be improved
16:02Hussam: Apple macs uise intel graphics. they work well.
16:02karolherbst: but we can reclock maxwell2
16:02karolherbst: Hussam: they ain't believe me
16:02karolherbst: I have such, even with hi res display
16:03karolherbst: it lags like hell
16:04Yoshimo: karolherbst: it is a little bit too complicated for most people though ;)
16:04karolherbst: Yoshimo: sure, that was the "bs reason" part I was talking about
16:07karolherbst: mupuf: seems like ccache doesn't make it much faster ./
16:08karolherbst: mupuf: download/install/upload overhead is just too big
16:10imirkin: karolherbst: can't you keep a cache on the server, and then just git fetch so you don't have to reclone the whole thing?
16:10karolherbst: imirkin: guess why 4GB gets stored on AWS
16:11imirkin: kernel tree is like 1-2G
16:11karolherbst: cache is per matrix entry
16:11imirkin: 1.7G on my box, but i've pulled in a ton of crap over the years
16:11karolherbst: 4 buidls = 4 caches
16:22Hussam: what does this mean? n[ 25.555206] nouveau 0000:01:00.0: priv: HUB0: 085014 ffffffff (1a70820b)
16:22kugel: karolherbst: any word on when your reclocking patches hit mainline? can't live without your work :-)
16:23Hussam: I saw it while booting.
16:23imirkin: Hussam: don't worry about it
16:23imirkin: i get that too
16:23imirkin: kugel: v4.9 should have them.
16:23Hussam: Ok, thank you.
16:23Hussam: now to test hibernate
16:24kugel: imirkin: awesome
16:25imirkin: kugel: they're in ben's tree now
16:25imirkin: kugel: https://github.com/skeggsb/nouveau/commits/master
16:28kugel: scrolling in firefox seems slower with the modesetting driver compared to nouveau ddx. does that ring a bell for anyone?
16:29imirkin: yeah. don't use the modesetting driver.
16:30imirkin: for a lot more reasons than perf
16:30imirkin: the nouveau ddx is simple and stable. modesetting uses the nouveau GL driver which has basically 0 error handling.
16:30imirkin: this is fine for games
16:30imirkin: not so fine for a ddx
16:32kugel: okay. these days everyone seems to recommend modesetting ddx, especially for intel graphics. will try nouveau ddx again (hopefully reverse prime works as well with it)
16:32karolherbst: I have no issues with the intel ddx
16:33imirkin: yeah, pretty much everyone recommends the modesetting ddx except the people that have to support users using the modesetting ddx ;)
16:33karolherbst: and devs
16:33glennk: i recommend using the default the driver devs have set up to load automatically :-)
16:33karolherbst: I don't
16:34karolherbst: X is a pain in this regards
16:35karolherbst: wuhu, now patching the kernel works as well
16:35karolherbst: finally I can enable ttm set to y
16:36mupuf: karolherbst: you are testing linus' tree or ben's github tree?
16:37karolherbst: mupuf: what do you mean? as I said, I use drm-next for the kernel and merge a nouveau tree in it
16:37karolherbst: mupuf: https://github.com/karolherbst/nouveau/blob/travis/.travis.yml
16:37mupuf: great great!]
16:38karolherbst: I have to divide the script section though, but I don't care anyway
16:38mupuf: git log --oneline --grep='drm-next' we'll see if this holds
16:38mupuf: will be nice for Ben to take it
16:39karolherbst: it works without PRs even if you enable travis ci for your account
16:39karolherbst: painful is just, that the file has to be managed within the repository :/
16:40karolherbst: okay next step: fail if undefined symbol within module
16:41karolherbst: the 32bit build indeed prints "WARNING: "__divdi3" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!"
16:41karolherbst: but still returns 0
16:42imirkin: how are you building?
16:42karolherbst: what do you mean by "how"? it is in the .travis.yml file
16:42imirkin: oh. i see. link above.
16:42imirkin: didn't notice it
16:42glennk: divdi3 is long by long division
16:43karolherbst: glennk: sure and not there on 32bit kernels
16:43karolherbst: we know already, there is even a fix for that
16:43karolherbst: but we want to catch those issues earlier
16:43mwk: long long by long long :p
16:43karolherbst: hihi :D
16:43glennk: thats divti3 :-)
16:43karolherbst: long long and long is the same on 64bit, but not on 32bit
16:44karolherbst: x86 that is
16:44karolherbst: on linux
16:44glennk: llp64 vs lp64
16:44glennk: i just never use long, problem solved :-p
16:44karolherbst: I think using "long" is silly anyway
16:44karolherbst: C99 has nice datatypes for that
16:44karolherbst: use them
16:44imirkin: glennk: only __uint128_t? :)
16:45karolherbst: allthough uin64_t is optional....
16:45mwk: eh, wish I could depend on an actual uint128_t
16:45karolherbst: it would be time for that, I guess
16:45mwk: but apparently gcc thinks it's too much of a problem to support it
16:46karolherbst: is there any CPU supporting it for non SIMD operations?
16:46mwk: natively? not that I know of
16:46karolherbst: not that some devs simply to int128_t/int128_t and trigger like a 1000 cycle operation or so
16:47mwk: but most CPUs have hw support for extended-precision arithmetic
16:47karolherbst: yeah I am aware
16:47mwk: which is much better than whatever implementation you can write in plain C
16:47mwk: so I'd expect the damn compiler to be able to do it for me, it's 2016 after all
16:47karolherbst: just read a blog post about idiv today
16:47karolherbst: where a compiler optimized a module to a bunch of regs
16:47karolherbst: instead of div
16:48mwk: yeah, fairly common technique
16:48karolherbst: 15 instructions, faster than one div :)
16:48mwk: anyhow... clang supports a 128-bit int, 64-bit gcc supports a 128-bit, why can't 32-bit gcc support it as well...
16:49karolherbst: 32bit valgrind doesn't support sse3
16:49karolherbst: imagine how silly _that_ is
16:49karolherbst: especially cause of 32bit games
16:49mwk: I don't care if it's 60× slower than an uint32_t, it's still going to be faster than my emulation written in C
16:49karolherbst: somebody has to write that stuff, and I imagine everybody is in a "32bit should just die" mode
16:51karolherbst: if anybody has any ideas how to improve the travis.yml thing, please tell me :)
16:52Hussam: This broke hibernating. http://pastebin.com/raw/WZWmZigD
16:56Hussam: I have 4GB ram and 32GB swap partition.
16:57Hussam: I think nouveau is caching stuff in physical memory and causing issues when trying to hibernate.
16:59karolherbst: might be
16:59karolherbst: is this stock kernel hibernation?
16:59karolherbst: I heard tuxonice is much more advanced
17:00karolherbst: but yeah, if nouveau breaks hibernation, we should fix it
17:01Hussam: It works with nvidia proprietary driver.
17:03Hussam: I found this https://bugzilla.kernel.org/show_bug.cgi?id=33582
17:03Hussam: but not sure if related.
17:03kugel: karolherbst: I use the modesetting ddx on intel because it works better for me
17:03karolherbst: kugel: did you try intel dri3 with sna?
17:04kugel: I've had randomly freezes after resuming from suspend, more likely to happen when monitor config changed (e.g. when docking during suspend)
17:05kugel: on my laptop that is, on my workstation at work I use intel ddx without problems
17:06kugel: it sucks though that it has no releases so everyone (even stable distros) are forced to use git master
17:16kugel: does anyone know if I can point X to /usr/local for driver modules?
17:46Hussam: maybe there is a workaround for the hibernation issue?
18:11karolherbst: mupuf: !!! I did it https://travis-ci.org/karolherbst/nouveau/builds/160698761
18:11karolherbst: had to add a silly patch to modpost, because I was too lazy to see what I have to pass to make :D
18:20karolherbst: nice, isn't it?
18:23karolherbst: airlied: is there a way to download drm-next by commit?
18:26mupuf: karolherbst: indeed!
18:26mupuf: karolherbst: well, this is a git questyion ;)
18:27mupuf: git fetch origin <commit>
18:27karolherbst: I tried that
18:27karolherbst: didn't work
18:27karolherbst: I think you have to enable it on the git server for that to work
18:27karolherbst: let me test again though
18:28mupuf: but seriously, you won't optimize anything ;)
18:28karolherbst: mupuf: yep, doesn't work
18:28karolherbst: mupuf: :D except the storage maybe
18:28karolherbst: or time
18:29karolherbst: I wouldn't mind cloning a specific commit, cause that is frigging fast
18:29mupuf: ah, I see, and skipping the history
18:29karolherbst: now we would have to clone like with --depth 50000 to at least catch some kernel versions
18:29karolherbst: we could do 10.000 but then it won't work for a bit old trees
18:29karolherbst: also kind of bad
18:29karolherbst: anyway, that doesn't help much
18:29mupuf: well, don't mind it, travis is used all the time for the kernel
18:30karolherbst: yeah, but they don't cache 5GB files on AWS :D
18:30mupuf: well, given how often Ben pushes to the repo, it *really* does not matter
18:31mupuf: spend time on your presentation instead ;)
18:31karolherbst: yeah, I do while waiting :D
18:35karolherbst: k, plotting in latex :D
19:23karolherbst: uhh, plotting in latex is like the biggest crap... I want strings as my x labels, not numbers :(
19:24karolherbst: ahh, got it now...
19:59Hussam: karolherbst: hi, I found more information about the hibernate issue.
19:59Hussam: if I swapoff -a ; swapon -a, it will hibernate again.
20:00Hussam: now this is not an issue under the nvidia closed source driver. but is it possible the nouveau driver is not correctly freeing memory?
20:51karolherbst: mupuf: wtf...
20:51karolherbst: if I forcxe temp to 1°C I get 18.94W
20:52karolherbst: if I force it to 50°C I get 18.50W
20:52karolherbst: ohhh wait
20:52karolherbst: my mistake
20:52karolherbst: that's the voltage thing
20:56karolherbst: I thought the hw is doing crazy things :D but that's just me
21:13karolherbst: uhhh, does somebody play around with reator?
21:13karolherbst: it was off, but it was used recently
21:16imirkin: Hussam: are you sure this is nouveau-related? what if you don't load nouveau at all?
21:16karolherbst: imirkin: he said with nvidia it is fine
21:16imirkin: Hussam: anyways, it's possible we pinned something we shouldn't have, hibernate is basically never tested afaik
21:17imirkin: with the same kernel?
21:17karolherbst: no clue
21:17Hussam: imirkin: same kernel 4.8rc6
21:17Hussam: I can't unload nouveau.
21:17imirkin: Hussam: that's coz vtcon is bound
21:18karolherbst: Hussam: how big is your swap?
21:18Hussam: ram is 4G
21:18karolherbst: should be enough (tm)
21:18imirkin: but cleaning out swap "fixes" it?
21:19imirkin: i wonder if some gpu items get swapped out and we're missing a callback somewhere to properly clean it up on hibernate? i know nothing about these things sadly =/
21:20karolherbst: hibernation is "odd"
21:21Hussam: likely something of the sort. because there is another related note. actual ram usage increases after the first hibernate.
21:22Hussam: then stabalizes.
21:22Hussam: I can't tried to check if rmmoding nouveau frees those.
21:22karolherbst: is there a way to check what is swapped out?
21:23Hussam: haven't tried
21:24Hussam: imirkin, what would I need to do first (apart from existing X) to rmmod nouveau?
21:25imirkin: echo 0 somewhere
21:25Hussam: ok, let me look it up on google. someone probably already asked
21:25karolherbst: or something like that
21:25Hussam: ok, thank you
21:26karolherbst: mind you
21:26karolherbst: cause you won't see much after that
21:27Hussam: I'll ssh from my phone, type free, echo 0 > /sys/class/vtconsole/vtcon1/bind; free again and see what happens then reboot.
21:28imirkin: note that this will kill the console
21:28Hussam: Will ssh still work?
21:28karolherbst: it should
21:28Hussam: ok, cool.
21:36Hussam: karolherbst, imirkin: I think I found something useful. it's not the swap size that matters. after the hibernate trial, the system ram in use is 740MB
21:36Hussam: running that command and rmmod nouveau
21:36Hussam: brings it down to 156MB
21:36Hussam: which is what I was around outside X on NVIDIA driver.
21:37imirkin: hm. we probably pin something we shouldn't
21:37Hussam: 2) the hibernate issue:
21:37Hussam: I have 4GB ram.
21:37Hussam: this card has 2GB
21:37karolherbst: imirkin: so something gets pinned, swapped out and then it messes up?
21:38karolherbst: mhh wait
21:38karolherbst: that can't work this way, can it?
21:38Hussam: if gnome using more than 2GB ram with many apps running, the system is failing to hibernate on nouveau (but succeeds on NVIDIA)
21:38Hussam: I could be wrong but this is my uneducated guess.
21:38Hussam: I did see the memory go down from 740MB to 156MB just by rmmoding nouveau.
21:39imirkin: Hussam: do you know a kernel where it worked?
21:39imirkin: if so, a bisect would be nice
21:39Hussam: imirkin, no idea, sorry.
21:39karolherbst: Hussam: didn't you link the one bug report?
21:40Hussam: that's just something I found on google.
21:42Hussam: I rebooted 7 minutes ago. let me exit X and note the memory usage.
21:42mupuf: karolherbst: I was just sending the led patch
21:43mupuf: when you see the led go on on its own
21:43mupuf: then it is me turning it on manually
21:47Hussam: hi. running a game and closing it after a fresh boot, then exiting X, doesn't cause a memory increase.
21:47Hussam: it was down to 125MB
21:48Hussam: so it looks like hibernate is causing a memory leak in the nouveau kernel module?
21:53Hussam: imirkin, it was definitely an issue under linux 4.5 as well since that was when I first tried nouveau (on old card).
21:53Hussam: and I remember this particular issue.
21:53imirkin: hm ok =/
21:55karolherbst: mupuf: k
21:56karolherbst: mupuf: by the way, with clock gating we are around 40% more close to nvidia
21:56karolherbst: on kepler that is
21:57karolherbst: which means around 10% higher power consumption at full idle
21:57imirkin: in power usage?
21:57karolherbst: on my gpu on 0f
21:57karolherbst: 18.6W stock
21:57karolherbst: 17.2W clock gated
21:57karolherbst: 15.5W nvidia
21:58karolherbst: 10W 9.5W 8.5W on 07
21:59karolherbst: on maxwell2 the difference is more massive
21:59Hussam: if I echo 1 > /sys/class/vtconsole/vtcon1/bind and modprobe nouvea from ssh, do I get the console back?
22:00imirkin: not sure what you have to echo in there
22:00Hussam: the value at the moment after the reboot is 1
22:01karolherbst: maxwell2 on 07: 14.8W vs 13.0W ...
22:03Hussam: I apparently already filed a bug report too https://bugs.freedesktop.org/show_bug.cgi?id=94949
22:09Hussam: maybe on attempting to hibernate, nouveau is caching to physical ram instead of swap with the assumption that the kernel is just going to swap it anyway? because on failed attempts, the memory increases as well.
22:10Hussam: so the issue is at hibernating, not resuming.
22:12karolherbst: mupuf: this is fun, the effect of clock gating is bigger if secboot is enabled :O
22:14karolherbst: on 0f without secboot: 38.5 -> 37.5W
22:14karolherbst: with secboot: 38.5W -> 29.5W
22:30karolherbst: mupuf: mhh odd, I think we might be wrong in calculating the power consumption...
22:31karolherbst: pwr_read says 12.9W where nvidia-smi says 9W
23:27kugel: karolherbst, imirkin: do you know why I my nv card isn't set as primary anymore when I use nouveau ddx?
23:27kugel: I have set the intel to inactive in xorg.conf
23:27karolherbst: cause it ain't work that way
23:28imirkin: 'set as primary'?
23:29kugel: the one used for 3d stuff
23:31kugel: I have Inactive "intel" in my ServerLayout (according to https://wiki.archlinux.org/index.php/PRIME#Discrete_Card_as_Primary_GPU) but it doesn't work anymore for some reason
23:32imirkin: leave intel out entirely?
23:34kugel: imirkin_: want to use it for reverise prime
23:35kugel: but nevermind, I had a stupid typo in my xorg.conf. works now
23:36kugel: scrolling in firefox is still slow though
23:37imirkin: that's not going to be very power efficient. not sure if that matters to you
23:38kugel: what do you mean?
23:39imirkin: disable acceleration in firefox
23:39imirkin: that should speed it up nicely =]
23:39imirkin: a bunch of people have, btw, reported that firefox is able to trigger stupidity in nouveau now
23:39kugel: I'm using "xrandr --setprovideroutputsource modesetting nouveau" to display stuff on the laptop display
23:41kugel: no change without acceleration
23:46imirkin: kugel: nvidia gpu will always be powered in that scenario
23:52kugel: imirkin: yea, i know. that's on purpose
23:53kugel: I've got a eGPU setup with a display attached to the external nvidia
23:54kugel: so when playing games they should run on that nvidia. render offload via prime is not an option because it's too slow (only a pcie gen1 x1 link)
23:55kugel: so I want to use reverse prime to have the nvidia render stuff for the laptop display (mostly static content)