03:11karolherbst: imirkin: :D
03:13karolherbst: mupuf: found out anything new?
03:20karolherbst: mupuf: https://i.imgur.com/Q1lfK6d.png
03:20karolherbst: I've added the min and max values for each clockf rom the voltage map table
03:21karolherbst: mupuf: maybe the base is the middle value and is (info.max + info.min) / 2 and the other values +- 1/2
03:50mupuf: karolherbst: no, it is not the middle value
03:50mupuf: I had a lot of fun with this yesterday evening
03:50mupuf: or, should I say, this morning :D
03:51karolherbst: I just calculated the middle value
03:53karolherbst: mupuf: anyway: it is damn close https://i.imgur.com/BAj4o5I.png
03:53karolherbst: the thick lines are max min and (max+min)/2
03:54mupuf: so, for your information, the max value has almost no influence on the voltage
03:54mupuf: and you can even lower the max value under the one actually set
03:54karolherbst: that is kind of suprising
03:55mupuf: the max value is actually used in conjunction with 5 more 16-bits numbers
03:55karolherbst: so it is just min + some offset
03:55mupuf: and I got stuck there
03:55karolherbst: from the voltage map table?
03:55karolherbst: there is _one_ thing I found in the voltage map table, but well
03:55karolherbst: it only works for the boost_max_voltage entry :/
03:55mupuf: yep, and the offset is computed based on the "max" value
03:55karolherbst: maybe you figure it out
03:56karolherbst: 0x874a: 00 ff d8 ed 11 00 d8 ed 11 00 70 4a b3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03:56karolherbst: here you see the 1175000 value
03:56karolherbst: but there is also 70 4a b3
03:56karolherbst: which is 11750000
03:56karolherbst: so *10
03:56karolherbst: and I find it in every vbios
03:57karolherbst: doesn't work with the other entries though
03:57karolherbst: actually the 0 entry works too
03:58karolherbst: it seems to work pretty well for entries where max equals min
03:58karolherbst: but then it stops making sense
03:59mupuf: seriously, we just need more data
03:59karolherbst: but there is always a relation to the voltages in the entries
03:59karolherbst: even if it's higher
04:00Tom^: define data. you want something from me? :P
04:00karolherbst: 800000/837500 => 936318.0
04:01karolherbst: 800000/843750 => 942810.9
04:01karolherbst: mupuf: see
04:01karolherbst: 800000/918750 => 1115309.1
04:01karolherbst: but still
04:01karolherbst: no clue what that is
04:02mupuf: I agree, the max value has a strong correlation with the min one
04:02mupuf: but ...
04:02mupuf: it is not a max value
04:03karolherbst: maybe it is the thing I found, but why is it *10 ?
04:04karolherbst: orrr wait
04:05karolherbst: no, I can't figure that out yet
04:06karolherbst: mupuf: but what is the "max" value then if not a max value?
04:07karolherbst: it looks like it, but you may have figured out it doesn't behave like one
04:07mupuf: I do not know exactly what it is
04:07mupuf: but it is clearly not a way to clamp the max voltage
04:08mupuf: so, the name is misleading
04:09Tom^: is it the value these kepler cards have wich overclockers found, the top most volt limit they let you overvolt to. unless you mod the vbios.
04:09karolherbst: :O gnuplot broke?
04:10Tom^: so its not exactly of any worth besides limiting overclocking people to not burn it up :P
04:10karolherbst: Tom^: no, we try to figure out the voltage ranges for each clock
04:10karolherbst: or at least the ones the blob is using
04:11Tom^: iirc the limit im talking about was 1.21V or so
04:11Tom^: but oh well, carry on. ignore my stupid ramblings xD
04:12karolherbst: ohh that was the max voltage for boosting what you mean, and yes, the blob respects that value
04:13karolherbst: as long as it stays in range with the pstate voltage
04:13Tom^: yea well they limit you to that voltage even when you overclock your card yourself unless you modded something in the vbios
04:13karolherbst: mupuf: if you want, you can also have some fun with this one: http://lists.freedesktop.org/archives/nouveau/2015-December/023444.html to verify it
04:14karolherbst: but you have to stay within the range of the associated voltage of the pstate otherwise the blob seems to ignore it or something
04:14karolherbst: and clocks higher than with a sane value :/
04:15mupuf: karolherbst: no, I will stick to figuring out what the heck this table means
04:15karolherbst: it was meant for when you got some time anyway
04:15mupuf: but true, I forgot that I can try to see if any modder's tool figured it out!
04:17karolherbst: at least the kepler one didn't
04:17karolherbst: it parses the min/max value as nouveau does
04:18mupuf: yeah, to say they do a sloppy job is an understatement
04:18mupuf: same with the power budget
04:19mupuf: maybe they just use nvbios as their source of info :D
04:19karolherbst: yeah, they just list all budgets :D
04:19karolherbst: but I found something nvbios didn't know
04:19karolherbst: that max boost entry for example
04:19karolherbst: also the base/boost clocks I found out with that tool :p
04:20karolherbst: but I think this was everything I get out of their
04:20mupuf: did you check it?
04:20karolherbst: it works
04:21karolherbst: also with teh boost voltage you can change the max clock the blob uses
04:21karolherbst: quite interessting :D
04:21mupuf: makes sense
04:22karolherbst: but I only checked that value as long max==min
04:22karolherbst: I don'T know what the blob does when these differ
04:22karolherbst: and the base clock is used on idle when you force the blob to clock to max
04:22karolherbst: it still clocks up when you put some load on though
04:23karolherbst: the boost clock seems to mean nothing to the driver though
04:23karolherbst: may be only for displaying purpose or something
04:23karolherbst: anyway, it equals to what the card was "sold" with, so at least it matches those values
04:24mupuf: when voltmax is 1106250 or 1200000, I get the exact same temperature-induced changes
04:25karolherbst: "which" volt max? and at which clock?
04:25mupuf: I do my testing at the base clock
04:25mupuf: mine changes twice
04:25karolherbst: at least something :D
04:25mupuf: once at 17°C and once at 48°C
04:25karolherbst: on the gk106 card? or maxwell?
04:26mupuf: kepler is a waste of time for me
04:26karolherbst: ohh cause of GPIO?
04:27karolherbst: mupuf: do you know to which the blob boosts with your maxwell?
04:27karolherbst: and to which voltage?
04:27mupuf: never checked
04:27mupuf: and yes, because of the limited resolution provided by the gpios
04:28karolherbst: would maybe help, because the vbios looks a bit different than my kepler one (regarding the boost voltage thing)
04:28mupuf: hmm, I can check
04:28karolherbst: mupuf: also: 0xf pstate voltage voltage_min = 600000, voltage_max = 1500000
04:29mupuf: yeah, not sure what it is supposed to mean
04:29mupuf: but my base clock is 1084 iirc
04:29mupuf: it is entry 55
04:29karolherbst: yeah, that I found out myself :p
04:29mupuf: from the cstate table
04:29karolherbst: avg boost is 1163
04:29karolherbst: but well
04:29karolherbst: that means nothing :D
04:29karolherbst: it should reach that though
04:30mupuf: so, let's have a look again at those values
04:31mupuf: I will have to go to the groceries and sauna soon, so I wouldn't mind letting the machine collect data for me :p
04:31karolherbst: mhhh, maybe it indeed boosts to 1163
04:31mupuf: I want to check if min really is the base now
04:32karolherbst: yeah I think your card boost to 1163, higher clocks have way too high voltages attached :D
04:32karolherbst: maybe 50MHz more, but that doesn't matter much then
04:32mupuf: oh fun, oh joy :D
04:33karolherbst: what happend :D
04:33mupuf: upping the min voltage from 0.95 to 0.96V did not change the value set :D
04:33karolherbst: and let me guess, your card doesn't need additioanl power suply?
04:34karolherbst: or does it uses a 4pin thing?
04:34mupuf: nope, it does not need anything
04:34karolherbst: or maybe your card has this 38W power budget
04:34karolherbst: then its fine
04:34mupuf: why is it risky?
04:35karolherbst: well the other has 70W
04:35karolherbst: and pcie alone can only provide 75W
04:35mupuf: which is still fine
04:35karolherbst: ohh okay
04:35karolherbst: I just though you should have a bigger safety margin than <5%
04:35mupuf: pff, seriously :D
04:35mupuf: that is still very large :p
04:35karolherbst: you think so?
04:36karolherbst: I see my power consumption jump by several W within seconds, but maybe the gpu detects that faster
04:36mupuf: the seriously is about this: setting min to 0.6V still does not influence the output voltage
04:36karolherbst: mupuf: for the entries?
04:36mupuf: for entry 55
04:36karolherbst: mupuf: you might want to change the pstate entry too
04:36karolherbst: ohh wait
04:36karolherbst: it is the borked one :D
04:37mupuf: borked one?
04:37karolherbst: yeah 0.6V - 1.5V for 0xf pstate
04:37karolherbst: doesn't make sense somehow
04:38mupuf: maybe it is the allowed range for this pstate
04:38mupuf: and the cstates are selected to be between those values
04:38karolherbst: yeah well
04:38mupuf: that would be a good experiment
04:38karolherbst: still that doesn't change the fact that this range doesn't make much sense
04:38mupuf: setting min and max to 0.6V yield a change though :D 943750uv
04:39karolherbst: mupuf: try to set the values to the 54th entry
04:39karolherbst: and see if you still get 943759uv
04:39karolherbst: I always got the feeling that the blob somehow calculates a linear thing through all of these values, but that is just a guess
04:40mupuf: true that it is the value of the previous one
04:40karolherbst: and if you set the 54th and 55th to the 53th one?
04:41mupuf: no change when changing the 54th
04:41mupuf: let's change the 56th
04:42mupuf: still no change
04:42mupuf: I don't think it uses the surrounding valyues
04:43karolherbst: maybe you need to change all of them to 0.6V :p
04:43karolherbst: could be some weighted function or something :/ no clue though
04:46mupuf: nah, it is becoming ridiculous
04:46mupuf: I am sure all the informations to set the voltage is to be taken from those lovely values after
04:47mupuf: any idea what the first byte means?
04:48karolherbst: I will ask the tool first, it changes the values, that's how I figured out that they are equal to the min value * 10 if min equals max
04:49karolherbst: no, it seems to set it to 0 for the pstate entry
04:49karolherbst: try set it to 0 for the cstate entry?
04:49karolherbst: maybe it does nothing
04:52mupuf: people don't add random value for no good reason :p
04:54karolherbst: so you set all next 4 bytes to 0?
04:55karolherbst: maybe just set the entire entry to 0
04:55karolherbst: maybe the blob doesn't care at all
04:55karolherbst: who knows :D
04:55karolherbst: maybe the 2nd byte should be ff
05:01mupuf: well, that would indeed be interesting
05:14mupuf: karolherbst: where is the base clock stored?
05:22karolherbst: mupuf: https://github.com/karolherbst/envytools/commit/b507bcad07b78fe43c4ff7f50f09e798c8b9030d
05:23mupuf: karolherbst: it did not land?
05:23karolherbst: not yet: https://github.com/envytools/envytools/pull/30
05:24karolherbst: quite unsure about this tdp thing though
05:24mupuf: let's land this and work from there
05:24mupuf: I want to do something simple
05:25mupuf: sweep through the frequencies and see how the voltage increases
05:25karolherbst: for that you should be able to just increase the entry number or lower
05:25karolherbst: because the lower have higher clocks
05:25mupuf: I am sure there is a model, since writing 0 to the entire voltage mapping entry changes some stuff, but not much
05:26karolherbst: you only have three entries :/
05:26karolherbst: yeah, I figured
05:26karolherbst: but the entry alone doesn't mean everything
05:26karolherbst: mupuf: why not just writing 0 to every entry
05:27karolherbst: mupuf: 0x7146 + 5 for your card
05:27karolherbst: two bytes
05:28karolherbst: entry in MHz * 2
05:28karolherbst: 79 08
05:28mupuf: hmm, it is going to be messy :s
05:29karolherbst: ohh wait
05:29karolherbst: 0x714d + 5
05:29karolherbst: the other was the tdp entry :/
05:59mupuf: so convenient that the blob can report the clocks from the command line, no need to run a modified version of nouveau in the background
06:03mupuf: I need to port my patch to the latest nouveau to support my maxwell
06:05mupuf: I still need to use my pwm-reading code to read the voltage though as the blob always advertises 1.2V
06:05karolherbst: for me too
06:07karolherbst: ohh wait
06:07karolherbst: it reports 0 for me :/
06:10mupuf: ok, got the data
06:11Tom^: imirkin: ping.
06:11Tom^: imirkin: i forgot to report back https://bugs.freedesktop.org/show_bug.cgi?id=90181 , but im running cs:go at ~140fps right now. so yea things are fixed :P
06:12mupuf: requested core freq,actual core freq,memory freq?,temperature,blob volt, pwm value decimal, actual voltage
06:12karolherbst: memory seems about right
06:13mupuf: will plot that after buying my groceries, I should have done it 2 weeks ago and I seriously have nothing left to eat :D
06:13karolherbst: these pwm value jumps are rather big though :D
06:14karolherbst: in the end
06:16mupuf: exponential, bitch! :p
06:16mupuf: really need to go though :D
06:16mupuf: ok, see you in a bit!
06:28RSpliet: mupuf: cutting boards accumulate quite a lot of flavour over their lifetime... if you're looking for something to eat
06:29Tom^: RSpliet: sane people wash them from time to time.
06:57mupuf: Tom^: heresy!
07:14imirkin: Tom^: hope you got one of those 144hz screens...
07:15Tom^: imirkin: nope sadly not
07:16Tom^: only 2 EIZO IPS
07:16imirkin: 2 * 60hz = 120hz? :)
07:16Tom^: sure if we tweak the nouveau driver to send one fram on each other monitor.
07:17karlmag: is that a weird form for non-interlacing?
07:18Tom^: the more fps you get the better your aim is.
07:18Tom^: proven fact
07:24Yoshimo: i thought after a certain treshold latency matters more
07:24Yoshimo: connection that is
07:38aboll: imirkin: the Debian bugtracker is email based, so you can just download a specific mbox from the bts and reply to it or use the reply link from the bugreport
07:39aboll: imirkin: just make sure that you use reply-all to not loose the bug reporter or the bts itself
07:39imirkin: aboll: right... in the meanwhile i've soured a bit on stk, so dunno if i'll be investigating it further
07:39aboll: imirkin: I'll write a new mail and add you in Cc
07:40imirkin: it seems like their solution to problems reported by people running nouveau is to tell them to use nvidia blob drivers
07:41Yoshimo: imirkin: it might even work to do so ;)
07:41imirkin: so my solution is to tell people to try 0ad :)
07:42karolherbst: imirkin: I read the thread and I think this guy is just not open minded, well I mean how unlikely it is that something changes in nouveau in one year :/
07:43imirkin: i'm sure he has his reasons... i get his position
07:43karolherbst: yeah I know
07:43karolherbst: but the thing is, he also develops software
07:43imirkin: it's not a novel one :)
07:43karolherbst: he should know that one year is a lot
07:43karolherbst: the other person was nice though
07:45Tom^: one year ago nouveau didnt even run on this card. today i have boost clocks, and unigine heaven with tesselation.
07:48imirkin: yeah, but nouveau ran fine on plenty of cards
07:48imirkin: yours was just... special :)
07:48imirkin: thanks for helping us get nouveau working on it btw =]
07:48karolherbst: imirkin: actually I think his card wasn't that special, there was just the fan issue and some reclocking, or was there anything else?
07:49imirkin: yeah... ctxsw
07:49imirkin: and a few other things
07:49karolherbst: ohh k
07:49imirkin: you saw it in a much more working state than it was originally
07:49imirkin: a bunch of the fixes went into 3.19 and 4.0 iirc
07:49karolherbst: ahh I see
07:50Yoshimo: i offer time and a 560ti, 275gtx and 980 to get them to a platinum level ;)
07:50imirkin: Yoshimo: the GTX 275 should work well now, no?
07:51Yoshimo: probably, it is an old card, i don't plug it in that often
07:51karolherbst: Yoshimo: well there is lot of stuff to do for fermi, so the 560 ti is a good start to work with :D
07:52imirkin: the 560ti should work well, but without reclocking.
07:52imirkin: the 980 shouldn't work at all :)
07:52Yoshimo: just shout if i should peek or poke something or run one of your 200 branches karol ;)
07:52Yoshimo: imirkin: it does, but barely
07:52karolherbst: mine are kepler stuff
07:52karolherbst: except the pcie stuff
07:53karolherbst: Yoshimo: if you really have some time to help then fermi reclocking would be a good thing to implement :)
07:53Yoshimo: i am a user, so all i can do it is test stuff, i can't write it
07:54imirkin: and all i can do is write, can't test ;)
07:54imirkin: s/can't/really really really really don't like to/
07:55karolherbst: Yoshimo: I thought you could code some C? :O or was it somebody with a similiar name
07:55Yoshimo: not me, i can do a little java, but i doubt that helps
07:55karolherbst: ohh k
07:56karolherbst: well in my job everything I did was also some Java :D, but yeah, I think without any machine code language jumping into kernel developing is a bit fast
07:58imirkin: "machine code language"?
07:58Yoshimo: does that equal assembler imirkin?
07:58imirkin: it does to me, but i doubt that's what karolherbst meant
07:59imirkin: but even during the (very sad) times i had to use java, i every so often had to look at the jvm bytecode to see wtf was going wrong
07:59karolherbst: maybe I thought of system language or something like that
07:59imirkin: [eclipse's compiler and javac compiled something differently... that was fun.]
08:00karolherbst: imirkin: compiler options!
08:00karolherbst: usually eclipse should use the same compiler if you select the system jdk
08:02imirkin: dunno. this was a decade ago.
08:02imirkin: it had its own fancy progressive compiler
08:03karolherbst: really? :/
08:03imirkin: which wouldn't properly typecast varargs
08:03imirkin: so if you had, say, foo(String...) and then fed it an object, but only used object functions on the vararg, then it wouldn't give you a compile fail
08:03imirkin: or something along those lines
08:03imirkin: or rather, runtime fail
08:04imirkin: i don't remember the precise situation, but it ended up in runtime errors when compiled with javac, and working fine with the eclipse compiler
08:04karolherbst: why should you be able to feed objects in there :O
08:09imirkin: well, the code was wrong
08:13Tom^: Yoshimo: dont steal my karol to fermi, he has yet to fix the volt for cstates :P
08:14Yoshimo: as long as he doesn't have a fermi i think you are save
08:15karolherbst: ohh I have one right here, 2 meters away from me :p
08:16karolherbst: Tom^: mupuf is already taking care of further volting stuff, today and yesterday we collected some data and tried to make sense of which voltage to choose
08:16Yoshimo: sounds good ;)
08:16Tom^: karolherbst: nice
08:16karolherbst: nah men, that fermi no fun, only ddr3 and 630M :/
08:16mupuf: well, I would say that the only thing we achieved so far is to realize that the little we knew was really wrong!
08:17karolherbst: well at least we know the real voltage is somewhere in between, or isn't that true?
08:18Tom^: cant you ask nvidia?
08:19karolherbst: well we could, but maybe we can figure it out ourself and that would be actually faster :D
08:20karolherbst: mupuf: what about those downclocking on high temp thing? Before actually implenting all of this, I really would like to have this before fixing volting issues
08:20mupuf: fair point
08:20mupuf: that's a week end project, really simple
08:21karolherbst: and then we should take care of the TDP and power budget :/
08:21mupuf: you have the documentation for this already, right?
08:21karolherbst: ohhh no idea?
08:21mupuf: no, that will have to wait
08:21karolherbst: ohh you mean your pdf
08:21mupuf: I already gave you a ton of times my thesis and article about this :D
08:22karolherbst: yeah, its in my local log then somewhere
08:22karolherbst: mupuf: this? http://phd.mupuf.org/files/xdc2013-nvidia_pm.pdf
08:24karolherbst: mupuf: so in the end I would implement a "daemon" on the pmu which just checks the temp or is it something like we change some regs and we are done?
08:24mupuf: you are making it waaaaayyyyy too complex
08:24mupuf: you just need to write a few regs and that's it :D
08:25karolherbst: yeah, that was part of my question :p
08:25karolherbst: is it the FSRM part?
08:25mupuf: there are a ton of thresholds
08:25mupuf: just pick 2
08:25mupuf: set one to 97 and one to 100
08:25karolherbst: okay, for that we have to parse which temperatures are fine and which are not, too
08:25mupuf: set the FSRM to using the divided clock at all time
08:26mupuf: can't remember if it is 0 or ff you need to write
08:26mupuf: then set the divider
08:26mupuf: use the values found in my thesis ... or found on your card when running the blob
08:26mupuf: and boom, done!
08:26karolherbst: mhh actually, can the FSRM also react on the power consumption?
08:26karolherbst: sounds like it
08:30mupuf: yes, but no
08:30mupuf: it does not work as expected, it was designed for tesla
08:30mupuf: when boost and voltage changing was not a big thing
08:30mupuf: intel has something like that and it supposedly actually work
08:31mupuf: maybe it works on the tk1
08:31karolherbst: mhhh okay
08:31karolherbst: but how do we know that the clock changed because of the FSRM?
08:44Tom^: who needs dynamic reclocking, i bound 0f to F2 and 07 to F1
08:54Yoshimo: Tom^: we are all lazy, didn't you hear about the guy that scripted the coffeemachine?
08:55Tom^: ive actually had plans on buying a coffe machine with timer features.
08:55Tom^: so i can get automated coffe for my breakfast :>
09:18mupuf: Tom^: glad to see you have a better morning routine than I have
09:18mupuf: I try to wake up around 9, +/- 2h
09:19Tom^: well mostly because of work 07:00 - 16:00 , i got no choice.
09:19Tom^: weekends and vacation are a mess tho :p
09:19karlmag:wonders what that "breakfast" thing is... Heard about it before but can't say I've seen it much :-P
09:19mupuf:wake up too late to have one nowadays
09:19mupuf: the finns eat their lunch at 11:30 :o
09:20Tom^: same here, around 11:00
09:20karlmag: that's around when we have lunch at work too
09:20urjaman: not all of us
09:20urjaman: OTOH i might eat at that time and have skipped breakfast :P
09:22karlmag: urjaman: depends on if you name the meals after the time of day or which meal number of the day it is.
09:23urjaman: i'm always confused if somebody asks me what name my meal i'm having is .... i dont bother to think of that usually
09:23urjaman: like "are you having breakfast or lunch?" "umm, both"
09:24karlmag: well, that's often called "brunch", actually.
09:25karlmag: But sometimes what you call the meal will influence what you eat - or vice versa.
09:30karolherbst: mupuf: mhhh, the blob doesn't seem to do much with those FSRM regs :/
09:30karolherbst: it only touches PTHERM.FSRM_CFG_5
09:30mupuf: karolherbst: really? I doubt that :D
09:30karolherbst: well at least from the cpu
09:31karolherbst: will check the regs with nvidia loaded
09:31karolherbst: ohh 20048 changes, but not through iommu a iommu operation
09:34mupuf: that's the status
09:35karolherbst: mupuf: does nvaforcetemp trigger here anything?
09:35mupuf: let me check
09:36karolherbst: well I am thinking if I just poke the blob values into the regs and force a high temp with nouveau running, something should change, shouldn't it?
09:37mupuf: wait a sec
09:38mupuf: I will make it work
09:38mupuf: stop doing what you are doing
09:38mupuf: wait, are you on reator or is it hakzsam?
09:39mupuf: ack, hakzsam. Do you think
09:39mupuf: will check it out later
09:39mupuf: karolherbst: on the blob
09:39mupuf: nvawatch 20048
09:39mupuf: then nvaforcetemp 98
09:39mupuf: you should see changes
09:39karolherbst: :O but 98 crashes the driver
09:40karolherbst: I think I can do 97 :/
09:40mupuf: crashes the driver? :o
09:40karolherbst: I will just try
09:40karolherbst: yeah well
09:40karolherbst: the last time I did this
09:40karolherbst: the driver hung
09:40mupuf: 97 is the threshold
09:40karolherbst: and didn't want to let me stop X
09:40mupuf: wait a sec
09:40karolherbst: and stuff
09:40mupuf: the critical threshold may be at 97°C :D
09:40karolherbst: yeah, 97 should be good
09:41mupuf: it is 201e0 on fermi+
09:42karolherbst: 20048 does change though :O
09:42karolherbst: but unrelated to forcetemp
09:42mupuf: nvapeek 20480 8 please
09:43karolherbst: 201e0 changes without doing anything
09:43karolherbst: 00020480: 00000068 00000000
09:43mupuf: ok, critical is 104°C for you
09:43mupuf: nvapeek 204c0 8
09:44karolherbst: 000204c0: 00000066 00000000
09:44mupuf: hmm, 102 is the lower threshold
09:44mupuf: now, nvapeek 20138
09:44karolherbst: with 97°C it downclocked to 405MHz
09:46mupuf: nvapeek 20074
09:47mupuf: now read the documentation for those regs
09:47mupuf: fiddle with the values
09:48mupuf: and make it work :p
09:48mupuf: I never really tested it on kepler
09:48karolherbst: but how should I observe whatever happens?
09:48karolherbst: just run something and if the perf drops it works?
09:48mupuf: look at the status reg
09:49karolherbst: pit 19
09:49mupuf: that, and also look at the div used
09:49mupuf: and which fsrm is set
09:49mupuf: fsrm is like a pwm used to select which clock to use at any time
09:50karolherbst: the reg is the same with 36°C and 97°C :/
09:50mupuf: yes, you need to set the thresholds much lower than that :s
09:50karolherbst: ohh okay
09:50mupuf: they are really high right now
09:50karolherbst: I hope the blob don't mind
09:51mupuf: set them to 60
09:51mupuf: threshold 2 to 60
09:51mupuf: the other one to 65
09:51mupuf: and set the offsets to 0 too
09:51mupuf: I guess the idea behind the offsets was to send both an IRQ when reaching 102°C
09:52karolherbst: 20480 and 204c0?
09:52mupuf: and then, 3°C after, do the actual downclocking in hw
09:52mupuf: yep. sounds good
09:53karolherbst: 88 MHz :D
09:53karolherbst: 44 in the end
09:53karolherbst: but full memory clock
09:53karolherbst: yeah, makes sense :D
09:55karolherbst: I messed the driver up
09:55karolherbst: it doesn't want to go back to normal
09:55mupuf: what the heck, how did you get this clock reading?
09:56mupuf: really? interesting :o
09:56mupuf: good to know!
09:56karolherbst: it is stuck at 44MHz no though
09:56mupuf: because I had to guess the dividers based on previous gens
09:56karolherbst: your daemon still reads 705MHz
09:56mupuf: this does not affect the perf counters
09:56mupuf: ack, then all is fine
09:57mupuf: but you know, no need for the blob to understand how the hw works
09:57karolherbst: okay, so 705 / divider = 44
09:57karolherbst: sounds like 16 to me
09:57mupuf: it is supposed to be 64 ;s
09:57mupuf: but hey, see, I may be wrong!
09:58mupuf: I had to guess :p
09:58karolherbst: PWM at 47 :D
09:58karolherbst: yeah , well :/
09:58mupuf: the pwm won't go down too much though
09:58mupuf: have fun!
09:58mupuf: this is simple stuff to have fun with
09:58karolherbst: where should I be able to read the divider?
09:58mupuf: status will tell you the current one
09:59mupuf: 20074 will let you select it
09:59mupuf: read the doc in rnndb :p
09:59mupuf: I gave you the regs :p
09:59mupuf: as for ,myself, I am off to see some friends!
09:59karolherbst: ohh no
09:59mupuf: I\ll try to figure out the voltage management a bit more after
09:59karolherbst: how do I get from 705 with 0x1e to 44 :/
10:00mupuf: don't think about that too much for now
10:00mupuf: understand how the logic works :)
10:00karolherbst: okay, so that's all the regs
10:00karolherbst: mhhh okay
10:00karolherbst: first I try to poke the blob values in while nouveau runs and see what happens :D
10:01mupuf: no, nouveau won't care
10:01mupuf: this is a purely-hw feature
10:01mupuf: get rid of all the drivers
10:01mupuf: and have fun :p
10:01mupuf: the status reg is all you should care about
10:01mupuf: then. when you are done, validate with running heaven :p
10:02karolherbst: ohh okay
10:03karolherbst: mhhh, now the X server messes up again :/
10:03karolherbst: how I like the blob :D
10:08jcallen: out of curiosity, has there been any updates in the ability to use my "VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)" with nouveau? Last I checked, the driver couldn't even initialize the device to run unaccelerated 2D
10:09karolherbst: you need signed firmware from nvidia
10:09karolherbst: blame nvidia :p
10:09jcallen: and how do I get it?
10:10karolherbst: mhh write a nice email and offer zillions of dollar for them, then you might get them exclusivly
10:10jcallen:doesn't have zillions of dollars :(
10:10imirkin: jcallen: you should be able to get modesetting running
10:11imirkin: karolherbst: it's a lot more than firmware, i wouldn't even bring it up to people.
10:11karolherbst: k :D
10:11karolherbst: maybe we are lucky and somebody has zillions of dollars
10:12imirkin: well, its market cap is 18.6B... i'm sure even a tiny 5% stake would capture their attention... so 1B should do the trick
10:18karolherbst: fair enough
10:19karolherbst: if we split it by 10 it is only 100M
10:19karolherbst: sounds possible
10:19Yoshimo: why bother? You won't run out of things to do for quite a while even without maxwell
10:19jcallen: 100MM, you mean :)
10:20jcallen: (for some reason, in financials, 1MM is million, 1M is (sometimes) 1000)
10:20karolherbst: yeah like I care
10:20karolherbst: 1000 is 1k
10:22imirkin: jcallen: what kernel did you last try with your GTX 970?
10:23imirkin: jcallen: multiple people have reported working modesetting in kernel 4.2 at least
10:23jcallen: I don't remember, but I think it was 4.x, for some value of x :)
10:27imirkin: how is your screen connected?
10:27jcallen: directly to the NVIDIA card -- this is a desktop
10:28jcallen: I have the BIOS/UEFI set to use the onboard Intel as primary, but then start X on the NVIDIA card
10:28karolherbst: jcallen: you need to use prime offloading when intel is the main gpu afaik
10:29imirkin: jcallen: i meant what sort of connector
10:29jcallen: imirkin: DVI, DVI, and HDMI
10:29imirkin: and all 3 were having issues? :(
10:29imirkin: there was a bug where we weren't init'ing secondary gpu's properly i think
10:30jcallen: and I'm definately set up with the NVIDIA card as secondary -- otherwise the proprietary driver gets upset that I didn't set my kernel to use the "vga" driver, which *cannot* work under UEFI...
10:35karolherbst: mupuf: okay, got it working on nouveau
10:36karolherbst: mupuf: what bothers me though is, that the status reg switches between 0014000e and 0000ff00 in the normal case
10:41karolherbst: mupuf: with PTHERM.THERMAL_PROTECT_FSRM1_CFG_OFFSET you can really mess up the gpu
10:41karolherbst: I think it disconnects itself from the bus or something
10:56karolherbst: mupuf: okay, I think I am nearly done
10:56karolherbst: at least with those 5 regs
11:00karolherbst: mupuf: thing is, there is always a divider of 8
11:00karolherbst: and this gets increased by bit 4-6 of 20074
11:00karolherbst: so if I poke 70 into it, I get 0xf as the divider
11:00karolherbst: with 0 I get 0x8
11:01simonpatapon: arandr was working on my quad dual head system
11:02simonpatapon: I physically change monitors on a port and now it gaves me an error
11:03simonpatapon: screen hdmi1 and vga1 are cloning and cant separe them anymore
11:04simonpatapon: here is the layout command http://pastebin.com/aWe3Fwts
11:08imirkin: simonpatapon: pastebin output of 'xrandr'
11:11simonpatapon: hey you again!
11:11simonpatapon: how are you ;)
11:12imirkin: simonpatapon: what happens if you do 'xrandr --output VGA1 --off; xrandr --output VGA1 --right-of HDMI1 --auto'
11:12simonpatapon: wow i used gnome tool and it worked
11:12simonpatapon: --auto was wrong?
11:13imirkin: er wtf... both of VGA1/HDMI1 screens were in the "far" position
11:13imirkin: just now noticed that
11:14imirkin: anyways... it can be quite difficult to debug tools like arandr if they don't print out what it is they're doing... i'd recommend falling back to the commandline when you get weird fails
11:48simonpatapon: thank you veru much
11:48simonpatapon: i'll try to save arandr sricpt and reboot
13:25SylvieLorxu: imirkin: Hey, koz_ told me to poke you for my lockup issues. I'm still not really sure if they're related to nouveau at all, as I don't know how to debug these things. I'm on Gentoo, running nouveau with an NVidia GeForce GTX 550 Ti card
13:25imirkin: SylvieLorxu: are you using kde5 plasma?
13:26imirkin: if so, i have a lot of lockups reported in connection with that...
13:26imirkin: anyways, best thing to do is to ssh in from another machine and grab dmesg when you see a lockup
13:26imirkin: or perhaps the logs might make it to disk and you can check what they said on the next boot
13:26SylvieLorxu: imirkin: Yes, but I also had the issues back when I was running KDE4. I did notice the lockups seem to have become a lot less common when I switched the Compositor to XRender
13:26SylvieLorxu: Well, I don't know where I'd even find these logs
13:27SylvieLorxu: I've had this issue for... as long as I run nouveau on this card, basically :P
13:27imirkin: yeah that makes sense... the less you use nouveau the less chance it has to lock up ;)
13:27imirkin: what kernel are you on btw? and how much vram does the card have?
13:27SylvieLorxu: Oh, XRender bypasses nouveau? Today I learned (I know absolutely NOTHING about this, I'm just amazed at how good nouveau works generally)
13:27imirkin: no, just uses a different part of nouveau
13:28imirkin: which is much smaller and much much much more battle-tested
13:28SylvieLorxu: linux-libre 4.0.5, obviously with some Gentoo patches. VRAM, err, no clue. How would I find out?
13:28imirkin: and is much less complicated
13:28imirkin: pastebin your dmesg
13:28imirkin: should be in there
13:28SylvieLorxu: imirkin: https://dpaste.de/9oDA
13:29imirkin: ok, well i wrote a patch that was included in kernel 4.3 and various stable trees which minimizes some sad interactions between nouveau and kde5 plasmashell
13:29imirkin: it helped a bunch of people, but others still have trouble
13:29imirkin: pretty sure 4.0.5 is well before that patch though
13:30imirkin: looks like you have 1GB of vram, which is quite a good amount
13:30SylvieLorxu: In all fairness, I do need to update my kernel again
13:30imirkin: do your issues happen mostly on suspend/resume? if so, a kernel update can help
13:30SylvieLorxu: Nope, it is utterly randomly
13:31imirkin: k, so you're probably in the other "bucket" people =/
13:31SylvieLorxu: Today, all my lockups seem to have been when I moved my mouse over a YouTube video, but that is most likely complete coincidence seeing the history
13:31imirkin: could be. logs from after the lockup happens could be useful
13:32SylvieLorxu: If you could tell me where to look I would happily supply those
13:32imirkin: do you have another computer?
13:32imirkin: if so, try to ssh in when the lockup happens
13:32imirkin: and grab dmesg
13:33SylvieLorxu: I have another computer, but I don't have SSH set up on this device as it's not supposed to ever be accessed from the outside. Is there another, possibly easier way? Otherwise I'll put it on my todo list and try to do it when I find the time because setting SSH up properly is work :P
13:34imirkin: you could set up netconsole and receive the logs on the other computer directly
13:34imirkin: you should be able to find some online guides to help you with that
13:36SylvieLorxu: That's even creepier, I want my system to talk less to other systems, not more, heh. I'll just opt-in for the SSH option then and give you logs one day :)
13:36imirkin: do try the kernel update too...
13:36SylvieLorxu: Although I guess it's cool netconsole is possible
13:36SylvieLorxu: Yeah, let me get to that right now
13:36SylvieLorxu: I'm been putting it off for way too long anyway
13:38imirkin: i think we did something questionable for GF116... i forget when we fixed it, pretty sure it was well before 4.0 though
13:39imirkin: ooh fun. not *that* much before 4.0 -- went into v3.18
13:40prg_: how about something like while :; do dmesg > dmesg-$(date +%s); sync; sleep 10; done
13:40prg_: to get the logs without networking
13:41imirkin: prg_: dmesg -w > foo is probably simpler
13:42SylvieLorxu: Oh, that sounds much easier
13:43imirkin: but... it's not fool-proof
13:43imirkin: and normally syslog takes care of it
13:43imirkin: you should have a log file somewhere
13:43imirkin: unless you use systemd... then i have no idea how to operate it
13:43SylvieLorxu: And... some system logger I forgot which
13:43imirkin: oh right, gentoo.
13:43SylvieLorxu: It's been some years since I installed this, lol
13:43Tom^: systemd? journalctl or dmesg.
13:44SylvieLorxu: I don't know my own system anymore
13:44imirkin: SylvieLorxu: anyways, /var/log/messages should have it
13:44SylvieLorxu: I'm afraid not: https://dpaste.de/U1yS
13:45SylvieLorxu: Whoa, my kdm.log is 125MB, lol
13:45imirkin: uh wtf
13:45SylvieLorxu: It's filled with X backtraces o.o
13:45imirkin: are you not running syslogd?
13:47SylvieLorxu: Maybe not? Honestly, I'm not quite sure. Anyway, could this be my nouveau crashes? https://dpaste.de/gJfh
13:47imirkin: no, that just a leftover of a lockup
13:47imirkin: you want kernel log, not xorg log
13:48SylvieLorxu: Ah, okay
13:48SylvieLorxu: Well, I'll get you dmesg later then when it locks up again
13:48SylvieLorxu: No way to force it either
13:48imirkin: mouse over a youtube video? :)
13:50koz_: imirkin: Lol.
13:50koz_: Also, the responses you've had in that STK thread were ... enlightening.
13:51imirkin: hopefully i extinguished it... they got a lot more defensive than i expected
13:55SylvieLorxu: I... can't believe that was actually reproducible. Unfortunately, dmesg logged nothing, only my SysRq keypress (standard REISUB), so it seems either nouveau didn't log to dmesg or it's not nouveau after all? :(
13:55koz_: imirkin: Yeah, the whole 'We're making a 3D game with no OpenGL experts' thing was especially wtf.
13:56imirkin: well, people shuffle in and out of a project
13:56imirkin: they're in a pretty awkward situation though
14:32karolherbst: mupuf: any idea where the 8 base divider comes from?
14:45Tom^: how well should vsync work with nouveau, im getting tearing in movies. :< however its just the same on the blob unless i use some ForceCompositePipeLine option in xorg, apparently because of some sort of adaptive vsync according to nvidia.
14:46imirkin: Tom^: i've never seen tearing on fermi, but i've heard lots of such reports from kepler users. no idea what is different.
14:55karolherbst: Tom^: check your window manager
14:55karolherbst: what wm are you using by the way?
14:55Tom^: non compositing standalone one.
14:56Tom^: so yea tearing is unavoidable in X and window movement
14:56karolherbst: yeah well, you may want to use a compositor if you want proper vsync
14:56Tom^: but movies and games should sync
14:56karolherbst: Tom^: run glxgears
14:56Tom^: i see tearing in it but it syncs to 60fps
14:57Tom^: i fullscreened it :P
15:00karolherbst: Tom^: do you want to install kwin for testing purposes?
15:00Tom^: dear god no
15:00karolherbst: it has the best tearing prevention afaik :p
15:01karolherbst: it is a bit hacky getting tearless desktop without a compositor
15:02Tom^: yea well im not aiming for tearless, i just want mpv tearfree.
15:02karolherbst: yeah I meant tearfree
15:02karolherbst: I am quite sure you _need_ a compositor
15:02Tom^: and i am 100% sure i dont
15:03karolherbst: well did it tear with nvidia?
15:03Tom^: moving windows and scrolling in firefox does because of not using a compositor but games or rather opengl and mpv synced just fine
15:04karolherbst: that's not tearfree for me :p
15:04imirkin: karolherbst: i never get tearing on fermi
15:04karolherbst: imirkin: without a compositor?
15:04imirkin: at least not in movies
15:05imirkin: however lots of people have reported tearing with vdpau on both nouveau and blob for kepler
15:05RSpliet: Kepler tears
15:05imirkin: so... something it does oddly
15:05imirkin: thinking about that stuff always gives me a headache
15:05Tom^: then its not just my weird setup. good.
15:06RSpliet: or... I'll be honest, I didn't check in a while. but it used to always tear on the same vertical line
15:06Tom^: now that you mention it haha yea
15:06Tom^: same line
15:06RSpliet: as if the page flip happens not during vblank, but N pixels afterwards
15:23karolherbst: how many pixels?
15:23Tom^: by my estimation, 50% of the rendering window.
15:27karolherbst: mupuf: the divider doesn't have any big impact on the performance :O
15:27karolherbst: around 5%, maybe less
15:29karolherbst: Tom^: wanna test some overheating prevention stuff? :D
15:30karolherbst: but I think tomorrow is better, because that's quite some test
15:30karolherbst: you have to brick your fan support for that
15:30karolherbst: otherwise it is no real test :p
15:30Tom^: thats easily done.
15:30Tom^: one line :P
15:30karolherbst: yeah, but still for tomorrow
15:31karolherbst: I think I will dig a bit deeper into it, but basically it is easy to do
15:31Tom^: i might be half dead tomorrow tho but we shall see
15:31Tom^: got a special work assignment tomorrow in 5 hours, not sure if im gonna sleep yet.
15:31karolherbst: tomorrow is like sunday :p
15:32karolherbst: that's is the special part I suppose
15:32Tom^: some event is happening in the town, i got to place out a couple parking restriction signs and car restriction signs.
15:33karolherbst: yeah okay, that makes somehow sense
15:34karolherbst: imirkin: this might interest you: furmark blob: 55 fps, furmark nouveau 50 fps
15:34imirkin: karolherbst: let me know when they switch
15:38Tom^: karolherbst: i got 102 :>
15:40karolherbst: yeah lol, only :p
15:41karolherbst: the difference was bigger with unigine
15:43karolherbst: imirkin: maybe it makes sense to take a look at the pixmark piano shaders
15:43karolherbst: thats like core load only
15:43karolherbst: no memory operations
15:44karolherbst: should be easy to improve the driver here
15:45imirkin: i'm about to push a couple of changes that reduce the number of instructions in some shaders
15:45imirkin: just redoing one of the changes real quick
15:45karolherbst: nv50 or nvc0?
15:46imirkin: not by that much... like 0.7% in aggregate across all shaders
15:46karolherbst: if the difference to the blob is like 20% with pixmark_piano
15:46karolherbst: that's still something
15:47imirkin: well there's not a 1:1 mapping to perf in these things
15:47imirkin: in fact i haven't the faintest clue what the real effect is
15:47imirkin: but it seems intuitive that less instructions = better :)
15:49karolherbst: yeah, I think I will test the stuff tomorrow then, want to head to bed now :D
15:50imirkin: made a small fix and retesting now
16:09pmoreau: imirkin: It's really awesome that you got shader-db up and running!
16:12imirkin: anyways, those changes are pushed
16:12imirkin: heaven still works :)
16:12imirkin: [it didn't at first...]
16:12pmoreau: Eh eh eh!
16:12pmoreau: But heaven can wait! :-D
16:13imirkin: i forgot to clone the values and was modifying the reg offset in the shared one
16:14pmoreau: Haven't been able to work on Nouveau this week-end, due to contribution to an OpenHack. But I'll get back to it later this week, once I recovered some additional sleep.
16:14Tom^: imirkin: when did those changes land?
16:14imirkin: Tom^: 5 mins ago
16:15Tom^: :o got to rebuild mesa then
16:15imirkin: pmoreau: pretty happy that i finally got around to inlining those indirect addr calculations... i always hated that we generated such obviously idiotic code
16:15imirkin: turned out to be pretty easy
16:16pmoreau: That's awesome! I remember we talked a bit about it when I was beginning to get addressing working for SPIR-V
16:16imirkin: Tom^: i sincerely doubt these changes will have any visible effect on their own
16:17imirkin: Tom^: but if you make 1% improvements 50x, then it becomes a lot more significant :)
16:17imirkin: e.g. i reduced nv50 instruction count by ~1% last week
16:17imirkin: so it all starts to add up
16:17Tom^: as long as i know its faster, it will be faster. =D
16:19Tom^: hm does mesa compile with clang?
16:19imirkin: i wouldn't if i were you
16:19pmoreau: Does work for me
16:21imirkin: airlied: what gpu is that g+ post about?
16:22imirkin: airlied: i've seen that happen randomly on my GT215, and it will go away equally randomly
16:42Tom^: imirkin: nothing happend, exactly same score in unigine heaven :p
16:43imirkin: Tom^: like i said, unlikely to make significant difference
16:44Tom^: or unigine heaven is the wrong tool to measure the changes
16:45Tom^: im just getting bottlenecked on other things :p
16:47imirkin: yeah, obviously there are various benchmarks
16:47imirkin: you can try valley
16:48imirkin: or some of the unreal demos... does elemental work ok for you? i can never get that to give me more than 3-5 seconds per frame
16:55Tom^: uhm elemental?
16:57imirkin: Tom^: https://wiki.unrealengine.com/Linux_Demos
16:57imirkin: i haven't checked out the more recent ones actually
17:09Tom^: imirkin: it seems to work but it looks a bit off
17:10Tom^: imirkin: http://i.imgur.com/yzFcByh.jpg
17:10Tom^: imirkin: runs smooth but has this minecraft layer on it :P
17:12pmoreau: Could be some kind of Tetris as well :-D
17:12pmoreau: Or a pacman maze
17:12Tom^: its like the shadows are foobared and garbled all over the place
17:12Tom^: the rest is fine
17:18imirkin: Tom^: hmmmm odd. iirc i didn't see that. could be gk110-specific. or perhaps i introduced a bug.
17:18imirkin: although it usually takes like 5-10 mins to get to that point and i'm rarely that patient
17:18Tom^: yea i can test pre shader patches later
17:18imirkin: just test some release
17:18imirkin: like 11.0.x or something
17:18Tom^: sure thing, but tomorrow. :p
17:19Tom^: il probably git bisect it if its introduced
17:21imirkin: well i'm currently rebuilding chrome + firefox on my box, but after that's done i'll have a look
17:24imirkin: Tom^: did it look ok other than that screenshot?
17:24Tom^: it looks like this in the entire loop
17:25imirkin: right, but just the dude's face?
17:25Tom^: no everywhere
17:25imirkin: in the whole demo, or just parts of it?
17:25Tom^: was a fraction of a few seconds in the end where it didnt show
17:25imirkin: huh ok
17:26imirkin: well i def didn't see that in the early parts of it where you're in the courtyard
17:27Tom^: imirkin: http://i.imgur.com/xw2FalD.jpg
17:27Tom^: but yea il test some mesa releases tomorrow .p
17:31imirkin: Tom^: well, i just ran it on my GF108 at like... 500x300 where it got about 1fps, and i didn't see any artifacts
17:32imirkin: that seems like we messed up a loop or something
17:32imirkin: also since GK110 has 255 regs, the program layout will look pretty different than fermi/kepler1 (which have 63 regs)
17:33imirkin: er actually... nm. that shouldn't matter.
17:33imirkin: (not for loops)
22:12Tom^: ok let the testing commence
22:57Tom^: imirkin: same issue on 11.0.6