08:14 mupuf: karolherbst: here I am, I have done almost everything I needed to do for the week end :)
08:14 mupuf: first things first, get the nve6 to work again on nouveau
10:18 tobijk: imirkin: why havent we pushed this yet https://git.thm.de/tjkl80/mesa/commit/d859e8ed0f440a992b5a7988c6348eefc2390499 ?
10:18 tobijk: had to refresh it now, but its kinda old and in use in my mesa build every day :)
10:19 imirkin: tobijk: well, among other things, i had totally forgotten about it
10:19 imirkin: was there some reason i hated it a long time ago? i should try to find the thread
10:19 mupuf: karolherbst: your patch seems to help but it clearly is not enough for me :D
10:20 tobijk: i cant remember, thats why i'm asking...
10:20 mupuf: at least, the display does not go to sleep after a second
10:23 mupuf: ok, back to using the blob and find this voltage table
10:25 tobijk: imirkin: if there is a vali reason for not pushing it, i'm all for resolving that issue
10:26 imirkin: tobijk: yeah, i just need to reload the "state" on it. iirc there was something dumb, but i don't remember offhand
10:26 imirkin: need to find the email threads and see what was said
10:31 imirkin: tobijk: i'm sorting through some local patches first...
10:33 tobijk: imirkin: no need to hurry, i just remebered that patch myself
10:33 tobijk: although it is in my mesa build :D
11:36 briocalter: I've got a NV84 card (8400GS), but the CodeNames page is listing it under NV86, is that a a mistake? Both lspci and glxinfo report it under NV84. http://nouveau.freedesktop.org/wiki/CodeNames/
11:39 imirkin: briocalter: marketing names have only limited correlation to the chips actually on the cards
11:39 imirkin: 8400GS can also be G98
11:39 imirkin: and GT218 iirc
12:00 orospakr: Hey, my discrete nvidia GPU is in the Pwr state. While I can echo OFF to it to successfully turn it off, how do I go about running it in the dynamic DynPwr/DynOff modes?
12:01 imirkin: orospakr: there are different types of configuration
12:01 imirkin: if you have a hard mux, it's a straight up on/off situation
12:02 imirkin: if you don't have a mux, aka optimus (i think), then it's a more dynamic thing
12:02 imirkin: afaik it should do the DynPwr/DynOff thing automatically unless you've set runpm=0
12:02 imirkin: or if you don't have CONFIG_PM (and CONFIG_RUNTIME_PM in older kernels) enabled
12:06 orospakr: xhmm. so, this computer arch (rMBP 10,1) has a hard mux, but I'm running it with the mux on the intel right now. I know that Prime is working, because I can use the environment variable to run GL clients against either silicon.
12:07 orospakr: and nope, runpm hasn't been overridden on the kernel cmdline. kernel is arch's stock one.
12:08 imirkin: orospakr: is this the one with nvac + nv96?
12:08 imirkin:can't keep mac model numbers straight
12:11 orospakr: hmm, I don't know what nvac is, but the part is a 650M, which is Kepler.
12:12 imirkin: ah that's a much later one
12:12 imirkin: and that should be able to do the dynamic power thing
12:13 imirkin: orospakr: mind pastebinning dmesg? perhaps that has some clues
12:15 orospakr: https://gist.github.com/anonymous/859adbb69f6b70cede05 you'll see me manually powering down the gpu near the end, there.
12:16 imirkin: no bumblebee right?
12:17 orospakr: shouldn't be. I believe I've eliminated all traces of it.
12:18 imirkin: ACPI: \_SB_.PCI0.P0P2.GFX0: failed to evaluate _DSM
12:18 imirkin: not sure if those are bad or not
12:21 tobijk: imirkin: it is normal
12:21 tobijk: [ 3.604197] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
12:22 tobijk: from my optimus system :)
12:22 imirkin: tobijk: that one's normal yes
12:22 imirkin: tobijk: what about the failed to evaluate _DSM?
12:23 tobijk: both are present here
12:23 tobijk: [ 11.738201] ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM
12:23 imirkin: ah ok
12:55 karolherbst: mupuf: the other problem can be core voltage though
12:55 karolherbst: I know at least three cards with that problem
12:56 mupuf: karolherbst: this one has GPIO-based voltage control
12:56 mupuf: we *may* not set the right voltage though
12:56 karolherbst: your card uses PWM too?
12:57 karolherbst: ohh
12:57 karolherbst: yes
12:57 karolherbst: Karlton: has that problem
12:57 mupuf: karolherbst: no, the PWM one is another one :s
12:57 mupuf: it's the maxwell
12:57 karolherbst: wait
12:57 karolherbst: mhh
12:58 karolherbst: mupuf: do you see the issue here? http://sprunge.us/LFLY
12:58 karolherbst: this is the cstate table of Karlton on his card at 0f
12:59 mupuf: well, not sure what you want me to check here
12:59 karolherbst: look at the core clock
12:59 karolherbst: and "voltage" value and check if you see something strange
12:59 karolherbst: or different
13:00 karolherbst: or troublesome
13:00 mupuf: seems sane
13:00 mupuf: the clock goes pretty high, but it is ok
13:00 mupuf: the value is in kHz
13:00 karolherbst: mhh okay, 25 works, 26 not
13:01 karolherbst: Karlton: ping? card still stable by the way?
13:01 mupuf: well, there is a big gap between 25 and 26
13:01 karolherbst: his card seems to be working at 0f if you clock at the 25th cstate
13:01 karolherbst: but on 26 it hangs after a while
13:01 karolherbst: I assume this "gap" can be too much
13:01 mupuf: well, seems like we will have fun with this too :p
13:02 karolherbst: and therefore the voltage gets too low
13:02 karolherbst: yeah
13:02 karolherbst: this is a mess :/
13:02 mupuf: I would trust the bios
13:02 karolherbst: but
13:02 karolherbst: this card is opretty ṕretty overclocked
13:02 mupuf: it may simply be because we need to change some timeouts
13:02 karolherbst: +300MHz compared to "usual"
13:02 mupuf: it would not be the first time this happens
13:03 karolherbst: yeah maybe, or the prducer just didn't care enough putting sane values in
13:03 karolherbst: or the blob doesn't care about the voltage there at all?
13:03 karolherbst: who knows
13:03 karolherbst: it could be the same for you too though :/
13:04 karolherbst: if you want I could give you a branch with my cstate interface and you could try if lower cstates make the card stable at 0f
13:08 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commits/karlton_test there are two changes: 1. pstate file moved into debugfs 2. cstate interface added in debugfs
13:09 mupuf: karolherbst: so far, we never had issues with the voltage
13:09 mupuf: if you do not trust the value, set a highervalue by hand and check it out
13:10 karolherbst: I have to set my voltage by hand anyway :/
13:10 mupuf: yeah, right now, we do not have anything for you
13:11 karolherbst: I think this only effects some cards, where the 0f pstate has different core clocks than the lower ones
13:11 karolherbst: which isn't the case on every chip
13:15 karolherbst: mupuf: sadly I can't do anything in this domain on my card anymore, because everything seems to be super stable now :/
13:15 mupuf: karolherbst: that's always the problem with reclocking :D
13:16 karolherbst: :)
13:16 mupuf: getting one card to reclock is relatively easy
13:16 mupuf: making everyone's card work ... that's another story
13:16 karolherbst: I was also fun to get all pstates right at first
13:17 karolherbst: messed up the plls and got like 160MHz mem clock at 07/0a
13:18 mupuf: ah ah, roght!
13:18 mupuf: or the opposite
13:18 mupuf: 3GHz instead of 600 Mhz
13:18 karolherbst: ohh
13:19 karolherbst: but this is still inside a valid range :D
13:23 mupuf: ah ah, well, 3GHz was well above spec for this GPU :D
13:24 Karlton: karolherbst: yes, I am still running from yesterday :)
13:25 karolherbst: okay
13:26 karolherbst: mhh, mupuf said the issue could be something else too. I don't know which regs to check, but it would be nice to check for differences between blob and nouveau for core clock related stuff
13:26 mupuf: karolherbst: may I remind you of peek_diff?
13:26 mupuf: it is *meant* for this
13:27 karolherbst: yeah, but I don't know which regs to check :D
13:27 karolherbst: never done anything core clock related
13:27 mupuf: dump the entire range :D
13:28 karolherbst: ...
13:28 mupuf: *FB, PCLOCK, PTHERM
13:36 pmoreau: imirkin: Nouveau will print "failed to evaluate _DSM" for each DSM it tries and on which in either gets incorrect results or that DSM is not present, which is really misleading.
13:37 imirkin: pmoreau: ah ok
13:37 pmoreau: It should be cleaned up by some patches from airlied, which are waiting on the MBP switch serie iirc
13:39 imirkin: ah ok
13:39 Yoshimo: why does the log link in the topic point to dri-devel?
13:40 pmoreau: Yoshimo: Both are tracked on that page, and you can specify which one you want.
13:40 pmoreau: Though we could have the correct link directly in the topic…
13:41 pmoreau: It's just missing the "?channel=nouveau" at the end of the url
13:47 pmoreau: imirkin: Oh right, as it was a generic way to handle runpm on MBPs, it has to wait until switching and runpm works on those laptop. :) http://lists.freedesktop.org/archives/nouveau/2015-May/021098.html
13:48 imirkin: pmoreau: so... what's the issue exactly? that there are no acpi methods to turn it on/off?
13:48 imirkin: i.e. why does runpm not work?
13:49 pmoreau: For my MBP, the _DSM method uses another UUID, func revision, and functions, so Nouveau does not detect it
13:49 pmoreau: Hence why I made some patches in May
13:50 imirkin: ah ok
13:50 imirkin: orospakr: --^
13:51 pmoreau: And for later revisions of MBPs, switching from Nouveau to Intel results in a black screen
13:51 pmoreau: Which is what Lukas Wunner is trying to solve with his serie
13:54 karolherbst: mupuf: peek_diff is part of envytools?
13:56 karolherbst: mupuf: and with *FB you mean like PBFB?
13:57 karolherbst: ohh and PFFB
13:57 mupuf: right
13:58 karolherbst: and where is this diff tool? because I can't find it :/
13:59 mupuf: nvidia_vbios/scripts/
14:00 imirkin: mlankhorst: you ever seen this before? max-texture-size': corrupted double-linked list: 0x000000000172fab0 ***
14:01 karolherbst: mupuf: okay
14:09 karolherbst: mupuf: but generally you would also say, that my patch doesn't make the situation worse
14:15 imirkin: mupuf: can you let me know when you're done with reator and plug the G80 in again if it's unplugged?
14:25 mupuf: imirkin: oh, right, I am mostly doing stuff on my machine right now, trying to find something remotely plausible for the vbios table I am looking for
14:25 mupuf: give me another hour and I will go to bed
14:25 imirkin: mupuf: is the G80 still plugged?
14:25 mupuf: oh, and I should plug the rasp pi again
14:25 mupuf: nope
14:26 imirkin: could you arrange for it to be in there before you head off to sleep?
14:26 mupuf: yes, I will
14:26 mupuf: will do that now
14:27 imirkin: want to do a final push to get the lod stuff working on there
14:27 mupuf: :)
14:27 mupuf: plugged
14:28 imirkin: i've semi-sort-of-fixed it, but not all the cases
14:28 imirkin: pretty sure the blob had it all working
14:28 mupuf: so you want to check how it is doing so?
14:29 karolherbst: mupuf: would you mind to also have a working gddr5 there? maybe I play around a little with that and check some values
14:29 mupuf: I am sorry, I updated the kernel of reator, you may have a hard time recompiling an old version of the blob :s
14:29 mupuf: karolherbst: I can;t have 3 connected :D
14:29 mupuf: I will try to remember to unplug the maxwell
14:37 karolherbst: sad :/
14:37 karolherbst: :D
16:20 mupuf: karolherbst: ok, so the blob obeys at least to the maximum voltage information
16:20 mupuf: funnily-enough, it just clamps the value :D
16:20 karolherbst: mmhh
16:21 mupuf: and , if the voltage is too low, it crashes the gpu :p
16:21 karolherbst: I get the strange feeling, that the blob has some "faulty" algorithm somehwere
16:21 karolherbst: like with my pwm/clock graph
16:21 mupuf: it has asumptions, for sure :D
16:21 karolherbst: I think it just uses max volt for max clock
16:21 mupuf: anyway, it does not obey the steps
16:21 karolherbst: and then scales down the voltage for specific clocks
16:22 karolherbst: the steps were pretty linear for me
16:22 mupuf: well, the blob knows how to compute volt <=> PWM duty
16:22 mupuf: and that's what I am looking for
16:22 karolherbst: yes
16:22 karolherbst: mhh
16:22 karolherbst: idea
16:23 karolherbst: mhh
16:23 karolherbst: okay, no idea
16:23 karolherbst: ohh wait
16:23 karolherbst: idea
16:23 karolherbst: try to manipulate the max clock
16:23 karolherbst: and see if anything changes in the choosen votlage
16:23 mupuf: that still won't help with my current task
16:23 karolherbst: I see
16:24 karolherbst: what's your current task?
16:24 karolherbst: the pwm table?
16:25 karolherbst: ohh
16:25 karolherbst: now I saw it
16:25 mupuf: :p
16:26 karolherbst: mhhh
16:26 karolherbst: from my observations, the entire situation makes not much sense
16:28 karolherbst: there are some gpu boost reworks in kepler, I get the strange feeling, that it may be somehow related
16:28 mupuf: one needs to be very meticulous for this job. Change one variable at a time, and change the smallest one :D
16:28 karolherbst: what I don't understand though is, that gpu boost doesn't exist on linux, but I thought the driver is mostly the same?
16:29 mupuf: it is the same and it exists
16:29 karolherbst: I know that it exists, but the blob doesn't upclock when low temp, at least not for me
16:30 karolherbst: mhhh
16:31 karolherbst: mupuf: how much can you decrease the voltage?
16:31 karolherbst: I mean the max voltage until it crashes
16:33 mupuf: I have no clue, changing the pwm value won;t tell me the voltage as long as I won't have reversed it out
16:33 karolherbst: I am thinking, if that's the "real" max voltage, it should be still high enough to run stable at max boost clock, and when it does not, what I don't believe, then there has to be another "even more max" voltage somewhere
16:34 mupuf: I think you misunderstand how the table works
16:34 mupuf: anyway, I need to concentrate, sorry
16:34 karolherbst: k
16:40 _0x5eb_: hi, with Xorg + nouveau, is there a way to define a specific monitor as Primary (since Option Primary does not seem to be recognized by nouveau), iow is it possible to use any display other than Screen0 as Primary?
16:41 RSpliet: _0x5eb_: for what purpose?
16:41 imirkin: _0x5eb_: there's a xrandr --output FOO --primary
16:43 _0x5eb_: sorry I forgot to mention I don't use Xinerama (I use two independent displays: :0.0 and :0.1)
16:44 imirkin: _0x5eb_: oh, so 2 separate screens, i see.
16:44 imirkin: sorry, no idea. you're going to have to RTFS. what distinguishes a primary screen from non-primary?
16:45 _0x5eb_: well, the idea is just to have the login screen (lightdm) on the right display instead of the left one
16:46 imirkin: ah.
16:46 _0x5eb_: so to have :0.1 associated with the first detected output and :0.0 with the second (but I guess it's not supported by nouveau)
16:47 _0x5eb_: (well to be more accurate: DVI-I-1 as :0.1 and DVI-I-2 as :0.0)
17:49 mupuf: karolherbst: I am on the right track :)
18:02 karolherbst: wuhu!
18:02 karolherbst: what did you find?
18:15 mupuf: there is no other table
18:16 mupuf: so far, there are 4 fields in the header
18:16 mupuf: and nouveau just does not parse them as they should be, at least on maxwell
18:16 mupuf: or at least on this particular card
18:17 mupuf: there is one variable I do not know, otherwise it does not make sense
18:17 karolherbst: mhh
18:17 karolherbst: the "normal" voltage table?
18:17 mupuf: yes,
18:18 karolherbst: makes sense somehow
18:18 karolherbst: which fields to you mean exactly?
18:19 mupuf: will tell you more when I know more ;)
18:19 karolherbst: :D
18:19 karolherbst: I see
18:20 karolherbst: mupuf: what would happen if I put something too high in the pwm?
18:20 mupuf: there may be another table though
18:20 mupuf: your card will consume more power than needed
18:21 karolherbst: and if I put something _really_ high in it?
18:21 mupuf: which may lead to overheating, in extreme scenarios that nouveau probably cannot reach because it does not a super good job in the shader compiler
18:21 mupuf: I doubt you can damage the card
18:21 karolherbst: I would only change it while doing nothing anyway
18:21 mupuf: FYI, I have set it to the max quite a lot of times today
18:21 mupuf: max = 0x60
18:22 karolherbst: ohh, thats the content of the other reg
18:22 mupuf: well, you need to read up on pwm if you do not understand why it is the max
18:28 karolherbst: mhh I know in theory how PWMs work, but I don't get why especially "60" should be the max, but I now that you can't go above the max
18:29 karolherbst: but I know what you tried to explain to me :)
18:33 mupuf: div is set to 0x60
18:33 mupuf: duty cannot be bigger than div
18:33 mupuf: anyway
18:34 mupuf: nice finding: when we have a pwm_vid GPIO, then the voltage vbios table's header changes
18:34 mupuf: offset 4 in header
18:34 mupuf: 2 when using GPIOs, 3 when using PWM
18:35 mupuf: All the fun :D
18:36 mupuf: ah, one vbios has 0
18:36 mupuf: and it is using a VID-based control
18:36 mupuf: so, it is a bitfield
18:37 mupuf: bit 0: set = PWM, unset = GPIO
18:37 mupuf: let's try my theory :p
18:38 karolherbst: mhh
18:38 mupuf: looks good
18:38 mupuf: the blob refuses to boot if I set bit 0
18:38 karolherbst: I have 03, too
18:39 mupuf: I guess I need to fake GPIOs to check that out
18:41 mupuf: this freaking table starts making much more sense now that I found this switch
18:43 karolherbst: was this value used for something else before?
18:44 mupuf: nope, it was fully unknown
18:46 mupuf: see, I am happy now
18:47 mupuf: because this really did not make sense to me
18:48 mupuf: the guy who designed this is a real b*st*rd but I guess a hack was good-enough
18:55 karolherbst: :D
18:55 karolherbst: I guess there were to lazy adding a new table
18:56 mupuf: yeah :D
18:56 mupuf: or changing the version of the table
18:56 mupuf: you know, like normal people do
18:56 karolherbst: mhh
18:56 karolherbst: why should you if the other bits stay the same?
18:56 mupuf: but hey, they have already proven than they do not like updating the version :D
18:56 karolherbst: maybe they know they would use PWMs later?
18:57 mupuf: like the temperature table is still stuck at 0x10 after .... for ever!
18:57 karolherbst: ohh
18:57 karolherbst: and the layout changes?
18:57 mupuf: well, they add and remove stuff, yes :D
18:57 karolherbst: :D
18:57 karolherbst: do you need external information for that?
18:57 mupuf: In the clocks too, you need to check the length of the fields to know to parse it
18:57 karolherbst: or is it the same as here, just some bits changed
18:57 mupuf: and the chipset
18:57 karolherbst: ohhh
18:58 karolherbst: :/
18:58 mupuf: have a look at perf ;D
18:58 mupuf: version 0x40
18:59 karolherbst: I found two values which are kind of bugging me: "4f 12"
18:59 mupuf: the addresses are different for tesla, fermi, kepler and maxwell :D
18:59 karolherbst: I think 15th and 16th?
18:59 mupuf: ?
18:59 karolherbst: maybe 4f: max pwm, 12: min pwm?
18:59 karolherbst: but this doesn't make any sense
19:00 karolherbst: these values just bug me
19:00 mupuf: well, it could be
19:00 mupuf: 12 = min voltage and 4f = max voltage
19:00 karolherbst: I know that the blob uses 3f as the highest value on my card
19:00 karolherbst: and something around 20 as the lowest
19:01 karolherbst: ohh no, 26 is lowest
19:01 mupuf: dude, this is max voltage
19:01 karolherbst: ohh
19:01 mupuf: 124f80 = 1200000
19:01 karolherbst: :/
19:01 karolherbst: also
19:01 karolherbst: the order of the bytes bug me there
19:02 karolherbst: :D
19:02 karolherbst: okay, makes sense
19:02 mupuf: well, that's intel's way of representing numbers]
19:02 mupuf: least significant byte first
19:02 mupuf: and almost every processor does that
19:02 karolherbst: yeah I know, I have to get used to that first
19:02 mupuf: yep
19:30 mupuf: interesting, it seems like nvidia is changing the voltage also based on the temperature
19:30 mupuf: that's a possibility, but ... risky
19:30 karolherbst: mhhh
19:30 karolherbst: you mean if it gets hot, it lowers it?
19:31 mupuf: nope, it may increase it
19:31 karolherbst: mh
19:31 karolherbst: I know, that the blob uses 3f as the highest for me for some time and then drops to 3e, but who knows why the blob does that
19:31 mupuf: I mean, yes, it will eventually take it down if the temperature gets too high
19:32 mupuf: but at low temperature, a lower voltage is probably OK. Not sure why it makes sense, probably because a gate would flip faster at a lower temp
19:33 karolherbst: will try to get this behaviour here
19:34 karolherbst: ohh , need a better benchmark, pcie bandwith at limit
19:34 mupuf: what kind of benchmark are you looking for?
19:34 karolherbst: core full at 100%
19:34 karolherbst: furmark maybe=
19:35 karolherbst: yeah, furmark does the trick
19:35 karolherbst: but I don't get my gpu hot enough :/
19:36 karolherbst: mupuf: in your pwr_read thingy, the VID value changes
19:36 karolherbst: its either 2 or 3
19:36 karolherbst: but it swtiches pretty often
19:39 karolherbst: ohh wait
19:39 karolherbst: mupuf: are you sure about core load and memory load in this tool?
19:41 karolherbst: ohh, nvm could be my mistake
19:42 mupuf: the VID is wrong in your case, you need to replace it with the read to 20344
19:42 mupuf: ok, found another component
19:45 karolherbst: I added my pwm value there already, I just notied, that the VID part changes
19:47 karolherbst: what is "FSRM div"?
19:48 mupuf: unless you are above 97°C, you can ignore it
19:48 karolherbst: mhh
19:48 karolherbst: k
19:48 karolherbst: because its sometimes 14, but usually 0
19:48 karolherbst: how can I fake the temp the best way?
19:48 karolherbst: :/
19:49 karolherbst: I don't get it high enough, so that the voltge changes
19:49 mupuf: if you really want to know: http://phd.mupuf.org/files/xdc2013-nvidia_pm.pdf
19:49 mupuf: nvafaketemp
19:50 mupuf: if you see 14, it means your card is overheating
19:50 mupuf: which is impressive in the case of Nouveau :D
19:50 mupuf: but hey, we do not powergate the video decoding engines
19:50 mupuf: and other stuff
19:50 karolherbst: no, its with the blob now
19:50 mupuf: so we are kind of shooting ourselves in the foot here
19:50 mupuf: ack
19:50 karolherbst: and no, it does not overheat :/
19:50 mupuf: ok, then the 14 you see is because the gpu went idle for a short period of time
19:51 mupuf: read up on the FSRM in the link I provided you
19:51 karolherbst: ahhh
19:51 karolherbst: okay, nice
19:53 karolherbst: mhh
19:53 karolherbst: nothing changes
19:53 karolherbst: which temps should I try?
19:54 mupuf: well, try 30 and then 90
19:54 karolherbst: ohhh
19:54 mupuf: if the blob changes the pwm value based on temperature, it will reset it
19:54 karolherbst: the PWM is 62 with 30
19:54 mupuf: err, it will change it
19:55 karolherbst: with 50 it gets 61
19:55 karolherbst: at 95°C its still 61
19:55 karolherbst: at 1°C it is 64
19:56 karolherbst: mhh
19:57 mupuf: you are doing this when the gpu is fully idle, right?
19:57 karolherbst: nope
19:57 karolherbst: at full load
19:57 mupuf: then you are doing it wrong
19:57 mupuf: when you lower the temperature, the blob boosts the clock because it thinks it is not thermally limited
19:57 karolherbst: on windows
19:58 karolherbst: but the clock doesn't change here
19:58 karolherbst: at least not for me
19:58 mupuf: hmm
19:58 karolherbst: I also read in the nvidia forums, that there is no gpu boost on linux
19:58 karolherbst: by a nvidia employee
19:58 karolherbst: but this could be the fault of coolbits here
19:58 karolherbst: will disable it
19:59 mupuf: hmm, then I wonder what I saw
19:59 karolherbst: mhh
19:59 karolherbst: it reclocks depending on load
19:59 mupuf: I will ask Andy Ritger when I see him at XDC
19:59 karolherbst: max pstate is 705MHz here at idle
19:59 mupuf: but I guess everyone has a different definition of boost
19:59 karolherbst: but when I start doing something, it clocks up to 862MHz
19:59 mupuf: to me, nvidia does boost
20:00 karolherbst: will disbale coolbits and try again
20:01 mupuf: ok, I have all the fields of the header
20:01 mupuf: well, almost
20:01 mupuf: At least, they do not influence the actual voltage
20:01 mupuf: so, meh
20:01 karolherbst: okay, so blob doesn't boost for me
20:01 mupuf: fuck, 6 am, I should go to sleep
20:02 karolherbst: mhh 5am here :/
20:02 mupuf: imirkin: reator is yours
20:02 karolherbst: I don't feel like sleeping though,
20:02 imirkin: mupuf: cool thanks
20:03 mupuf: karolherbst: /me feels like the sun is rising
20:03 mupuf: and it actually is true
20:03 karolherbst: will take some time here
20:03 mupuf: days are getting shorter and shorter though
20:03 karolherbst: oh well
20:03 karolherbst: you get pretty short days up there anyway later in the year
20:03 karolherbst: enjoy the sun while its still there :p
20:04 karolherbst: wow
20:04 karolherbst: my blob can't control the fan
20:04 karolherbst: even with coolbits enabled
20:04 karolherbst: it can't do nothing about the speed
20:06 mupuf: of course it can't
20:06 mupuf: there is no fan on your gpu
20:06 mupuf: and yeah for the sun
20:06 mupuf: I did enjoy it a lot during the summer though
20:06 mupuf: now, the sun sets at 8:30
20:06 mupuf: and apparently rises at 6
20:06 mupuf: see you! sleep tight
20:09 karolherbst: my gpu has a dedicated fan though :/ which reacts to its temp