00:45mangix: just tried reclocking on this laptop
00:45mangix: dota playable at medium settings
00:45mangix: not bad
00:46mangix: btw under pstates what is AC?
00:46mangix: oh that must be the current clock
00:46imirkin: it'll say DC if you're not plugged in, but yeah, current state
00:49imirkin: afaik there's something about dota2 that makes it extra slow on nouveau. haven't investigated.
00:49mangix: i noticed that too. but define slow anyway
00:50mangix: oh god these gnome animations are so smooth now
00:52imirkin: more slow compared to blob perf than other games
00:53gnarface: that's weird actually, considering that it's one of the games that runs the *best* on the blob
00:53imirkin: i'm told there's a similar issue on radeonsi
00:53gnarface: as in, performs shockingly well even on what valve considers "ancient" hardware (tested on a 560 Ti 1GB)
00:53mangix: the problem i've most noticed is with mouse input
00:54mangix: but yeah i expect nouveau to be slower than the blob
00:54gnarface: it just makes me curious what sort of optimizations they used
00:54mangix: 560 ti is not ancient
00:54gnarface: it runs so much better than some other even AAA titles that i suspect actually *secret* optimizations
00:55imirkin: could be that they have built-in optimized shaders due to the popularity of the game
00:55gnarface: (as in, Nvidia has fed Valve some information about hardware features nobody else knows)
00:55imirkin: that's exceedingly likely - they embed nvidia devs on all AAA teams
00:55gnarface: imirkin: yea maybe something along those lines
00:56mangix: hmm interesting
00:56mangix: so going from pstate to pstate it always uses the max clock
00:57mangix: even on 07 nouveau runs at 405 and not 135
00:57gnarface: what ever happend to that program 'nvclock' is that abandoned now?
00:58mangix: 0a: core 135-1228 - runs at 1189 mhz.
00:58imirkin: yes, it picks the highest cstate available
00:59imirkin: (some of the highest ones are actually not available due to ... various reasons)
00:59mangix: i'm guessing that would be the nvboost patches for kepler?
01:00imirkin: well, there can be a variety of reasons that a cstate isn't available
01:00imirkin: we don't do the same validation when displaying that "high" core amount as we do when actually reclocking
01:00imirkin: sometimes it points at an illegal voltage
01:00imirkin: other times the temperature is too high to let it be used
01:01mangix: i see
01:06mangix: from 30 to 104 watts
01:06imirkin: bye bye battery life
01:07mangix: funny you mention that
01:07mangix: on the blob, it downclocks on battery
01:07mangix: can't clock up
01:08mangix: seems not to be true of nouveau
01:15imirkin: nouveau theoretically allows you to set different pstates for AC and DC
01:16gnarface: i'm guessing you can sabotage the binary's ability to downclock on battery by disabling acpid
01:17gnarface: at least, it used to need acpid for that to work right
01:30imirkin: skeggsb_: are you planning on taking https://patchwork.freedesktop.org/patch/164973/ or do you want ccaione to do something?
01:32skeggsb_: imirkin: i wouldn't mind doing a quick comparison vs a mmiotrace for each subdev that it uses
01:32imirkin: skeggsb_: ok... well the bug has a mmiotrace in it
01:32imirkin: (the bug = https://bugs.freedesktop.org/show_bug.cgi?id=101601 )
01:39imirkin: skeggsb_: oh, and not to forget about https://bugs.freedesktop.org/show_bug.cgi?id=101587 :)
07:00karolherbst: mangix: there is a table in the vbios stating the max states under certain conditions, for example on_battery
07:00karolherbst: there are also other random things like SLI or such
07:04karolherbst: mangix: also sometimes those lower clocks don't make any sense, because they have the same voltage or there are no cstates for those. So it is basically just setting lower clocks without any benefit
13:20RSpliet: karolherbst: a lower clock *still* reduces power usage, even if voltage doesn't scale.
13:30karolherbst: only if there is enough load
13:30karolherbst: and then it is quite insignificant
13:31karolherbst: I tried it out once and the difference was dissapointing and within the error margin
13:32karolherbst: the only situation where it might matter is, when your fan is so broken, that even on the lowest states the GPU still gets too hot
13:32karolherbst: and the GPU needs to be even lower clocked
13:43NanoSector: hey, random stupid question of the day - I keep hearing about reclocking being added for the 9xx series, but I've been able to reclock my GTX950M for a while now - why's that? is it an older generation card in a new model?
13:45karolherbst: NanoSector: maxwell1
13:46karolherbst: those have no locked down fan controls, so we can reclock them without issues
13:46NanoSector: oh the reason maxwell2 wasn't reclockable yet is because of no fan control?
13:49karolherbst: but laptops maxwell2 usually have uefi/bios controlled fans, so that's no issue there
14:29RSpliet: karolherbst: false. every clock pulse, every transistor switch will consume power. Idle hardware has switching transistors, the (bogus) "results" are just never committed anywhere. This is why clock gating is such a big thing - as you've experienced with setting the BLCG registers yourself
14:31RSpliet: That measurements show very little benefit doesn't mean it isn't there - your statement "those lower clocks don't make any sense" is too strong for practice
14:31karolherbst: provide data to show me my messurements are wrong then
14:32RSpliet: karolherbst: I'm talking about basic knowledge of electronics. If you refuse to accept fundamentals you shouldn't be making statements at all.
14:32karolherbst: on idle there is no benefit at all, it's all within the margin of error, that's why I messured
14:33karolherbst: well even if you save like 0.01W, it still has no benefit
14:33karolherbst: well maybe a super slim one
14:33karolherbst: but it's not really worth the effort
14:34RSpliet: Exactly! We can agree that benefit is very limited, but a statement like "those lower clocks don't make any sense" is too strong.
14:34karolherbst: also, clock gating is no "big" win
14:35karolherbst: it is significant enough though to care about it
14:37RSpliet: Maybe I should read past it and assume "you don't mean it quite as strong as you express it", but well, be aware that such rash claims drive people into defence mode unnecessarily.
14:40RSpliet: whether it's truly worth the effort - I reckon for sw dev it's a matter of prioritisation and yes there's bigger fish to fry! What does it cost, what does it gain? In theory, although the power reduction is very slim it could still matter to the longevity of the chip. That is, if it reduces temperatures in local hotspots (temperature isn't constant over the entire surface of the chip). I'd be surprised if reducing a global clock by 50MH
17:00pmoreau: For those interested, I added some links to NVIDIA presentations on how the graphics pipeline is mapped to modern hardware: https://nouveau.freedesktop.org/wiki/IntroductoryCourse/ , item 3 in the NVIDIA-specific section.
17:09mupuf: it was already these
17:09mupuf: inside the DRI section
17:09mupuf: but maybe not the talk
17:11pmoreau: Ah, true, I had missed it in the DRI section.
17:12pmoreau: mupuf: Should it be in the DRI section though?
17:13mupuf: maybe not?
17:15pmoreau: part of it is probably applicable to Intel and AMD GPUs as well, but maybe not all of it?
17:16mupuf: most of it, IIRC
22:03mangix: does nouveau really support opengl es 3.1?
22:03orbea: glxinfo reports this for me: Max GLES profile version: 3.1
22:04orbea: glxinfo | grep GLES
22:04mangix: oh never mind i confused egl with opengl es
22:17imirkin_: mangix: ES 3.2 on GK20A and GM20B
22:18imirkin_: desktop chips missing ASTC support =/
22:18imirkin_: [and we're too lazy to implement it]
22:18imirkin_: [in software, that is]
22:18mangix: was looking at mpv debug messages
22:19mangix: said egl 1.4. confused it with opengl es
22:19orbea: mangix: fyi, mpv + nouveau + hwdec = bad things
22:20mangix: not using hwdec
22:20mangix: i am seeing this error though [vo/opengl] retrieving framebuffer depth: OpenGL error INVALID_OPERATION.
22:20imirkin_: more like mpv + gl + vdpau = sadness
22:20imirkin_: mpv + vdpau should be fine afaik
22:22orbea: huh, you are right, vdpau + hwdec seems fine
22:22orbea: least nothing blew up yet
22:25Lyude: mangix: double check that it's only nouveau doing that
22:25Lyude: i swear i've seen that error on my amd r9 before with mpv + vdpau
22:25Lyude: specifically when running under wayland iirc
22:26mangix: i am running under wayland as well
22:26mangix: could be a GNOME bug
22:28Lyude: it might be a gnome bug, but i'm more suspecious of MPV itself
22:29Lyude: usually an explicit GL error like that means the caller is doing something mesa knows is wrong
22:30Lyude: related: does nvidia's blob actually have a vdpau driver?
22:44imirkin_: Lyude: yes
22:47Lyude: then that makes me even more suspecious, just because nvidia's gl drivers have a very bad habit of silently working around user errors...
22:48Lyude: I wouldn't be surprised if they're doing something that's not correct with GL that only happens to work on their gl driver + vdpau driver just because nvidia's blob was ignoring errors