03:51 hakzsam: hey guys, I plugged two NV50 but I want to load nouveau only for one card, how can I do that?
03:52 hakzsam: I tried to unbind device before re-loading Nouveau without success
04:00 hakzsam: got it :)
05:10 RSpliet: mlankhorst: braaksel? classy!
05:14 RSpliet: imirkin: I don't really get what you're trying to achieve... if it's understanding memory reclocking; I just took an old trace from mwk's nvc1
05:14 RSpliet: ran it through demmio
05:15 RSpliet: and get readable memory reclocking scripts
05:15 RSpliet: like that: http://hastebin.com/oziriwipev.md
06:21 alexandernst: As airlied said, my 4 monitors - 2 cards setup is working fine with 1.17 and his patch \o/
06:22 alexandernst: KUDOS!! The only thing I need to do is xrand --setprovideroutput 1 0. My question is, can I make this change permanent so I don't have to run it every reboot?
07:14 buhman: wow
07:14 buhman: alexandernst: how are you starting your X server?
08:11 imirkin: RSpliet: i don't want to _understand_ anything... just extract the necessary bits and replay them.
08:20 alexandernst: buhman: no xorg.conf, just the command I pasted. This enabled the 3rd and the 4th monitor so I can arrange them using KDE's "Monitors" tool
08:20 alexandernst: buhman: basically, this is vanilla kernel 3.18 + Xorg 1.17 + nouveau (latest I guess, I'm no Arch)
08:20 alexandernst: buhman: also note this is with 2x NVIDIA GT610 *not* on SLI
08:20 imirkin: alexandernst: no way to make it permanent afaik. some DE's will auto-do it for you thought.
08:21 alexandernst: imirkin: damn :(
08:21 buhman: alexandernst: that's not what I asked
08:22 alexandernst: buhman: uhmm... I have "exec startkde" in my .xinitrc . I guess this is what starts X
08:22 buhman: startx you mean
08:22 buhman: so put that xrandr in your .xinitrc
08:22 alexandernst: no, startkde
08:23 buhman: 'startkde' starts, you know, kde
08:23 buhman: which is not an X server.
08:24 alexandernst: yes. But I'm not sure how X itself gets started. Maybe "startkde" starts X too?
08:24 buhman: no
08:24 imirkin: heh
08:24 imirkin: you might think that a file like '.xinitrc' wouldn't actually be the one starting X
08:24 imirkin: much like '.bashrc' doesn't _start_ bash
08:24 alexandernst: imirkin: indeed, I followed a silly logic
08:24 alexandernst: how can I find how X is started?
08:25 buhman: alexandernst: you're using xorg-xinit whether you realize it or not
08:25 imirkin: you probably have a *dm doing it
08:25 imirkin: xdm, gdm, kdm
08:25 buhman: alexandernst: you should put that xrandr command in your .xinitrc
08:25 alexandernst: oh ok, that would be sddm
08:25 buhman: before the exec startkde
08:25 alexandernst: buhman: I tried that but it didn't work :/
08:25 buhman: sounds like you aren't actually using .xinitrc then
08:26 imirkin: yeah, xinitrc usually doesn't get used
08:26 alexandernst: how can I find that for sure?
08:26 imirkin: you have to actually run xinit for it to work :)
08:26 imirkin: maybe .xsession
08:26 imirkin: or maybe your dm ignores all that and just does its own thing
08:26 alexandernst: no ~/.xsession
08:26 buhman: alexandernst: you're the one who set your thing up, you tell us? ;p
08:26 alexandernst: buhman: :D then I'm screwed
08:27 imirkin: all those files are from the before-time, back when it was easy to do things. now linux has gotten more "user friendly", aka harder to use.
08:27 alexandernst: I setup my desktop years ago. Erased those bits of memory long time ago...
08:27 alexandernst: ok, I feel like I should ask #kde folks where exactly is sddm starting X and how can I tell it do stuff
08:28 imirkin: afaik the kde desktop thing should be doing the setoutputsource stuff for you
08:28 imirkin: so it's surprising that it isn't
08:29 alexandernst: then I should report a bug to bugs.kde.org ?
08:29 alexandernst: saying that if 2 GPUs are available, KDE should do --setprovideroutpu 1 0
08:29 alexandernst: ?
08:34 imirkin: no, it's not a bug... i just thought that it did that
08:46 glennk: alexandernst, put the xrandr command in ~/.xprofile ?
09:00 infinity0: this https://bugs.freedesktop.org/show_bug.cgi?id=71994 mentions http://cgit.freedesktop.org/~darktama/nouveau/commit/?h=devel-pm&id=ffbf93ba1eb5f05d22bd5419e5f314188801155b but i get "bad commit"
09:02 imirkin: infinity0: there's no fermi reclocking support atm
09:02 infinity0: what are the details about that?
09:03 imirkin: it's a project on which next to no progress has been made over the past couple of years.
09:04 imirkin: (largely due to a lack of trying)
09:05 infinity0: imirkin: i see hints from various online sources that it actually works with kepler, which is a newer series, is that true?
09:06 imirkin: that's true.
09:06 imirkin: although 'works' is a generous term... there's some support
09:09 infinity0: i guess i could try to recompile with changing "false" to "true" in line 441 of https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/core/subdev/clock/nvc0.c?id=refs/tags/v3.18.7 and see if it blows up my card?
09:10 infinity0: the reported possible states in /sys/class/drm/card0/device/pstate actually match the specs, just i can't write to it
09:10 imirkin: sure, you can
09:12 imirkin: i actually didn't realize as much as that was already done
09:15 infinity0: i wonder if there is a quicker way to iterate than to recompile the kernel every time ¬.¬
09:15 infinity0: this seems quite interesting and adaptable to nvc0 if only i had the background knowledge to understand it https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/gpu/drm/nouveau/core/subdev/clock?id=refs/tags/v3.18.7
09:15 imirkin: you can just rebuild the module
09:16 imirkin: your biggest problem will be this:
09:16 infinity0: ah i suppose, make is supposed to be smart about these things
09:16 imirkin: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c#n129
09:16 imirkin: you could turn off memory reclocking though and "avoid" that problem
09:17 imirkin: (of course you also "avoid" having faster memory)
09:22 infinity0: imirkin: what's the problem with it?
09:22 imirkin: infinity0: it hasn't been written in a way that works on multiple cards :)
09:23 infinity0: ah ok i see
09:25 imirkin: which card do you have, out of curiousity?
09:25 infinity0: 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1)
09:25 infinity0: i think that means not OEM
09:26 imirkin: well, it means NVCE. good card; i can see why you want reclocking :)
09:27 infinity0: yes :)
09:28 infinity0: it's running on 1/10th of its normal speed atm, i think
09:29 imirkin: these things are hard to judge... memory and core speed have a fun non-linear relationship
10:05 joi: is there any trick to speed up apitrace trim?
10:08 imirkin: obtain a faster cpu :)
10:08 imirkin: found a bug?
10:10 joi: yup, "read fault at 0x000d881000 [PTE] from GR/GPC0/PE_2 on channel 0x007f8f1000 [glretrace[7515]]" and "PGRAPH engine fault on channel 4, recovering..."
10:10 imirkin: nice... haven't seen one of those in a while
10:10 imirkin: that must be a resource management issue =/
10:10 imirkin: which are anti-fun to track down
10:11 joi: apitrace trim gets to 37% of the file and then stops
10:11 imirkin: try a more recent apitrace?
10:12 joi: i'm using the latest/greatest
10:12 imirkin: hm ok =/
10:34 infinity0: re the line 441 false->true, i wonder if i can identify the right bit to flip in my existing kernel binary image, so that i don't even need to recompile it ¬.¬
10:34 infinity0: i guess this is a good exercise to brush up on my low-level skills
10:42 imirkin: seems like it'd be faster to just recompile
11:05 RSpliet: under normal circumstances you're not recompiling a full kernel, only the changed files
11:06 RSpliet: (Fedora RPMBuild is not a normal circumstance)
14:51 alexandernst: A single GT610 drives fine 2 monitors at 1080p (even with translucent effects and so on), but as soon as I run "xrandr --setprovideroutputsource 1 0" to enable my second GT610 and my 3rd and 4th monitor, the performance gets worse. I'd expect the same performance as I'm doubling the number of monitors and the number of GPUs, but that is not the case. I don't see any anormal CPU usage (no process is using more than 1% or 2%) , but all the
14:51 alexandernst: windows are freezing randomly (in gaps from a couple of seconds to a couple of minutes).
14:52 alexandernst: Is that expected? Is it because of xandr --setprovideroutputsource? Or is it because of the hardware? (GT610 is a really low end card, anyways it should be able to move windows around, which is the only thing I'm doing)
14:52 mgottschlag: iirc in such situations the system would completely disable hardware acceleration, although I think that has changed
14:53 mgottschlag: but it still will only be one GPU which does the rendering I think
14:53 alexandernst: oh, so it is because of the hardware
14:53 mgottschlag: which will draw 4 images and send 2 of them to the other GPU
14:53 alexandernst: is there a way I can make both GPUs work?
14:54 mgottschlag: I don't know, I'd be surprised if multi-GPU setups wouldn't introduce lots of software rendering paths somewhere
14:54 mgottschlag: I don't think there is any way, that's just something which isn't frequent enough to be supported
14:54 alexandernst: ok, I see
14:55 alexandernst: so, the only way would be to get another card, right?
14:55 mgottschlag: and is probably particularly difficult to support as well, because applications would need to know about two GPUs (likely two seperate OpenGL contexts etc)
14:55 alexandernst: do I need to get 2 identical or can I reuse one of my GT610?
14:55 mgottschlag: but I might be totally wrong, I've never done anything like this
14:57 mgottschlag: I think this should work with arbitrary hardware combinations
14:58 alexandernst: ok, let's see if I can get another card and try :)
14:58 mgottschlag: and I just looked this stuff up, it actually should perform well
14:58 alexandernst: so both GPUs should be rendering?
14:59 mgottschlag: no, but the copy between the two GPUs shouldn't be slow, and the setup does not disable hardware acceleration
14:59 mgottschlag: such setups used to be a lot slower before modern linux graphics drivers
15:00 alexandernst: hmmm
15:00 mgottschlag: actually, with 4 monitors side by side you might hit some output size limit
15:00 alexandernst: is there a way I can test if there is acctually hardware acel?
15:00 alexandernst: no, this is actually 2 on top of 2 setup
15:01 mgottschlag: okay, no idea then
15:01 mgottschlag: better ask someone who actually has done this stuff before
15:02 alexandernst: I have found that 4 monitors in Linux is actually really weird
15:02 alexandernst: I have no idea how to find a person that has done this setup
15:02 alexandernst: (and I have been idling in this channel asking stuff like this for a week now)
15:05 alexandernst: one more question
15:06 alexandernst: does the GT7xx have the same support as the GT6xx ?
19:11 infinity0: ah, yes i only need to compile nouveau.ko and not the whole kernel, of course
19:12 infinity0: 000000000001bd90 <nvc0_clock_ctor>:
19:12 infinity0: 1bd90: e8 00 00 00 00 callq 1bd95 <nvc0_clock_ctor+0x5>
19:12 infinity0: whoop whoop, ghex time ¬.¬
19:12 infinity0: (famous last words)
19:12 infinity0: i-have-no-idea-what-im-doing.jpg
19:14 imirkin: why bother?
19:14 infinity0: i don't have compile stuff set up on my machine, i figure it'd be quicker to try it out this way
19:57 infinity0: $ cmp -l /lib/modules/3.18.0-trunk-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko{,.bak}
19:57 infinity0: 114219 1 0
19:57 infinity0: will try this out tomorrow and see what happens ¬.¬
19:57 infinity0: <3 objdump -SF and gdb disassemble /mr
20:02 imirkin: of course it'd be hilarious if you have some sort of kernel module signature verification thing going on that will now fail
20:03 imirkin: skeggsb: in case you missed it, someone's claiming you broke ACPI firmware loading in 3.19
20:04 imirkin: skeggsb: and also something funky wrt nvif and the SOR_HDA_ELD call
20:04 skeggsb: yep, i seen them both
20:04 imirkin: kk
20:06 skeggsb: the eld one i'd have said was fixed already, except the claim is it doesn't work in 3.19 too
20:06 skeggsb: his patch looks pretty similar to the current code...
20:06 skeggsb: but it *was* broken at some point
20:16 imirkin: it wasn't too clear to me if he was quoting fixed or broken code
20:17 imirkin: oh. i guess +++ = not working
20:19 imirkin: so i guess it wants the struct not to be packed... maybe the __packed is getting inherited by the base?
20:20 skeggsb: when i get home from the office i'll see what happens here with my tv, but last i used it, it worked as expected
20:21 imirkin: well apparently it's only something fancy which breaks... probably because 'args' is misalend
20:21 imirkin: misaligned*
20:21 imirkin: er, make that 'data'
20:21 skeggsb: well yeah, but my tv has that "fancy" stuff
20:22 imirkin: should check the eld info as reported by hda
20:22 imirkin: what happens if you add a
20:23 imirkin: assert(offsetof(args.data) == sizeof(nv50_disp_mthd_v1) + sizeof(nv50_disp_sor_hda_eld_v0))
20:23 imirkin: or something