05:50storkus: Hi, anyone on tonight?
07:03storkus: Anyone there?
13:50mupuf: karolherbst: Hey, since we now know most of the different entries for the power table, why not parse them properly?
13:50mupuf: both in nvbios and nouveau?
13:50mupuf: some can already be used
13:50karolherbst: because it is super implicit
13:50karolherbst: they are not picked up by references usually
13:51karolherbst: and depending on the entry byte, the entry means something differently
13:51karolherbst: I am still trying to make some sense out of it
13:51karolherbst: but I think I am somehow close to at least detect what is the power cap
13:54karolherbst: mupuf: I think I am able to parse all 0x02, 0x42, 0x82 and 0xc2 entries for now
13:55karolherbst: no idea what the difference is fo the 0x40 and 0x80 bit
13:56karolherbst: mupuf: or what did you mean?
13:56mupuf: no, you got iit
13:56mupuf: But ... I have an idea
13:56mupuf: we would need two more files
13:57mupuf: actually, just one
13:57mupuf: power1_mode: Select the entry (0 == auto, 1 == full_power, 2 == battery mode, 3 == etc...)
13:58mupuf: and when you change the mode, you get the associated power entry
13:58mupuf: but we should not allow the user to shoot himself in the foot too much
13:58mupuf: oh, maybe we want to support a custom mode too :D
13:58karolherbst: there is no such mapping
13:59karolherbst: this is done through the vpstates
13:59mupuf: right, it still holds true though
13:59karolherbst: no idea
13:59karolherbst: found no clue regarding this
14:00karolherbst: the entries aren't referenced
14:00mupuf:is confused here
14:00karolherbst: this table is confusing
14:00mupuf: what about the logs we got from nvidia-smi?
14:00karolherbst: that's the vpstate stuff
14:01karolherbst: no idea what those power values mean
14:01karolherbst: afaik, they don't do anything
14:02karolherbst: there are always set to 0
14:02karolherbst: except for 2 kepler vbios
14:03mupuf: ah, right
14:04mupuf: well, then we need two modes for power then
14:04karolherbst: we already have that infrastructure
14:04mupuf: this can wait though, for when we start enforcing it
14:04karolherbst: we can set the pstate for battery and non battery mode already
14:04karolherbst: we would just to adjust it a little
14:05karolherbst: anywaym I think we would have to rework a lot anyway after we figured out more
14:07karolherbst: but come to think of it, maybe some power budget entries are indeed enabled if you are on battery mode
14:07karolherbst: at least there is some kind of overwriting going on
14:07karolherbst: like you can have multiple 0x02 entries
14:07karolherbst: but the lowest gets picked
14:11mupuf: karolherbst: I would be surprised if this was only for the maximum clock
14:11karolherbst: it isn't clock related at all
14:12mupuf: I meant vpstate
14:12karolherbst: I see
14:12karolherbst: it is though afaik
14:12karolherbst: nvidia can always clock lower than the vpstate
14:12mupuf: well, I would have expected that it would try to enforce a power budget
14:12karolherbst: and does
14:12mupuf: but I guess the enforcing is not super good
14:13karolherbst: maybe those power values in the table indeed does it
14:13karolherbst: but I wasn't interested enough yet
14:13mupuf: so it prefers setting clocks
14:13karolherbst: those clocks are max clocks
14:13karolherbst: at least nvidia interprets them as such
14:13karolherbst: if I unplug power, nvidia drops to a pstate and 405 mhz
14:13karolherbst: even if something is running at full speed
14:14karolherbst: *pstate a
14:15karolherbst: and currently, I wouldn't bother to check that for just two gpus if there is no benefit anyway
14:23karolherbst: anyway, that power budget table starts to make sense every day I look into it
14:23karolherbst: by the end of the year I might even get a pretty solid understanding of it
15:04pmoreau: karolherbst, mupuf: If you need any testing, more numbers, feel free to ask :-)
15:07karolherbst: pmoreau: if you got time, you could try to figure out when those vpstates are activated on your nve7: https://gist.github.com/karolherbst/afc4f7b365bbc709e2316a749cecff3b
15:07karolherbst: the d2/d3/d4/d5 ones
15:08pmoreau: How do I get that info?
15:08karolherbst: trying stuff out, no idea what those dx things might mean
15:08karolherbst: maybe it is acpi related?
15:09karolherbst: but there is no d5
15:09karolherbst: ohh wait
15:10karolherbst: windows ce 5.0
15:10pmoreau: But do I get those dX in the first place?
15:11karolherbst: mhh I am thinking
15:11karolherbst: can the OS request a d state of the pci device without involving the driver?
15:12pmoreau: No idea…
15:12karolherbst: okay something more important
15:12karolherbst: nvidia-smi cap entry: 5
15:13karolherbst: 5: min = 150000 mW, avg = 250000 mW, peak = 275000 mW (unkn12 = 5000)
15:13karolherbst: nvidia-smi should print 250W and 275W with the -d ALL option
15:13karolherbst: or only -d
15:13karolherbst: always forget how to get the detailed information
15:13karolherbst: 250W being max and 275W being critical
15:15pmoreau: I’ll switch to the blob sometime later today then
15:16karolherbst: thanks :)
15:16karolherbst: had no chance to verify it, cause the 0x30 version table is maxwell2 only afaik
15:16karolherbst: and the byte moved in the header
16:06aethe: anyone know if NV136/gtx1060 is supported yet?
16:07imirkin: i don't believe modesetting has been hooked up for that
16:08imirkin: and obviously no accel support because nvidia does not provide the signed firmware required to operate these gpu's
16:08aethe: so when i try to boot fedora live cd i get monitor out of range/frequency
16:08imirkin: sounds like you need to ask in a fedora-specific support venue
16:08aethe: do you know of any possible work arounds?
16:09aethe: it happens with every distro
16:09imirkin: unlikely. the gentoo installer doesn't even have a graphical mode.
16:09imirkin: [in fact, there is no installer]
16:09aethe: hmmk. does gentoo have a live cd?
16:11aethe: nvm found irt
16:11imirkin: chances are that it won't do you much good
16:12imirkin: anyways, i can say with some certainty that your problem is not nouveau-related -- the 0x136 chip id isn't recognized. if you're having trouble operating your distro, ask in a distro-specific support channel.
16:13imirkin: aethe: you can try booting with nouveau.modeset=0 to super-duper-turn it off
16:14aethe: i have tried that and it didnt work for me
16:14imirkin: skeggsb: should you be setting an error code here? https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/device/base.c#L2680
16:14aethe: maybe i didnt do it correctly though. idk
16:15imirkin: skeggsb: it'll end up with -ENOMEM which isn't so bad, but perhaps it should be -EEXIST?
16:16bernie: I'm trying to debug a blank screen with nouveau in 4.8.7... are there any cli tools to set modes for the console?
16:16aethe: so to be clear, to boot with custom commands, i press tab and it shows some command text stuff. at the end is something like "quite" or "quiet-boot". do i add that command after "quiet"?
16:17imirkin: bernie: console is controlled by fbdev
16:17imirkin: bernie: well, fbcon to be specific
16:17imirkin: aethe: sounds like you're looking for distro support. ask in a distro-specific support chan.
16:18bernie: imirkin: is there a tool to set modes, or do i have to cat stuff somewhere in a /sys file?
16:19imirkin: bernie: there's actually no way that i know of to set console modes. that said, you can e.g. use modetest to set a KMS mode. this is in the libdrm package (not shipped in binary form afaik)
16:19imirkin: bernie: perhaps you'd like to share more details about your issue?
16:19imirkin: [i'm answering the questions you're asking, but i'm somewhat sure they're not the questions you want to be asking...]
16:20bernie: imirkin: so fbset reports 3840x2160, which seems correct for my screen
16:20bernie: imirkin: and the sysfs file for the HDMI-A-1 output says "connected"
16:21bernie: still, the screen detects no signal
16:21imirkin: pastebin dmesg
16:21bernie: imirkin: this is a GTX 970 (GM204)
16:22imirkin: is this a GTX 970 with 4GB of VRAM?
16:23imirkin: if so, try moving the firmware out of the way (/lib/firmware/nvidia, and rebuild your initrd of however you cause the firmware to exist in the vfs where the module is loaded.)
16:24bernie: imirkin: https://paste.fedoraproject.org/490666/02638671/
16:25imirkin: yep. it's the thing i thought
16:25imirkin: bernie: you may be interested in https://bugs.freedesktop.org/show_bug.cgi?id=94990
16:26imirkin: there are also some hackpatches in there to help things limp along
16:28bernie: imirkin: thank you a lot, i'm reading through the bug log
16:31imirkin: bernie: this is probably the most promising of the hackpatches: https://bugs.freedesktop.org/attachment.cgi?id=127508
16:34orbea: what is left for exposing ogl 4.5 in nouveau?
16:40imirkin: orbea: nothing... it's been requested that we don't as it may present headaches for the distributors of nouveau.
16:42imirkin: you can set some override flags locally with little ill effect
16:42imirkin: you can also patch nouveau to report 450 instead of 430 in nvc0_screen.c
16:43orbea: ah, that sounds easy enough. wasn't a big concern, was just curious :)
16:44imirkin: at last check we don't do phenomenally worse at CTS than the intel/radeon drivers - https://people.freedesktop.org/~airlied/piglit/cts-gpus/ - nouveau is the 3rd col
16:45orbea: nice, that looks pretty close
16:45imirkin: (about 0.6-0.7% worse)
16:47karolherbst: imirkin: anybody working on fixing it?
16:47imirkin: karolherbst: fixing what?
16:48karolherbst: the errors from the test
16:48imirkin: afaik i've fixed all the test traces that airlied has fed me
16:48imirkin: it's a little tricky to try to fix the bug from just the test name =/
16:48karolherbst: ohh true, it is still not accesable yet
16:48imirkin: although i know what's going on with those stupid MS tests
16:48imirkin: dEQP has the same complaints
16:49imirkin: iirc i just disagreed on what MS with samples == 1 meant
16:49imirkin: which, tbh, is a bit of a corner-case :)
16:51karolherbst: mhh true
16:52imirkin: with access to the tests, i'm sure i could get it to the 99% mark (up from 97.5% today)
16:53imirkin: the last percent will likely be murder though
16:53karolherbst: most likely
19:04karolherbst: mupuf: you were actually right about the battery thing
19:04mupuf: hehe, cool to know I helped you
19:04karolherbst: even without knowing :p
19:04karolherbst: it was funny
19:04karolherbst: with the stock vbios, nvidia drops to pstate a and 405MHz
19:05karolherbst: but with my messed up power budget, it droped to 600MHz and pstate f
19:09karolherbst: mhh okay
19:09karolherbst: this will be fun
19:10karolherbst: if I am on battery it indeed drops to the battery vpstate
19:10karolherbst: I think there might be an additional power related thing
19:15karolherbst: that's interesting
19:15karolherbst: I managed that nvidia uses higher clocks when on battery
21:16NanoSector: Lekensteyn: I won't be able to do more testing for you sorry as I've been forced to move to Windows for some crap program school requires
21:16NanoSector: and my laptop doesn't have enough space for both windows and linux
21:27karolherbst: NanoSector: virtual machine?
21:27NanoSector: no space and wine didn't work :(
21:27karolherbst: tell your school they are crap for enforcing software
21:27NanoSector: i did
21:27karolherbst: which software by the way?
21:27NanoSector: Coach for interfacing with special apparatus
21:28NanoSector: it works to a degree in Wine
21:29NanoSector: but not the actual part of working with hardware and reading sensors
21:29NanoSector: oh well i guess there are worse things in the world than using Windows
21:35karolherbst: NanoSector: can't be :p
21:35NanoSector: it's kind of fun to poke around it now after not using it for a year or so
21:35NanoSector: see what's changed
22:50Lekensteyn: NanoSector: virtual machine should work unless you have 32GB space or something
22:50Lekensteyn: NanoSector: I've survived for years using a 80GB Intel SSD :)
22:54imirkin: that's the same one i have :)
22:56karolherbst: mupuf: mind getting a mb with vt-d , so that we could also RE the windows driver at some point? :D