01:13 cellsheet: Hello, I'm trying to use KMS for nouveau on pascal architecture as I saw there was initial support now if I'm not mistaken
01:13 cellsheet: but I keep on getting an unknown chipset message
01:14 cellsheet: I'm okay with no hw acceleration for now
03:37 gnurou: imirkin_: that's weird, I had the feeling that we had solved this problem before... let me check
04:02 gnurou: imirkin_: that bit exists since Fermi, but if some cards are showing issues with it, maybe we can start using it for later cards only?
04:03 gnurou: imirkin_: I believe Kepler/Maxwell should be safe
09:29 Lekensteyn: karolherbst: that byte you were talking about, does that have anything to do with reporting itself as unsupported to "nvml"?
09:40 karolherbst: nvml?
10:12 Lekensteyn: karolherbst: apparently the interface (library) that nvidia-smi uses for querying things like power management mode
10:27 karolherbst: ohh yeah
10:27 karolherbst: right
10:27 karolherbst: some features should be available though
10:30 Lekensteyn: can you see if it is limited by the hardware (or whether it is just an artificial software limitation?)
10:30 karolherbst: caused by the vbios
10:32 Lekensteyn: does the vbios not expose the details at all, or is it giving a hint to the software that the information is not supported?
10:56 karolherbst: Lekensteyn: more like the engineer creating that vbios was lazy
10:57 Lekensteyn: karolherbst: but does that mean that the vbios is never exposing the information (resulting in N/A in nvidia-smi) or something else?
10:58 Lekensteyn: if it is never exposeed, then hacking the libnvidia-ml.so library is not worth it, otherwise it could be tried
11:01 karolherbst: right, it isn't in the vbios
11:02 karolherbst: maxwell cards are full supported by nvidia-smi
11:02 karolherbst: all
11:02 karolherbst: but if the gpu lacks something, nvidia-smi can't do anything about it
11:07 Lekensteyn: karolherbst: have you seen https://github.com/CFSworks/nvml_fix?
11:07 Lekensteyn: that is why I was wondering whether it is really just a flag to report "unsupported" or whether the vbios is not reporting stuff at all
11:22 karolherbst: Lekensteyn: well you have to trust the vbios
11:23 karolherbst: that fix :D
11:23 karolherbst: worth trying
11:23 karolherbst: would make some things easier
11:29 Lekensteyn: karolherbst: I have not tried that fix since it is driver version dependent, atm trying to figure out what check has to be bypassed
14:30 imirkin_: gnurou: well, we have 1 GK107 on record where a quick glance at the vbios, it didn't update that register either
14:30 imirkin_: gnurou: however it seems to mostly be GF104's for some weird reason
14:30 imirkin_: gnurou: however, unrelated to all this, re-running the vbios shouldn't kill it, so it'd be ideal to figure out wtf is going on :)
14:31 imirkin_: gnurou: but short-term, making GF104 or all GF10x's not use the "new" method seems like a reasonable way to handle it
14:31 imirkin_: gnurou: it seems like at least that dude's vbios tries to write stuff to GPC's that aren't there - do you know if the vbios interpreter is supposed to filter those out?
16:15 Lekensteyn: karolherbst: in case it could be of use, here is the nvidia-smi -q --debug=nv-debug.bin output http://ix.io/1Brt and decrypted debug log http://ix.io/1Brs
16:16 Lekensteyn: this model "0x56" is reported as not supported, whatever the number means
16:17 karolherbst: :O
16:18 karolherbst: the magic is within the kernel though, so yeah
16:44 karolherbst: mupuf: seems like there are even max_sli and max_batt vpstates according to those logs :O
16:45 mupuf: Lekensteyn: how do you "decrypt" the debug log?
16:46 karolherbst: we only do full disclosures here :p
16:47 mupuf: nvml_fix --> fun
16:48 karolherbst: yeah, for 325 drivers that is
16:48 mupuf: it may still be applicable
16:48 karolherbst: maybe
17:15 Lekensteyn: mupuf: there are various approaches, easiest to see how it works is: ltrace -o debuglog.txt -e vsnprintf nvidia-smi --debug=/dev/null -q >output.txt
18:22 Lekensteyn: mupuf: and here is a tool that can be pre-loaded in nvidia-smi (or other NVML users) and act as a null cipher: https://lekensteyn.nl/files/nvml-debugdump.c
18:24 mupuf: Lekensteyn: very good, thanks!
18:24 mupuf: amazing that they went for the security through obscurity here
18:26 mupuf:would have just printed in vsnprintf, but I guess your solution because you do not dump the encrypted values
18:26 Lekensteyn: when I looked at the manpage, I frowned upon seeing "encrypted logs"
18:27 Lekensteyn: at first I thought they would apply hybrid encryption using RSA, but xoring two ciphertexts showed a lot of zeroes
18:27 mupuf: yeah, it is ridiculous that they do not encrypt them with a public jey
18:28 mupuf: lol, really?
18:28 Lekensteyn: breaking the cipher can probably be done as an exercise in an crypto class
18:28 mupuf: oh, yeah, it oculd
18:28 mupuf: but as I was saying, it is ridiculous that they are not using a public key encryption in the kernel
18:28 mupuf: and then pass it to the userspace
18:28 Lekensteyn: the logs are all in userspace, note that strace does not work, you need ltrace :)
18:28 mupuf: not that a similar attack could not be done in the kernel anyway
18:29 mupuf: :p
18:31 Lekensteyn: mupuf: do you have a maxwell card where nvidia-smi produces data more useful than N/A?
18:31 mupuf: yes, I can check out when I come back home
18:52 Yoshimo: pardon, why would you encrypt logs?
18:52 mupuf: Yoshimo: it is ... pretty low-level logs
18:52 mupuf: I guess this is why
19:06 Yoshimo: what could probably leak ?
19:08 mupuf: there are lines and files of the kernel driver
19:08 mupuf: and decoded names of functions
19:25 Yoshimo: so if you find a way to decrypt this you can legally use this to improve nouveau?
19:35 Lekensteyn: karolherbst: I have posted a tool that undoes the encryption at https://lekensteyn.nl/files/nvml-debugdump.c
19:38 Lekensteyn: Yoshimo: normally the log file is encrypted, but the encryption can be bypassed by looking at the data given to the C library. Should be legal I think
19:38 Lekensteyn: ianal, but I think that attacking a cipher using blackbox cryptanalysis is allowed
20:43 nmschulte: Hi all! I ahve
20:44 nmschulte: I have a GeForce GTK 730M paired w/ an Intel Haswell CPU; I'm currently using nouveau w/ Xorg on Debian Sid, and I'm experiencing a funky display flicker issue.
20:45 nmschulte: Periodically, the display will "flicker", it will get brighter and dimmer, and I can see what looks like "dithering" in the picture while it does this.
20:45 nmschulte: As well, when this happens the touchpad becomes "unresponsive" and "finnicky": almost unusable it's so annoying.
20:45 imirkin_: nmschulte: pastebin xorg log
20:48 nmschulte: imirkin_: There are ACPI warnings about the GPU, and nouveau outputs red lines in dmesg. https://paste.debian.net/891516/
20:49 imirkin_: nmschulte: ok, so it's set up in the way i anticipated
20:49 imirkin_: nmschulte: i.e. everything's feeding off your intel board
20:49 imirkin_: nmschulte: you appear to be using the 'modesetting' driver too
20:50 nmschulte: imirkin_: Yeah I haven't looked at how this machine works with hybrid graphics.
20:50 imirkin_: nmschulte: since you're not driving displays off the nouveau chip (doesn't appear to have any outputs in any case)
20:50 nmschulte: It's a temporary replacement for my regular hardware, so I'm not too worried about that at the moment.
20:50 imirkin_: nmschulte: all your problems are intel-related, nothing to do with nouveau
20:51 nmschulte: imirkin_: do you know from looking at the log and your exp. how this hardware is configured for hybrid? is it render offload (no heads on discrete), or is it the other (heads on discrete, and possibly integrated?)
20:51 nmschulte: imirkin_: re: modesetting; are there known complications, or were you just calling it out?
20:53 imirkin_: nmschulte: looks like no screens attached to nvidia, so all displays are hanging off the intel board
20:53 imirkin_: mmmm.... well, modesetting runs on top of GL
20:53 nmschulte: Cool; so it's render offload, just like my other hardware.
20:53 imirkin_: which i personally distrust.
20:54 nmschulte: Can you help me understand my tradeoffs? I always thought modesetting/kms were bueno
20:54 imirkin_: well... bueno for who
20:55 imirkin_: for the guy who no longer has to write a ddx? yes. mouy bueno.
20:55 nmschulte: I thought Gallium was supposed to help w/ that picture?
20:55 imirkin_: but if you want reliability, you want (a) simpler code, and (b) code that doesn't have exit() as part of its error-handling strategy.
20:56 nmschulte: haha, yeah, exit() is no bueno
20:57 nmschulte: So, this is w/o an Xorg.conf; would I need to e.g. blacklist drivers to get a better config?
20:57 imirkin_: so as an end-user, i'm more in favor of simpler, hw-specific DDX's
20:57 nmschulte: Is there potential removing modesetting would help w/ my display issue?
20:57 imirkin_: not sure. you're probably running a distro that has made it harder to use non-modesetting? dunno
20:57 nmschulte: Debian.
20:57 imirkin_: sure, there's potential. but not exceedingly likely.
20:57 imirkin_: yeah, i don't keep up with what various distros do.
20:57 nmschulte: I'll ask the #intel-gfx guys. I appreciate your help!
20:58 nmschulte: DRI_PRIME=1 glxgears works great w/ render offload. :)
20:58 imirkin_: since they're the guys that no longer have to write a DDX, they'll definitely recommend using modesetting :)
20:58 nmschulte: I never used my discrete on my other hardware because I had to remember to invoke it/turn it on -- ideas for a transparent, auto-scale-up/down solution would be great.
20:58 imirkin_: patches welcome
20:59 nmschulte: Am I correct in thinking that Gallium hides away the DDX issue?
20:59 imirkin_: nope
20:59 imirkin_: for 2 reasons
20:59 nmschulte: Maybe I'm thinking of something from Wayland then.
20:59 imirkin_: (a) intel isn't a gallium driver
20:59 imirkin_: (b) the gallium driver is going to be very complicated
21:02 karolherbst: Lekensteyn: care to put your stuff inside a git repository?
21:02 karolherbst: Lekensteyn: so that we can reliable link to it
21:06 karolherbst: Lekensteyn: that c file is awesome :)
21:06 karolherbst: it just doesn
21:07 karolherbst: 't do anything useful on my kepler though
21:14 karolherbst: mupuf: remember that I said in the vpstate table that those two values might be related to power consumption? guess what
21:14 karolherbst: "reqPower10mW 0, reqSlowdownPower10mW 0" in the trace :D
21:15 karolherbst: sadly it doesn't work for me
21:15 karolherbst: should be easy to test on the titan though
21:16 karolherbst: I will RE that vpstate table so hard with this
21:16 karolherbst: :O
21:16 karolherbst: they even print it in the same order
21:16 karolherbst: are they insane?
21:16 karolherbst: 10 17 05 02 01 50 02 02 02 02 ff 00 02 00 ff 02 00 01 ff ff 00 03 04
21:17 karolherbst: in the trace: 2, 2, 2, 2, 0, 2, 0, 2, 0, 1, 3, 4
21:18 karolherbst: bytes: 0x6, 0x7, 0x8, 0x9, 0xb, 0xc, 0xd, 0xf, 0x10, 0x11, 0x15 and 0x16
21:19 karolherbst: D2, D3, D4, D5, VRHOT, MAX_BATT, MAX_SLI, BOOST, TURBO_BOOST, RATED_TDP, unk, unk
21:19 karolherbst: OVER_CURRENT is also there
21:19 mupuf: oh oh oh
21:20 mupuf: very very nice!
21:20 karolherbst: :D
21:20 karolherbst: we currently parse BOOST, TURBO_BOOST and RATED_TDP
21:20 mupuf: these are good names :)
21:21 karolherbst: we call it base, boost and tdp
21:21 karolherbst: close enough I guess
21:21 karolherbst: that MAX_BATT is a nice one
21:21 mupuf: I wonder what D2-5 are
21:21 karolherbst: yeah
21:21 mupuf: MAX_SLI --> this one is also fun
21:21 karolherbst: yeah
21:21 karolherbst: same as turbo boost on Lekensteyn gpu though
21:22 karolherbst: I will hack it into nvbios and see what that gives us going through all the vbios
21:22 mupuf: so, it is basically selecting different entries for different cases?
21:22 karolherbst: yes
21:22 karolherbst: as the cap
21:22 mupuf: well, that makes more sense
21:23 mupuf: thanks, nvidia, for documenting your vbios :D
21:23 karolherbst: :D
21:23 mupuf: VRHOT --> I wonder what this is
21:23 karolherbst: now if you look at what nvidia gave to us...
21:23 mupuf: oh, of course!
21:23 karolherbst: very hot
21:23 mupuf: nope
21:23 karolherbst: :p
21:23 mupuf: voltage regulator hot
21:24 karolherbst: aka very hot :p
21:24 mupuf: I guess this only works when we have an i2c connection with the VR
21:24 mupuf: or, at least, a GPIO
21:25 karolherbst: I think there are even more
21:25 karolherbst: cause they most likely skip the 0xff ones
21:25 mupuf: karolherbst: time to fake them? :p
21:25 karolherbst: not today
21:25 karolherbst: tomorrow
21:25 mupuf: sure sure
21:25 karolherbst: will leave work early then
21:25 karolherbst: you know, important things are more important :p
21:25 dcomp: D2-D5 sound like ACPI Power Management States
21:26 mupuf:is still at work. Had planned to come back early to work on the fan ... and here I am, debugging my auto bisect feature :s
21:26 mupuf: dcomp: hmm, interesting
21:30 karolherbst: much better: https://gist.github.com/karolherbst/74ed9c45d6bc34711a05d05bec78f4c5
21:33 karolherbst: mupuf: it works as expected on fermi vbios as well :D \o/
21:33 karolherbst: just have to verify it
21:33 karolherbst: maybe meanings may differ between chipsets
21:34 RSpliet: generally they shouldn't... unless the table version changes too
21:34 karolherbst: yeah
21:34 karolherbst: on the fermi it doesn't make sense
21:34 karolherbst: max batt entry is like 1600MHz
21:34 karolherbst: and max sli is like 1320MHz
21:34 karolherbst: well
21:34 karolherbst: maybe they want to do it this way
21:34 karolherbst: who knows
21:35 karolherbst: unk15 and unk16 are optional
21:35 mupuf: ah! It was not for the power budget
21:37 karolherbst: huh
21:37 karolherbst: the table header can be even shorter...
21:40 karolherbst: nice
21:40 karolherbst: now that pstate field makes also sense
21:40 karolherbst: some vbios have a lower pstate for the max_batt
21:41 karolherbst: most likely to drop the memory clock a little
21:41 karolherbst: or voltage
21:41 karolherbst: but then again
21:41 karolherbst: why is it set for desktop gpus
21:42 karolherbst: mupuf: it makes so much sense
21:42 karolherbst: now I got even index 30 for some, but then the table also has like 32 entries
21:46 mupuf: it does make way more sense, indeed
21:46 mupuf: now, let's hope there is the same for the power budget
21:47 karolherbst: :( it is somewhat boring though
21:50 nmschulte: imirkin_: I can't startx now, except as root, and I didn't really change the configuration at all.
21:51 nmschulte: I get an "xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted.)" in the Xorg log, but no errors from Xorg, it closes gracefully.
21:52 imirkin_: nmschulte: and what makes you suspect nouveau is the issue?
21:53 nmschulte: It seems an issue from interfacing w/ the NVIDIA card, I suppose. That of course doesn't explain why X won't start; I guess I was hopeful that'd cue some insight from you, but I suppose not.
21:53 imirkin_: X normally only starts as root in the first place
21:54 nmschulte: I ought to be able to e.g. blacklist i915, nouveau, and start X w/ "vesa", right?
21:54 imirkin_: yep
21:54 imirkin_: or efifb if you're booting with that
21:54 nmschulte: I wish I knew. :(
21:55 nmschulte: Debian configures xserver/Xorg to non run as root; I think KMS is part of this.
21:55 imirkin_: sounds like you need some basic distro support
21:55 imirkin_: i have no idea how your distro works
21:55 imirkin_: and am not particularly inclined to learn
21:55 nmschulte: Sure sure, I'm not asking. I believe a large swath of distros use the same paradigm, though -- especially like-derived (e.g. Debian-...).
21:56 imirkin_: probably
21:56 Lekensteyn: karolherbst: I have put the script in a gist: https://gist.github.com/Lekensteyn/c8d41c02d118aa40bc100020efde3696 (is there an existing repo with assorted tools where this could be added to?)
21:56 karolherbst: we could add it to envytools I suppose
21:56 nmschulte: imirkin_: I'm curious, what do you run on your hardware, and how do you handle hardware upgrades?
21:56 imirkin_: nmschulte: i run linux
21:56 imirkin_: nmschulte: i remove one piece of hardware, and plug another one in.
21:57 imirkin_: [crazy, right?]
21:57 nmschulte: no, but setup had to be a hassle
21:57 imirkin_: a bit, sure
21:57 nmschulte: and when hardware is incompatible, I wonder how you manage.
21:57 imirkin_: "incompatible"?
21:57 nmschulte: shows how naive I am.
21:57 nmschulte: I used to run AMD/K9
21:57 imirkin_: unless it's an emergency situation, i know that the new hw is coming, and i can adjust my system to work
21:58 karolherbst: ohh wait, htere is something interesting in the trace... let me check
21:58 imirkin_: if i'm installing on a totally new system, i copy a couple of helpful items from my old machine
21:58 nmschulte: Anyway, that's admirable; did you take the Systemd plunge?
21:58 imirkin_: absolutely not
21:59 imirkin_: it's the solution two problems i don't have: "sysv init is too simple, let's make it too complicated" and "logs are too easy to access, stop that"
21:59 karolherbst: Lekensteyn: I am curious if "GPU-6387f991-2cb8-161f-87e6-46929aa85907" is somewhere in the mmio space
22:00 karolherbst: Lekensteyn: nvapeek 0x0 0x1000
22:00 Lekensteyn: karolherbst: do I need blob for nvapeek? (would have to reboot again for that)
22:00 karolherbst: nope
22:00 Lekensteyn: k, lemme try
22:03 karolherbst: mhh
22:03 karolherbst: maybe it is in the vbios
22:05 Lekensteyn: karolherbst: output is http://sprunge.us/ZhHT
22:05 Lekensteyn: have a lot of funny dmesg lines too
22:05 karolherbst: it isn't in there, I already checked on mine
22:05 karolherbst: I am sure it has to be in the vbios somewhere
22:05 karolherbst: maybe this thing is even calculated
22:05 karolherbst: who knows
22:06 Lekensteyn: dmesg is at http://sprunge.us/CHFX in case it is relevant
22:06 karolherbst: nope
22:07 Lekensteyn: I think I saw that GPU-xxx line somewhere from /proc/driver/nvidia/.. (forgot exact path), but I guess you already know this
22:07 karolherbst: why should I? :D
22:08 karolherbst: gpus/*/information
22:11 karolherbst: will go to bed though
22:50 nmschulte: any ideas what these nouveau related messages in the kernel log signify? http://oi63.tinypic.com/28vswm9.jpg
22:51 imirkin_: nmschulte: i wouldn't worry about it
22:52 imirkin_: nmschulte: btw, reclocking should basically be working on that gpu, if you want to futz with it, look at /sys/kernel/debug/dri/1/pstate
22:52 imirkin_: nmschulte: but only while the gpu is powered on, so run glxgears on it or something dumb
22:54 nmschulte: I'll give it a whirl w/ some Wine-gaming later. It should "just work" though, right?
22:56 imirkin_: nmschulte: yeah, but you'll be at the lowest perf level by default
22:57 imirkin_: nmschulte: if you're playing DX9 games, look into gallium-nine
22:59 nmschulte: I'm not sure how it comes out in the end; I think I can configure to use OGL or D3D9?
22:59 imirkin_: sure, but the d3d9 is either emulated by wine, or implemented via a state tracker on top of gallium
23:00 nmschulte: and G9 is the latter?
23:00 imirkin_: G9?
23:00 imirkin_: oh, gallium-nine. yes.
23:00 nmschulte: "gallium Direct3d"
23:00 nmschulte: Cool; thanks for the info! I stopped building wine since the packaged version has the feature set I need, but I may look at this when I get my new hardware.
23:01 imirkin_: i'm sure you can find builds that work nicely for your distro
23:01 nmschulte: hehe...
23:01 nmschulte: I'd prefer to build from src than install rando-blob.
23:01 imirkin_: sure, whatever works for you
23:02 nmschulte: But, this is just a set of DSOs? (.so, .dll)? It's not in upstream though, right?
23:02 imirkin_: (you'll need to apply some patches, the wine guys refuse to merge those patches in)
23:02 nmschulte: :)
23:41 Lekensteyn: since a recent upgrade (I think mesa 13.0.0rc2), Xorg keeps sending DRM_NOUVEAU_GEM_PUSHBUF to /dev/dri/card1 (on new windows in KDE Plasma) which runtime resumes the GPU
23:41 Lekensteyn: any known issues regarding that or what this means?
23:42 imirkin_: Lekensteyn: something's submitting batches
23:42 Lekensteyn: (actually, it happens on maximizing windows, dragging windows around the corner; this is an Optimus setup but no output source provider attached)
23:42 imirkin_: Lekensteyn: do you have my updated nouveau ddx?
23:43 imirkin_: Lekensteyn: if not, perhaps modesetting does it
23:43 Lekensteyn: imirkin_: forgot to mention that I'm using modesetting driver
23:43 imirkin_: (via GL)
23:43 Lekensteyn: should I use nouveau DDX instead? intel DDX was in a sorry state last time I tried it, so I am using modesetting for both intel and nvidia
23:45 imirkin_: Lekensteyn: i'd definitely recommend that. and the intel ddx (also from git).
23:47 Lekensteyn: ok, I will try. Wasn't there an idea to make modesetting responsible for Maxwell (and newer cards)?
23:47 imirkin_: yep
23:47 imirkin_: i never liked that idea :)
23:48 Lekensteyn: I'll try the intel+nouveau instead of modesetting+modesetting combination then, hopefully the artificats that I had before are gone then
23:48 imirkin_: preferably from git on both of them
23:49 Lekensteyn: modesetting is also not without issues, currently my Xorg.0.log keeps growing because of "modeset(0): flip queue failed: Invalid argument"
23:50 Lekensteyn: there was also an issue where pictures on an external screen show up with 1fps, perhaps that is already solved by Hans, have not yet had a chance to try/check his patches