00:00 mishehu: I realize that.
00:00 mishehu: given that I've had success with vdpau on other non-mcp79/mcp7a chipsets with nouvea on kernels 4.6.x, I don't currently suspect that either mesa or vlc is the fault here.
00:01 imirkin: ok, i'll defer to your expertise.
00:02 imirkin:should have just kept quiet.
00:02 mishehu: and the fact that I see crap like this in dmesg: nouveau 0000:03:00.0: fb: trapped write at 0020414064 on channel -1 [1f799000 unknown] engine 05 [PFIFO] client 08 [PFIFO_READ] subclient 01 [SEMAPHORE] reason 00000002 [PAGE_NOT_PRESENT] , nouveau 0000:03:00.0: Xorg[1778]: failed to idle channel 2 [Xorg[1778]], nouveau 0000:03:00.0: DRM: GPU lockup - switching to software fbcon, seems to give a bit more
00:02 mishehu: credence to my hunch.
00:03 mishehu: imirkin: I'm not against constructive input, but you're just guessing as well. :-)
00:04 imirkin: mishehu: pretty much. in the absence of access to the nvidia HDL and full pci traces of your system, that's all anyone can do
00:06 imirkin: if you can identify a working version of the system for your hw configuration, then you can figure out the difference to the non-working version
00:06 imirkin: keep in mind that there are lots of moving pieces.
00:06 mishehu: there's a lot of more info at http://kusit.com/picture_library/tasrit-nouveau.txt from last night before I stumbled upon that link I posted above about my fbcon output.
00:08 imirkin: my bet is that your fbcon troubles on v4.6 are that you forgot to enable some config option - i think this happened to a ton of people. the "make a fbdev out of the drm device" option got split out and disabled by default i think.
00:08 mishehu: imirkin: I hear yah. mesa, xorg driver, libdrm, kernel drm, fb, kms, nouveau itself, and probably a half dozen other things that I don't know about.
00:09 imirkin: don't exactly remember when though
00:09 imirkin: either way, vdpau never worked well on any nvidia gen - there were always funny artifacts with H.264
00:09 mishehu: imirkin: my kernel .config is in that kusit link above in case it might ring a bell if you saw it
00:09 imirkin: mishehu: i saw it, but i assumed it was for v4.8
00:09 mishehu: that one is yes
00:10 imirkin: CONFIG_DRM_FBDEV_EMULATION=y
00:10 imirkin: that's the one to check for in your 4.6 setup
00:10 mishehu: sec
00:10 mishehu: need to fire up the wife's laptop.
00:16 mishehu: yeah that kernel setting is there for her laptop, which is a quadro fx 880m . kernel 4.6.4. it's also set on this atom-ion system that I'm having trouble with.
00:16 mishehu: the atom ion using 4.8.4
00:16 mishehu: otherwise they're both slackware64 14.2 boxes.
01:11 mishehu: ugh. I don't wnat to but looks like I'm going ot have to try the old proprietary 340.98 drivers for now. :-(
07:58 karolherbst: mupuf: :D nice
09:40 mupuf: karolherbst: yeah, so you need to set the first two bytes of the entry to 0x0101 and then, there is another word that has the most influence
09:40 mupuf: http://codepad.org/ERHiekks
09:40 mupuf: on normal cards, it is set to 10
09:40 mupuf: on mine, it is set at 140
09:54 karolherbst: :D
09:54 karolherbst: that looks.. funny?
09:55 mupuf: yep
09:56 mupuf: there is another byte or word that has a small influence
09:56 mupuf: looks like an offset to apply before dividing
09:58 mupuf: but this division looks funky for sure
10:01 karolherbst: mhh 8
10:01 karolherbst: there is a cap value, right?
10:02 karolherbst: mind removing the cap and see what happens to the lower values?
10:02 karolherbst: 0-39
10:03 karolherbst: I could imagine that until 39 it multiplies or so
10:10 mupuf: karolherbst: http://fs.mupuf.org/mupuf/nvidia/6b11.png
10:12 mupuf: seems like some bits are not controling something else
10:13 karolherbst: weird
10:15 karolherbst: but the thing looks pretty linear, do you think you might be able to change that?
10:19 mupuf: yep, it does look very linear ... aside from the begining and the end
10:20 karolherbst: yeah
10:28 mupuf: yeah, it makes no sense to me
11:25 karolherbst: mupuf: but do you think you know enough to implement the stuff for your fan?
11:25 mupuf: not yet
11:26 mupuf: I will need more data for the second mode
11:26 mupuf: err, second parameter
11:26 mupuf: and then figure out what the other modes are
11:26 mupuf: and what are all these parameters
11:26 mupuf: akin to what you did for the voltage mapping table
11:27 mupuf:is using nvidia-smi instead of X to load nvidia though
11:27 mupuf: it is faster and returns when it is done
11:27 mupuf: I added a 250ms delay though because the fan was sometime not yet fully initialized
11:28 mupuf: but I get ~1.25s/test
11:28 karolherbst: mhh
11:28 mupuf: instead of ~3s with X
11:28 karolherbst: nvidia-smi causes one problem though
11:28 mupuf: ?
11:29 karolherbst: the driver deinits parts
11:29 mupuf: right
11:29 mupuf: works for the fan though
11:29 karolherbst: good
11:29 mupuf: because pdaemon is responsible for it
11:29 karolherbst: ahhh
11:29 karolherbst: I see
11:29 karolherbst: well for clocks it doesn't cause the driver cares shit about the gpu then
11:29 mupuf: ;)
11:30 karolherbst: 100W over the budgeT? meh, I don't care
11:30 mupuf: ahah
11:30 mupuf: unlikely to happen without a driver
11:30 karolherbst: right
11:33 karolherbst: ohh I uploaded imirkin vbios by the way
11:34 mupuf: good, sorry, I forgot to do it
11:34 karolherbst: I meant his gk208 one, a few days ago
11:34 karolherbst: or was it another one? no idea
11:34 karolherbst: I uploaded one, that's for sure
11:59 Tomin: < karolherbst> seriously, that is a tesla faking to be a fermi card
11:59 Tomin: oops, sorry
16:08 hbsaul: I have difficulties connecting to mysql database.. getting the error on line 6
16:22 Ramattack: Good afternoon
16:23 Ramattack: I have a GT720 nvidia graphic card with two monitors connected to it... one of them through dvi and the other one through hdmi
16:23 Ramattack: if I use other composition different to xrender in plasma... it ends up by hanging
16:25 Ramattack: http://pastebin.com/KEWDm29i
16:25 Ramattack: could anyone help me plase?
16:25 Ramattack: thanks a lot
16:32 manio: hi guys, please help me... i have a problem with two monitors connected to my geforce gt220
16:33 manio: does nouveau support two digital displays at the same time (as the binary blob)?
16:33 manio: I have two nvidia cards
16:33 manio: on one analog+digital works fine
16:34 manio: but the second one - two digital outputs are connected, I can see in the /sys/class/drm:
16:34 manio: cat /sys/class/drm/card1-HDMI-A-4/status
16:34 manio: connected
16:34 manio: but when starting Xorg, it is complaining that:
16:34 manio: (WW) NOUVEAU(0): No outputs definitely connected, trying again...
16:34 manio: while this is not true - the outputs are definitelly connected indeed!
16:35 manio: I can even see the modes probed by the kernel
16:53 Ramattack: Hi manio, Nouveau does
16:53 Ramattack: I'm using them
16:53 Ramattack: one in hdmi and one in dvi
16:54 manio: Ramattack: on what card?
16:55 RSpliet: manio: two outputs, either analogue or digital, should work
16:56 Ramattack: gt 720
16:56 Ramattack: I have had too one analog one digital hdmi
16:56 manio: RSpliet: i have it working on binary blob, but not on nouveau :(
16:57 RSpliet: Ramattack: the first set of messages look like userspace problems, make sure mesa and libdrm and the likes are updated. The second ones are probably caused by fault handling, but it could be worth updating your kernel to >= 4.7 to be sure
16:57 manio: RSpliet: maybe it is related with the https://bugs.freedesktop.org/show_bug.cgi?id=38074...
16:58 manio: but Ben's fix is for nv50 :(
17:00 RSpliet: manio: the problem sounds similar, but the last patch mentioned in the bugreport does not cover your GPU
17:01 RSpliet: so if you're running a new kernel (4.8) and X.org, please file a bug
17:01 RSpliet: a new xorg that is ;-)
17:13 Ramattack: Thanks a lot RSpliet but is a new fresh gentoo installed system... media-libs/mesa-12.0.1:0 and x11-libs/libdrm-2.4.70:0
17:14 Ramattack: RSpliet I'm using mesa Gallium
17:14 Ramattack: could all that be ok?
17:20 RSpliet: Ramattack: sounds new enough
17:21 RSpliet: Presumably that means your kernel is newer than 4.7 too... then I can't help you much further than bugzilla atm either, sorry
17:21 RSpliet: I haven't encountered this myself (gnome-shell tends to behave from what I've seen, hasn't exposed such problems)
17:22 imirkin_: Ramattack: moral of the story: use xrender :)
17:22 Ramattack: I do it :)
17:23 Ramattack: and works fine with that
17:23 Ramattack: but.... I assume the transparency and so... is worse... :)
17:23 imirkin_: but it doesn't hang
17:24 Ramattack: RSpliet: I use 4.4.21
17:24 Ramattack: imirkin_
17:24 Ramattack: imirkin_: true :)
17:24 imirkin_: anyways, if you really want to use kde stuff, nuke nouveau_dri.so which will remove attempts to do hardware accel of GL
17:24 imirkin_: and then you'll use llvmpipe for your GL accel and won't get hangs
17:25 imirkin_: manio: pastebin dmesg and xorg log
17:25 Ramattack: imirkin_: but xrender does not use 3d acceleration
17:25 Ramattack: imirkin_: how does it create effects?
17:25 imirkin_: Ramattack: it doesn't use GL to accelerate, it's accelerated by the EXA module in the nouveau ddx
17:26 Ramattack: I see....
17:26 imirkin_: (well, ultimately by the XRender extension)
17:26 imirkin_: (which in turn is accelerated by ... )
17:26 Ramattack: imirkin_: yep was a question about how it works.... just relying in the own processor of the machine?
17:26 Ramattack: and giving all job done to the graphic card?
17:26 imirkin_: XRender is accelerated by the gpu
17:27 Ramattack: imirkin_: really?
17:27 imirkin_: yes.
17:27 imirkin_: not 100% of it, but most of it
17:27 Ramattack: and why then it does hang ?
17:27 Ramattack: and gl yes?
17:27 Ramattack: it does not
17:27 Ramattack: hang I meant
17:27 imirkin_: because the EXA backend is simple and well-tested and handles various error-scenarios
17:27 Ramattack: xrender works fine for me
17:28 Ramattack: I see...
17:28 Ramattack: I see :)
17:28 Ramattack: that's the reason because I was so curious
17:28 Ramattack: I didn't know if it was using gpu or not
17:28 imirkin_: it should be, unless you tell your DDX to disable acceleration
17:28 imirkin_: in which case it'll all be cpu-based fallbacks
17:29 Ramattack: how do you say that? I don't think had said that anyway...
17:29 imirkin_: Option "NoAccel" "true"
17:29 imirkin_: (iirc)
17:29 imirkin_: or boot with nouveau.noaccel=1
17:29 Ramattack: not at boot not at xorg because has no config by my side....
17:30 Ramattack: :) just the one generated by system preferences and screen
17:30 Ramattack: later I'm using soft render or how... it was ....
17:30 Ramattack: you can use clear, soft or.... medium
17:30 imirkin_: anyways, tons of people have been having issues with nouveau and KDE
17:31 Ramattack: I see...
17:31 imirkin_: my advice has been to either ditch KDE or ditch nouveau's GL backend.
17:31 imirkin_: whichever is preferable to the person in question
17:31 Ramattack: but move to gnome and to go through systemd??? wow
17:31 Ramattack: I prefer dying :p
17:31 imirkin_: not sure which part of that was saying to use gnome or the highly-unrelated systemd
17:32 imirkin_: but ... whatever you like.
17:32 Ramattack: I like gnome
17:32 Ramattack: have beein using it all the life
17:32 Ramattack: but now it needs systemd
17:32 Ramattack: :)
17:32 Ramattack: that's what I don't like :)
17:32 imirkin_: srsly?
17:32 imirkin_: that's crazy
17:32 Ramattack: yep I hate systemd
17:33 Ramattack: what exactly is crazy? :) systemd or the hate to systemd? :)
17:33 karolherbst: the latter
17:33 Ramattack: or do you use gnome withouth systemd
17:33 Ramattack: lol
17:33 Ramattack: I hate it :)
17:33 Ramattack: I preffer openrc which Gentoo uses
17:33 karolherbst: not because I like systemd, I just feel that "hate" is something really strong
17:33 karolherbst: and nobody really means it
17:33 karolherbst: which means, the word looses its meaning
17:34 imirkin_: depending on systemd by anything that doesn't have "systemd" in its name
17:34 ajax: man. imagine being so intimately involved with the startup of your system that you manage to form opinions about how it's implemented
17:34 ajax: truly weird.
17:34 karolherbst: ajax: that is calle "fear"
17:34 karolherbst: *called
17:35 ajax: i shouldn't talk i suppose
17:35 Ramattack: well I don't like systemd :) let's let there that topic :p
17:35 orbea: it does a lot more than just init, but apparently gnome3 can run without it not that I am going to try. I think funtoo or gentoo had patches?
17:35 Ramattack: just don't like :)
17:35 imirkin_: ajax: i don't think a random piece of software should depend on a specific init system
17:35 karolherbst: Ramattack: well I am fine either way, I am just against the overusage of the word "hate", don't get me wrong
17:36 imirkin_: ajax: if you think that's weird, then we just have a hard difference of opinion.
17:36 Ramattack: :) ok mate karolherbst
17:36 karolherbst: imirkin_: true
17:36 Ramattack: mates should go home... :) come tomorrow :)
17:36 Ramattack: thanks a lot to all :)
17:36 ajax: imirkin_: i guess it depends on what counts as "random" and why the dependency is present.
17:36 karolherbst: but then again, you do want to have some kind of dependency management in your init system, at least on modern systems
17:36 Ramattack: bye!!
17:36 imirkin_: ajax: random is a package without "systemd" in its name. like systemd-asdf depending on systemd - seems reasonable.
17:37 imirkin_: ajax: a package that one might want to use generally, like gnome - unreasonable.
17:37 ajax: that's... kind of arbitrary. you wouldn't require every program that requires glibc to start with glibc-
17:37 ajax: but anyway
17:37 karolherbst: ajax: because most of them, don't depend on glibc anyway
17:37 ajax: i'm just starting shit, i'll stop
17:37 imirkin_: ajax: mmmm ... i kinda would. my hope is that most of them depend on some POSIX set of it.
17:38 karolherbst: yeah, they should depend on the POSIX C API
17:38 ajax: (posix is terrible)
17:38 karolherbst: but most of them are crappily implemented and use extensions
17:38 imirkin_: ajax: or at least i'd point at them for being jerks about it :)
17:39 imirkin_: ajax: ultimately the init system is tied to a lot of "system" programs. gnome is some random silly user-runnable app. it shouldn't have antyhing to do with init.
17:39 karolherbst: imirkin_: well, logind provides user session functionality
17:39 karolherbst: which is a sane thing to have
17:40 imirkin_: karolherbst: fine. so package that off to the side.
17:40 imirkin_: karolherbst: and call it gnome-systemd-hotness
17:40 imirkin_: or gnome-logind or whatever.
17:40 karolherbst: it's a dbus API ;)
17:40 imirkin_: anyways, i used to use gdm until they made *that* depend on gnome. that was a sad day.
17:41 imirkin_: now i can't have any gnome stuff on my system. oh well.
17:41 halfline: it was a sad day when the gnome display manager used gnome ?
17:41 ajax: again: depends where you draw the line for "system". why should the desktop _not_ be a system component.
17:41 karolherbst: halfline: kind of
17:41 imirkin_: halfline: i always thought of it as the GTK+ display manager.
17:41 karolherbst: ajax: because it isn't
17:41 ajax: that we think it's replaceable means we have a bunch of not-quite-interchangeable parts that all collectively don't work
17:41 karolherbst: ajax: do you expect gnome to be part as the "linux system"?
17:41 ajax: we could instead have had, you know, one thing that works.
17:41 karolherbst: no, you don't
17:42 karolherbst: *of
17:42 ajax: i'll thank you not to decide my opinions for me
17:42 manio: imirkin_: http://skyboo.net/pub/nouveau/
17:42 karolherbst: do you expect "cp" to be part of the "linux system"? yes you do
17:42 imirkin_: halfline: and if it depended on some silly gnome lib, i'd be fine with that. sadly it depends on gnome-shell, which is some uber-package.
17:42 ajax: i'm not going to say _gnome_ should be _the_ system component.
17:42 karolherbst: do you expect a DE to be part of the "linux system" on a server?
17:42 ajax: it's part of the linux system on the server OS my employer sells
17:42 imirkin_: ajax: ultimately it's sad because of the direction a lot of projects are taking
17:43 imirkin_: ajax: it used to be that things were more open, everything worked with everythign else
17:43 ajax: and it's part of that system because our customers expect and require it
17:43 imirkin_: ajax: now it's like you HAVE to use this if you want to use this other thing
17:43 ajax: so, yes, i do expect a DE as a server component
17:43 imirkin_: ajax: which is a much more closed ecosystem =/
17:43 karolherbst: ajax: so you think everything is right, what your employee tells you? Seriously?
17:43 karolherbst: you want me to think this about you?
17:44 ajax: i don't really care what you think about me, but i think you misinterpret me there
17:44 halfline: imirkin: well the alternative is that gdm would provide it's only window manager / screen reader / magnifier / keyboard layout switcher
17:44 ajax: i think it _is_ reasonable that a DE work on a server OS
17:44 halfline: imirkin: reusing code rather than have duplicate code makes sense to me ...
17:44 ajax: i think it's reasonable that it be optional, if you like
17:44 imirkin_: halfline: all i want is a thing to type my username/password thing that doesn't have the ugly xdm background.
17:44 karolherbst: ajax: sure, but then you can't expect it to be part of the "system"
17:44 karolherbst: if it's optional
17:45 halfline: imirkin: fair enough, GDM probably isn't what you want then
17:45 halfline: GDM is for gnome
17:45 imirkin_: halfline: GDM *was* what i wanted :) it's not anymore.
17:45 halfline: i mean GDM can start non gnome desktops
17:45 halfline: but it's a part of gnome
17:45 ajax: karolherbst: yes i can. just as linux-the-kernel has optional, say, ipv4.
17:45 ajax: there's not two ipv4 stacks
17:45 imirkin_: and it was very sad when that change was made
17:45 imirkin_: it was working perfectly fine, and now it's gone.
17:45 halfline: to be clear, i'm the person who made that change
17:45 karolherbst: hihi
17:46 imirkin_: halfline: i see. well, i'm still very sad about it.
17:46 imirkin_: i used it for a decade, maybe more.
17:46 karolherbst: it might make sense to have a libgnome library gdm uses
17:46 imirkin_: and then i was able to convince gentoo to not upgrade it
17:46 karolherbst: but it shouldn't really depend on anything else
17:46 imirkin_: but eventually something happened and i had to move away from it
17:46 halfline: well i see where you guys are coming from
17:46 halfline: and i'm sorry that gdm does'nt ift your use cases anymore, but doing that was one of the best things i could have done for gdm
17:47 halfline: gdm reimplemented everything that was already in gnome
17:47 halfline: and it did it badly
17:47 halfline: so bugs were getting fixed twice
17:47 halfline: and then there was gnome-screensaver
17:47 halfline: which does pretty much the same sort of thing as gdm but it looked completely different
17:47 halfline: now the login screen and the unlock screen look and act the same
17:48 halfline: because they use the same code underneath
17:48 karolherbst: ajax: but there are many DE stacks. All I wanted to say is, that if you want to make decent assumptions on the system your applications runs on, you should expect a few things to be there
17:48 halfline: and now the a11y tools work the same inside gnome and outside gnome
17:48 karolherbst: ajax: one of systemds goal is to add a little bit more to that
17:48 ajax: karolherbst: i'm suggesting there should be fewer DEs, yes. like, one would be nice.
17:48 karolherbst: I don't
17:48 ajax: but that's personal opinion.
17:49 karolherbst: users have different views on things
17:49 karolherbst: and some DEs suite other users better
17:49 karolherbst: if there is just one, we wouldn't get to anything
17:49 orbea: some dont even use DEs. :)
17:49 karolherbst: because there is always that guy "this is crap, nak"
17:49 karolherbst: let gnome guys do gnome, and kde guys to kde and lxqt guys reuse kde components as they like
17:49 karolherbst: it's all fine
17:50 ajax: a more objective observation might be that expecting every DE to interoperate with every corresponding component from every other, or from every possible "system" layer below it, is the kind of avoidable polynomial explosion that encourages bad software
17:50 karolherbst: right
17:50 karolherbst: that's why systemd wants to introdude a common "system" layer
17:50 karolherbst: ontop of the kernel
17:50 karolherbst: so that every DE uses the same user session thing for example
17:51 karolherbst: or the same logging system
17:51 ajax: so in that light, being mad at gnome for requiring APIs that only systemd happens to implement is asking gnome to reimplement "systemd for people who don't like systemd" in openrc or upstart or whatever
17:51 ajax: that's a pretty unreasonable thing to ask for
17:51 karolherbst: ajax: something like that, yes
17:51 karolherbst: I see you understand the issue
17:52 ajax: only been fighting it professionally for like half my life ;)
17:52 ajax: okay, a third
17:52 ajax: still
17:52 karolherbst: well
17:52 karolherbst: as long as it stays technical
17:52 karolherbst: I never looked into the depths of systemd, so I don't say any technically about it, because I can't
17:52 ajax: (not that i'm trying to pull rank, sorry if it comes across that way)
17:54 ajax: and it's great that people can take their copy of any particular ball and go play with it by themselves
17:54 karolherbst: anyway, most of the anti systemd stuff is completly unreasonable and just "fanboyism" or "following others" and this is always the feeling I get when I see "hate" and "systemd" in one sentence
17:54 ajax: that works for individuals. it doesn't work for projects, and it doesn't work for products.
17:54 karolherbst: alone to hate software
17:55 karolherbst: like the software did anything harmful to you
17:55 karolherbst: like destroying your house or so :p
17:55 ajax: yeah. a lot of it is like a lot of the "minimal desktop" fetishism
17:55 ajax: i don't understand what this thing does, therefore i must not need it, therefore if i can't be rid of it it is bad.
17:56 karolherbst: also called "fear"
17:56 karolherbst: hakzsam_: thanks
17:56 ajax: works great right up until you're like "hey why can't i browse shared folders from windows machines in my file manager" and then you're rebuilding everything with USE=+smb again
17:56 karolherbst: hihi
17:58 ajax: the components that you can _see_ as replaceable are the ones people end up forming opinions about
17:58 ajax: for some reason people don't expect to be able to swap out their ld.so implementation
17:59 karolherbst: uhh some do
17:59 ajax: you know what i mean
17:59 karolherbst: right
17:59 ajax: also when they do that they replace the whole of libc, which is a bit more aggressive.
17:59 karolherbst: right
17:59 karolherbst: but there are many reasons to do so
17:59 karolherbst: on embedded devices, you usually don't want to have glibc
18:00 karolherbst: like android doesn't use glibc as well
18:00 ajax: android's use of not-glibc is political, tbh
18:00 karolherbst: so and so
18:00 karolherbst: glibc isn't optimized for low power usage
18:00 karolherbst: or low memory
18:01 ajax: and the size of device where glibc really is "too big" continues to be more and more of an edge case.
18:01 ajax: but, sure
18:01 karolherbst: would be interesting to know if glibc can handle it, if the process is paused for days
18:01 karolherbst: and with paused I mean no CPU cycles for days
18:01 ajax: i'm not sure why it wouldn't? glibc doesn't wake up on its own.
18:02 karolherbst: funky things like caches
18:02 ajax: even when you might wish it did, like, when resolv.conf changes
18:02 karolherbst: but I don't know in particular which issues glibc might have on "high mem" embedded devices
18:03 karolherbst: and then there is the hardcore replacement dietc? I think was the name
18:03 ajax: dietlibc. defunct afaict.
18:03 karolherbst: sure
18:03 ajax: also uclibc and musl
18:04 karolherbst: it doesn't claim to fully implement posix
18:04 karolherbst: it just implements what the devs actual needs
18:04 ajax: musl i'm actually kind of a fan of
18:04 imirkin_: manio: you appear to have 2x GT216? is that right?
18:04 manio: imirkin_: GT220 + 6200LE
18:04 ajax: anyway. i should stop talking about this and get back to remembering how xdmcp works.
18:05 imirkin_: manio: oh near. i see now. you're trying to use zaphodheads + xinerama.
18:05 manio: imirkin_: no other way to move windows from screen to screen :(
18:05 imirkin_: manio: right, coz NV44.
18:06 imirkin_: manio: can you include the output of 'grep . /sys/class/drm/*-*/connected'
18:06 imirkin_: er crap
18:06 imirkin_: make that 'grep . /sys/class/drm/*-*/status'
18:06 manio: /sys/class/drm/card0-DP-1/status:disconnected
18:06 manio: /sys/class/drm/card0-HDMI-A-1/status:disconnected
18:06 manio: /sys/class/drm/card0-HDMI-A-2/status:connected
18:06 manio: /sys/class/drm/card0-HDMI-A-3/status:disconnected
18:06 manio: /sys/class/drm/card1-DVI-I-1/status:connected
18:06 manio: /sys/class/drm/card1-HDMI-A-4/status:connected
18:06 manio: /sys/class/drm/card1-VGA-1/status:disconnected
18:07 manio: /sys/class/drm/card2-DVI-D-1/status:connected
18:07 manio: /sys/class/drm/card2-TV-1/status:disconnected
18:07 manio: /sys/class/drm/card2-VGA-2/status:connected
18:07 imirkin_: this is why i said pastebin.
18:07 manio: ah, sorry :(
18:07 imirkin_: never paste stuff into irc if it's more than like 3 lines
18:07 manio: ok
18:07 imirkin_: manio: ok ... so ... i think the issue is that the zaphod-heads naming is a little off
18:08 imirkin_: manio: i think it's actually not what's in the docs
18:08 imirkin_: but rather it should be the name of the X output
18:08 imirkin_: so ... it'll be HDMI-1
18:08 imirkin_: can you try that instead?
18:08 manio: imirkin_: ofc, give me a moment
18:09 imirkin_: manio: and if not that, then try HDMI-4
18:09 manio: ok
18:10 imirkin_: yeah, i think HDMI-4 would be it actually.
18:13 imirkin_: manio: btw, instead of using the ancient NV44, why not use the built-in intel that you have?
18:14 manio: imirkin_: I am using it on second Xorg instance for kodi :D
18:14 imirkin_: manio: ah ok
18:14 imirkin_: manio: well, it has multiple outputs, so you could use some with one, some with another
18:15 manio: imirkin_: you're the master! :)
18:15 imirkin_: (again, with zaphod heads)
18:15 manio: imirkin_: it has to be HDMI-4 !! :)
18:15 imirkin_: manio: ok, let me update the zaphod doc with that caveat.
18:15 imirkin_: manio: you were following this guide? https://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/
18:16 manio: imirkin_: I spent a week trying to configure it on single X server - but intel has problems in xinerama mode to enable VAAPI
18:16 manio: it's a must for watching TV for me
18:16 imirkin_: manio: ah right - xinerama = no DRI
18:16 manio: imirkin_: exactly - only using a single intel output I've got DRI enabled
18:17 imirkin_: manio: well, with intel + GT215, you should be able to use reverse prime, which is a more modern version of all this
18:17 imirkin_: at least you get to keep DRI
18:17 manio: imirkin_: hah I was also trying this
18:17 imirkin_: manio: the NV44 is out for reverse prime though, i think
18:17 manio: but the output was only on GT220, not on the second geforce 6200LE
18:17 imirkin_: right.
18:17 imirkin_: but you could do reverse prime on intel + GT215.
18:17 imirkin_: er, GT216
18:18 manio: 220 :)
18:18 imirkin_: no
18:18 imirkin_: that's not a thing
18:18 imirkin_: (check more closely in lspci...)
18:18 manio: ah right :)
18:18 manio: that's true, it seems it was working on it
18:19 manio: not mentioning the problem that the screen was still one frame behind
18:19 manio: or if I was still using a mouse, than it was ok
18:20 manio: I had only this problem with reverse prime
18:20 manio: anyway - now It seems I am closer to working xinerama using nouveau
18:20 manio: thanks imirkin_ :)
18:20 imirkin_: cool
18:20 manio: btw: I have strange problem, maybe you can also help? :)
18:21 manio: imirkin_: on the second Xorg instance is now intel connected to a samsung TV
18:21 manio: the problem is that when I turn on this TV, then xorg with nouveau is crashing
18:22 imirkin_: manio: pastebin xorg log after this happens.
18:22 imirkin_: guessing it's some dumb autodetect thing
18:22 manio: you want a backtrace?
18:22 imirkin_: i want the full xorg log
18:22 manio: ok
18:22 imirkin_: *after* it crashes
18:27 manio: imirkin_: http://skyboo.net/pub/nouveau/Xorg.3.log.old.txt
18:30 manio: imirkin_: sorry, it was the wrong one!
18:31 manio: imirkin_: https://skyboo.net/pub/nouveau/Xorg.txt
18:31 manio: but as you can see, there is no backtrace at the end
18:32 karolherbst: :O that never happened to me before: https://gist.github.com/karolherbst/5c9063ddab2225ecaf95550d939c98ae
18:32 karolherbst: first hash is a digit longer
18:33 manio: karolherbst: it is like this when there is the same sha hash for another commit
18:33 karolherbst: yeah I know
18:33 karolherbst: but as I said: never happened before to me
18:33 manio: :)
18:33 manio: I have it one time in my programming career ;)
18:34 karolherbst: I should create a bug report for git: 7 digits aren't enough, use 8 :p
18:34 manio: :)
18:36 imirkin_: manio: does it just exit?
18:36 manio: i have dixGetPrivateAddr: Assertion 'key->initialized' failed on the console
18:37 imirkin_: huh
18:37 imirkin_: feels like it's in the guts of xserver somewhere
18:37 imirkin_: i blame ajax :)
18:37 manio: :)
18:37 manio: i created a core and a bactrace - i think it is the same:
18:37 manio: https://bugs.freedesktop.org/attachment.cgi?id=127465
18:38 manio: because this is the trace when also intel was used by this Xorg instance
18:38 imirkin_: ok, so the issue is that we get a uevent for a gpu that we don't know about
18:38 manio: but now it is influencing somehow even if it is on other instances! :)
18:39 imirkin_: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/drmmode_display.c#n1535
18:39 imirkin_: oh. or the RR stuff isn't initialized for xinerama
18:39 imirkin_: but we hit it anyways?
18:40 imirkin_: ideally someone who would know something about X would chime in here
18:40 imirkin_: (ajax... looking at you ...)
18:42 manio: imirkin_: what is funny, when I have xinerama disabled then in the same time instead of xorg crash I have 100% cpu usage :)
18:42 manio: imirkin_: but for this 100% cpu a patch from https://bugs.freedesktop.org/show_bug.cgi?id=90482 helped :)
18:43 manio: in other words: when this turn on ueven is occuring it is crashing or eating the CPU - depends on xinerama :)
18:43 manio: but I'd love to get rid of this crash
18:43 imirkin_: yeah .... this is part of the system i know nothing about
18:43 imirkin_: and don't have time to investigate atm
18:44 manio: sure
18:44 manio: imirkin_: do you think that disabling this RRGetInfo could help?
18:44 manio: I am not using randr anyway
18:44 imirkin_: sure
18:44 imirkin_: kill the listener entirely
18:44 karolherbst: hakzsam_: I think the "NEG_(3b, 0);" in my first patch is wrong
18:44 imirkin_: it's only needed for dynamic screen stuff
18:45 manio: ok, will give it a try
18:45 manio: much thanks :)
18:45 karolherbst: hakzsam_: like if src0 and src1 have the neg flag set, the neg bit shouldn't be set, but it will be with the current version
18:57 manio: imirkin_: :)
18:57 manio: imirkin_: this simple patch solves my problem: http://pastebin.com/raw/6gt6xjD7
18:57 manio: imirkin_: much thanks x2 :)
18:57 imirkin_: manio: seems reasonable.
18:58 imirkin_: obviously that destroys xrandr, but you're not using it
18:58 manio: oh yes
18:58 manio: so as a workaround it's ok for me currently
18:58 manio: so - it seems i have to reassign this ticket to nouveau, right?
18:58 manio: as it is now in xorg/general
18:59 imirkin_: not 100% sure they're the same
18:59 manio: it was triggered on the same event (turning on tv)
18:59 manio: and on another driver (intel)
19:00 imirkin_: doesn't mean it's the same bug ;)
19:00 imirkin_: although a definite possibility
19:00 manio: imirkin_: and about that bad output naming, should i also create a bug for this?
19:00 imirkin_: manio: no, it's working as intended
19:00 hakzsam_: karolherbst: you probably have to do something similar to neg1, anyway, I will have a look at the last patch, but not before tomorrow :)
19:01 imirkin_: it uses the nouveau naming for connectors
19:01 imirkin_: which in the case of HDMI-A is just "HDMI"
19:01 karolherbst: hakzsam_: it is done already, at the top of the function
19:01 karolherbst: hakzsam_: there is one bit for src0 and src1
19:01 manio: ah, so it was just my fault :)
19:01 imirkin_: # Actual connector - as reported by /sys/class/drm/card0-xx
19:01 imirkin_: unfortunately that comment is a lie
19:01 manio: yeah, i was following this
19:01 imirkin_: it's more like "the name that nouveau would have given it"
19:02 imirkin_: which is that connector name for everything except HDMI :)
19:02 hakzsam_: karolherbst: I meant like "if (code[0] & 0x1) { blabla }, should be similar to the short imm form
19:02 karolherbst: hakzsam_: also, that post_ra_dead function is wrong. I don't really know the deatils, but I was using it for other things and it broke other things. I would play it safe and reuse the isDead thing for this, because it knows and handles more cases
19:02 karolherbst: hakzsam_: ohh, nope, emit_L does it already afaik
19:03 karolherbst: I think
19:03 karolherbst: have to check
19:04 hakzsam_: yep
19:05 karolherbst: hakzsam_: uhh, I think I need to take a second look at that gk110 thing, cause setImmediate32 also sets the mod bit already
19:05 karolherbst: ...
19:05 hakzsam_: karolherbst: but post_ra_dead() works fine on nv50, what does it break on nvc0?
19:05 hakzsam_: it sets the mod yes, but your is 0
19:06 karolherbst: it works for this use case
19:06 karolherbst: hakzsam_: right, and the immediate value can be negative. anyway, have to think through that and see what is the right think
19:06 karolherbst: *thing
19:06 hakzsam_: so if it's not required for that series, you can eventually remove it and improve later?
19:06 imirkin_: manio: updated that xorg.conf snippet, hopefully it's more clear.
19:07 karolherbst: well I could add support for only gf100 for now
19:07 karolherbst: hakzsam_: it breaks if you run post_ra_dead on every instructions
19:07 hakzsam_: karolherbst: I'm talking about post_ra_dead(), if it works fine with post ra constant folding, you can remove it from that series for now, right?
19:08 karolherbst: I don't trust this one, because I know it has issues
19:09 hakzsam_: yeah, but afaik it doesn't break nv50, so I don't see any reasons why it's going to break nvc0
19:09 karolherbst: true, I could seperate the patch, but I also don't see a reason why not to merge those things together
19:09 hakzsam_: if it works fine, you should re-submit a new version without patch 3
19:09 hakzsam_: because it's a separate thing
19:09 karolherbst: okay
19:10 hakzsam_: but there is no rush anyway :)
19:10 karolherbst: true
19:10 hakzsam_: I will try to have a second look tomorrow morning
19:10 karolherbst: k, will post updated patches friday or saturday
19:10 karolherbst: depending when I get time
19:10 hakzsam_: cool
19:11 hakzsam_: this opt is really nice btw
19:11 NanoSector: Lekensteyn: I'll have a play with linux 4.7 and power management in a bit
19:11 karolherbst: hakzsam_: yeah, it is
19:12 karolherbst: it shows how much we really need an instruction scheduler
19:12 karolherbst: 2% more perf in pixmark_piano...
19:12 karolherbst: just by removing some movs
19:13 hakzsam_: yeah
19:13 hakzsam_: I guess this will also improve elemental a bit
19:13 karolherbst: yeah
19:13 hakzsam_: because I do see a ton of movs
19:13 karolherbst: mhh well
19:13 karolherbst: it helps only cpu bound things really
19:13 karolherbst: *gpu
19:13 karolherbst: and with gpu bound I mean shader bound
19:13 karolherbst: *bottlenecked
19:14 karolherbst: still vague...
19:14 karolherbst: like if you wait a lot on memory operations, this won't do much
19:14 hakzsam_: yeah sure
19:14 hakzsam_: this only removes some movs
19:15 karolherbst: by the way, with all my local stuff I am 85% close to nvidia perf with piano :)
19:15 hakzsam_: but it's always good to have
19:15 karolherbst: I have a patch which reorders instructions to improve dual issueing, this also helps a lot
19:16 karolherbst: and this one: https://github.com/karolherbst/mesa/commit/fdf53f19abb7fd7a644b9ff689a859cffc7ce0c5
19:16 karolherbst: have to check if we can do it though
19:16 karolherbst: hakzsam_: do you know something with tons of joins?
19:18 hakzsam_: nope
19:18 karolherbst: hakzsam_: you could play with this patch and elemental: https://github.com/karolherbst/mesa/commit/30eaa15e32b6141a0074c0c427b57b8afee97f71
19:18 karolherbst: and check if you also see perf improvements
19:18 karolherbst: actually you need also https://github.com/karolherbst/mesa/commit/2a2059c211d4bec10add84410ba4557b3979c3fa ;)
19:19 karolherbst: or did this one actually land?
19:19 karolherbst: ... no clue
19:19 hakzsam_: k, I will try when I get some time :)
19:19 karolherbst: awesome :)
19:26 Lekensteyn: NanoSector: ping me when you have some results:)
19:27 NanoSector: Lekensteyn, I'm downgrading my kernel now, we'll see
19:31 NanoSector: Lekensteyn, hmm, with nouveau on 4.7.6 I'm now getting ~7W results withoutk ernel parameters or anything, so it seems to work there
19:32 NanoSector: i swear it didn't work before on an earlier kernel O_o
19:34 Lekensteyn: on older kernels, very recent cards might not be supported, but you should not be experiencing that with your 750M
19:34 NanoSector: i think it was until linux 4.4 that my card wasn't properly supported
19:34 Lekensteyn: could it be a udev rule? (should also not make a difference since nouveau enables it by default, unless you add nouveau.runpm=0)
19:36 NanoSector: well either way it is broken on linux 4.8
19:37 NanoSector: i don't have any udev rules to do with pci devices
19:37 NanoSector: at least no custom ones
19:38 Lekensteyn: just to be sure, if you boot into linux 4.8 without pcie_port_pm=off and run "sudo lspci -H1 -d10de:", can you see the nvidia device or not?
19:38 Lekensteyn: -H1 does direct access which should avoid runpm from powering on the GPU
19:38 Lekensteyn: if it shows something when dmesg reports that nouveau has suspended, then something is wrong
19:39 NanoSector: aight
19:39 NanoSector: checking
19:41 NanoSector: empty output
19:41 NanoSector: Lekensteyn: ˆ
19:42 Lekensteyn: and powertop reports higher power usage?
19:42 NanoSector: 16W
19:43 NanoSector: so yes
19:51 Lekensteyn: NanoSector: just to be sure, does this show 2x D3cold and a path? grep . /sys/bus/pci/devices/0000\:00\:1c.4/firmware_node/{path,*power_state}
19:52 NanoSector:boots laptop
19:52 NanoSector: again :P
19:53 NanoSector: Lekensteyn: no
19:54 NanoSector: wait
19:54 NanoSector: no
19:55 NanoSector: it shows /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05 and /sys/bus/pci/devices/0000:00:1c.4/firmware_node/power_state:D3hot
19:58 NanoSector: Lekensteyn: ^
19:59 Lekensteyn: NanoSector: yes, got it, what is the contents of the status file under the power_resource_* directory (relative to firmware_node/)?
20:00 imirkin_: skeggsb: could you send airlied a pull req for drm-next so that the same thing doesn't happen for 4.10 as happened in 4.9?
20:00 NanoSector: Lekensteyn there's no such directory
20:02 airlied: imirkin_: I have his pull request already from last kernel
20:03 imirkin_: airlied: ah ok. have you pulled it into drm-next?
20:03 airlied: I'll probably just pull that in when I get a chance
20:03 imirkin_: ah k
20:08 Lekensteyn: NanoSector: I have this (0000:00:01.0 is the parent pcieport of my card at 0000:01:00.0) http://sprunge.us/TdXU
20:11 NanoSector: Lekensteyn: I have adr, device:32, LNXVIDEO:00, path, physical_node, power, power_state, subsystem, uevent
22:11 karolherbst: I ran shader-db 4 times now, 4 crashes.. wtf
22:12 imirkin_: consistency!
22:12 karolherbst: at least!
22:12 karolherbst: and crash number 5
22:12 karolherbst: ...
22:17 karolherbst: in the past, those crashes happened like after each shader was compiled, but now at random points, which is like super annoying
22:18 karolherbst: okay, I have no access to a 4K display to test stuff, somebody interested in some tests?
22:18 karolherbst: should tesla be able to drive a 4k display with hdmi?
22:18 karolherbst: I somehow doubt this, but who knows
22:19 imirkin_: karolherbst: not really, but some people have abused the hdmimhz kernel param to drive stuff out of spec
22:19 karolherbst: it's a nvac though
22:20 imirkin_: it really depends on the physical properties of the board in question
22:20 karolherbst: funny, why didn't I extracted my vbios...
22:20 imirkin_: i believe tesla only ever supported 165MHz over HDMI
22:20 imirkin_: for 4K you need 297MHz
22:21 karolherbst: I don't even have an hdmi port anyway
22:21 imirkin_: heheh
22:21 karolherbst: the display has a VGA port though
22:21 karolherbst: and scart!
22:21 imirkin_: SCART!
22:21 imirkin_: my favourite
22:21 karolherbst: yeah
22:21 imirkin_: been so long since i've used one
22:21 karolherbst: :D
22:21 karolherbst: I even have a dvd player with scart
22:22 karolherbst: as the only output
22:22 imirkin_: fond memories of playing on NES & co
22:22 karolherbst: anyway, my tesla system has a mini DP and mini DVI port
22:22 karolherbst: what could I expect from mini DVI => VGA?
22:23 imirkin_: should work... it's just a DVI-I port
22:23 imirkin_: at least in theory
22:25 karolherbst: mhh I currently do not now if the display even supports >= 30Hz
22:25 imirkin_: well, for 4K @ 30Hz you need 297MHz
22:25 karolherbst: I see
22:38 karolherbst: hakzsam_: ue4_demos: total instructions in shared programs : 255756 -> 253811 (-0.76%)
22:38 hakzsam_: which opt?
22:39 karolherbst: post ra const folding
22:39 imirkin_: do you mean const folding?
22:39 imirkin_: or do you mean load propagation?
22:39 karolherbst: the mad thing
22:39 imirkin_: load propagation
22:39 imirkin_: const folding is like 1 + 1 -> 2
22:39 karolherbst: uhh right
22:39 karolherbst: I just kept the name it had before
22:41 hakzsam_: cool yeah
22:41 hakzsam_: elemental uses a TON of mad
22:41 imirkin_: it's INSANE! :)
22:41 hakzsam_: :)
22:41 karolherbst: well
22:42 karolherbst: only elemental: total instructions in shared programs : 117613 -> 116892 (-0.61%)
22:42 Lekensteyn: small debugging session later, I think we need some linux-acpi experts now :) https://bugs.freedesktop.org/show_bug.cgi?id=98398#c11
22:43 imirkin_: Lekensteyn: or you need to become an acpi expert :)
22:44 Lekensteyn: I'll try to poke experts in the community :)
22:44 karolherbst: hakzsam_: realistic: total instructions in shared programs : 15908 -> 15698 (-1.32%)
22:45 hakzsam_: cool
22:45 karolherbst: yep, elemental is indeed the one benefiting the least of the ue4 demos
22:45 karolherbst: most are above 1%
22:45 hakzsam_: but you should only use the ue4_demos dir because they use similar shaders
22:46 hakzsam_: some of them are in effects_cave but elemental also uses them
22:46 karolherbst: ahh I see
22:46 hakzsam_: and fdupes did random removals :)
22:46 karolherbst: right
22:46 karolherbst: anyway, progress!
22:46 hakzsam_: yu
22:47 karolherbst: will check f1
22:47 karolherbst: sad... just 0.18
22:48 karolherbst: would be nice to get some kind of overview which application benefits most from stuff
22:49 hakzsam_: I have a WIP patch for that
22:49 karolherbst: awesome :O
22:50 karolherbst: anywaym bed time!
22:50 hakzsam_: I should improve it at some point
22:50 hakzsam_: see ya