00:25 diegoviola: hi
00:25 diegoviola: will the boost patches be mainlained at some point?
00:26 diegoviola: really impressive to see the benchmarks, but sadly I don't use nouveau anymore
00:26 diegoviola: don't have nvidia hw anymore
00:40 karolherbst: diegoviola: if we are lucky 4.7, otherwise most likely 4.8
00:41 diegoviola: cool
09:41 felipebalbi: hi, I have a "NVIDIA Corporation GK107 [GeForce GTX 650]" GPU and, at least with kernel v4.5, xorg-video-nouveau 1.0.12 and libdrm-nouveau2 2.4.67, I can get the GPU to hang by running piglit's shader tests
09:41 felipebalbi: I think it hangs on test 11572 (IIRC)
09:42 felipebalbi: there was also at least one occasion of some shader test segfaulting
10:43 |PuLi|: hi, does nouveau drivers auto detect external displays?
10:43 |PuLi|: and can i have xorg.conf and 20-nouveau.conf same time?
12:31 karolherbst: mupuf: seems like 3 runs is only fine for some of those benchmarks :D
12:31 mupuf: yep
12:32 mupuf: which benchmark is problematic?
12:32 mupuf:wants to write a way to teach ezbench about the benchmarks
12:32 mupuf: expected variance and execution times
12:32 karolherbst: well pixmark_piano has +-0.0% for me, I have to check which one has much more
12:32 karolherbst: well, at least a bit of varriance :D
12:32 karolherbst: 12.2 FPS +/- 0.0% (n=8) in piano
12:32 mupuf: heaven is also super stable for me
12:33 karolherbst: furmark: 37.44 FPS +/- 0.91% (n=13)
12:33 karolherbst: or another one of furmark: 37.14 FPS +/- 1.69% (n=3)
12:33 karolherbst: gputest:tess_x8:window has also quite a lot
12:34 karolherbst: 662.51 FPS +/- 0.14% (n=13)
12:34 karolherbst: as you see I just ran some benchmarks again on significantly changed results :)
12:34 karolherbst: it is nice that you can just add runs
12:37 karolherbst: yeah, furmark seems to be the one with the highest
12:37 karolherbst: usually above -+1%
12:37 karolherbst: ohh and triangle
12:37 karolherbst: but this could be due to boosting
12:40 karolherbst: mupuf: and it would be nice if you could adjust the benchmark execution time if supported. Like maybe in gputest it is usually enough to test only 10 seconds or something, then you could let the user adjust this and have faster results, if this is okay by the user
12:41 mupuf: well, you can always add a parameter, but this is going to flood the test list
12:41 mupuf: seriously, just set a good setting and run it enough times
12:42 mupuf: running 100 times 3 seconds may not be as good as 10 times 30 seconds
12:42 mupuf: it all depends on the inter vs intra run variance
12:42 karolherbst: I know
12:42 mupuf: sometimes, it is super stable inside a run
12:42 mupuf: but run it again and it is widely different
12:42 mupuf: this is the worst...
12:42 karolherbst: yeah but you can still let the user be stupid :)
12:43 karolherbst: fur is giving me quite a headache :/
12:46 karolherbst: current version of my report by the way: www.googledrive.com/host/0B78S7GSrzebIallIcG9sNHJFMDA
12:47 mupuf: karolherbst: it would not be called ezbench if the goal was to make it too complex
12:47 mupuf: but in all fairness, I do not deal with the execution time
12:47 karolherbst: :D right
12:47 mupuf: it is a parameter
12:47 mupuf: of the benchmark
12:47 mupuf: stored in a file
12:47 karolherbst: yeah I saw it
12:47 mupuf: change it to 30 seconds
12:47 mupuf: it is usually enough for intra variance
12:48 karolherbst: yeah
12:48 karolherbst: those gputests are quite short
12:52 mupuf: anyway, glad that you are taking a data-driven approach to optimisation
12:52 karolherbst: mupuf: anyway, how do we want to handle temperature above soft max?
12:53 karolherbst: mupuf: :)
12:53 mupuf: let the FSRM deal with temperature
12:53 mupuf: or maybe, we can ramp down to using the base frequency
12:53 karolherbst: well yeha, but the fsrm only triggers on really high temperatures
12:54 karolherbst: nvidia clocks to un-reduced min above 96°C or something
12:54 karolherbst: and with unreduced min I mean what pstate.min is saying
12:54 karolherbst: so 405MHz core, 810MHz memory (and reduced min is 135MHz core)
12:55 karolherbst: but I also don't want that nouveau holds that min state for a second, but I don't know what nvidia does there :/
12:55 karolherbst: maybe I should find out
12:56 karolherbst: stupid furmark ...
12:57 karolherbst: even n=18 isn't enough
12:57 karolherbst: but it is good enough now
13:01 mupuf: ah ah
13:01 mupuf: and yeah, adding runs on ezbench is really easy
13:01 karolherbst: I forgot to run on master...
13:02 mupuf: and since it is mostly stateless, it does not remember results
13:02 karolherbst: so master..$commit isn't the right thing
13:02 karolherbst: :D
13:02 mupuf: as in, it does not remember that there was a perf regression
13:02 mupuf: it will always go through the actual data
13:02 mupuf: and figure it out all over again
13:02 karolherbst: nice
13:03 karolherbst: by the way: pixmark_julia_fp32 has not that many runs
13:03 karolherbst: or maybe there is no loop in it
13:03 karolherbst: no clue
13:03 mupuf: oh, and if you want to reduce the variance to a certain threshold
13:03 mupuf: you can ask ezbench to run more runs
13:03 mupuf: but for this ... you need to change the code
13:03 mupuf: I have not written support for writing report parameters
13:04 mupuf: but it is the goal
13:04 karolherbst: ahh nice
13:04 karolherbst: so if I want a variance of -+0.20% I tell it to ezbench and it will run and give up after 100 runs or something
13:04 mupuf: there are many default parameters in enhance_report()
13:04 mupuf: karolherbst: yes
13:04 mupuf: the 100 runs is also configurable
13:04 karolherbst: :)
13:05 mupuf: if you want to contribute to ezbench, that could be a nice addition
13:05 mupuf: making this configurable per report and globally
13:38 karolherbst: but it is good to know that the dual issueing pass indeed has a positive impact on performance
13:39 karolherbst: mupuf: yeah, but I think those files in tests.d need to be a bit more modular. Like currently it isn't possible to easily run only fullscreen or only windowed tests
13:40 karolherbst: I think I will sure work on something at some point :)
13:42 mupuf: karolherbst: what? Of course you can
13:42 karolherbst: I meant like -b gputest:fullscreen
13:42 karolherbst: or is there a way?
13:43 mupuf: -b gputest -B window
13:43 mupuf: that will run all the gputest that do not contain window in the ame
13:43 karolherbst: ohh
13:43 karolherbst: that's the way it works then
13:43 mupuf: and you may probably be able to write gputest:.*:window
13:43 mupuf:would need to check
13:43 mupuf: I am using bash's =~
13:44 mupuf: and if it is not enough for some cases, I can move to real regexps
13:44 karolherbst: ahh right .* works
13:44 karolherbst: :)
13:44 mupuf: good to know
13:44 mupuf: -k to avoid running naything btw
13:44 mupuf: pretty useful when testing
13:45 karolherbst: mhh sometimes I get "nvc0_screen_create:874 - Error allocating PGRAPH context for 3D: -17" in my Xorg log
13:48 karolherbst: yeah, mhhh
13:48 karolherbst: this branch thing is a bit of an issue
13:48 karolherbst: I created a new branch for the good commits, but the old report is wrongly generated now
13:48 karolherbst: :/
13:52 mupuf: it got rid of the commits that ar not in the branch anymore
13:52 mupuf: I do not know how to handle this case :s
13:52 mupuf: what to do when there are multiple branches
14:00 karolherbst: you mean because of the ordering?
14:01 karolherbst: but yeah, a report might contain a commit, which is in no branch anymore
14:02 karolherbst: maybe you could just get the commit information and check if one of it's earlier commits is in the report commit set and create an order this way... but maybe there is no linear order
14:02 karolherbst: maybe git can help here though
14:02 mupuf: yea
14:02 mupuf: git can help, but I only have one timeline
14:02 karolherbst: ahh okay
14:03 karolherbst: so when there is no linear order, the report is screwed anyway
14:03 mupuf: or maybe I need to make multiple charts, one per branch
14:03 mupuf: yeah, whereas I only show the commits found in the current branch
14:03 karolherbst: right, but this might not work
14:03 karolherbst: or
14:03 karolherbst: just do a clone
14:03 karolherbst: you can clone by system path with --depth 1
14:04 karolherbst: and then you have your own git tree or something
14:04 karolherbst: or you just git clone and sync
14:04 karolherbst: and then you can mess with that git tree all you want
14:05 mupuf: no need
14:05 mupuf: there are python bindings for git
14:05 mupuf: so go through the tree and walk it in any way you want
14:05 karolherbst: yeah right, but I meant you clone the local mesa repository
14:05 karolherbst: and then you can change branches and everything
14:05 mupuf: there would be no point
14:05 mupuf: I can get all the information about the branches without changing the exposed branch on the disk
14:06 karolherbst: well what do you do when the dev messes with its mesa git tree
14:06 karolherbst: and wants to look at a 1 month old report
14:06 mupuf: well, git remembers everything ... until stuff gets garbage collected
14:06 karolherbst: okay
14:06 mupuf: but that means it is not part of a branch anymore
14:06 karolherbst: but it hasn't to be in one of the branches anymore, that's what I mean
14:06 karolherbst: right
14:08 mupuf: yes
14:08 mupuf: but what do you do? Save a copy for every commit you test?
14:09 karolherbst: well that's why I was thinking about having a local clone inside ezbench, so that you can disable the gc and always have all the commits
14:09 karolherbst: or you can even enable the GC there, because you can have a branch for every report or something
14:09 karolherbst: and those commits are always referenced
14:10 karolherbst: even if the dev cleans up it's mesa tree
14:10 karolherbst: *its
14:11 mupuf: hmm, yeah, but seriously, do we care that much about stuff that is not part of the current history?
14:11 karolherbst: I do, because ezbench messed up my old report :D
14:11 karolherbst: allthough the branch is still there
14:11 karolherbst: I just swtiched branches
14:12 karolherbst: and I think this workflow isn't that far off. You test a bunch of commits, pick the best and run more benchmarks on those to verify they really help and are good
14:19 karolherbst: and also, you do not want to destroy old reports
14:42 mupuf: well, there is truth. What I would like to do is find the most recent commit and use this commit and walk back towards the begining until I find all the commits
14:42 mupuf: all the commits we used
14:59 karolherbst: mhh
14:59 karolherbst: but the commits might be in different branches
15:00 karolherbst: ohh right
15:00 karolherbst: but what do you mean by "most recent"?
15:00 karolherbst: the commit date doesn't have to be sorted
15:01 karolherbst: like a older commit could follow a newer one
15:01 karolherbst: or the other way around
15:01 karolherbst: I think the only thing which is reliable is the parent of a commit
15:02 karolherbst: mhhh maybe the commit date is linear, but you can commit multiple commits in the same second, I don't know the resolution of the commit date
15:03 karolherbst: mhh they save the unix timestamp
15:05 karolherbst: yep, there can be multiple commits with the same commit date
16:07 imirkin: felipebalbi: are you running piglits in parallel?
16:07 imirkin: if so, hangs are expected
16:08 imirkin: this is how i run piglit: https://people.freedesktop.org/~imirkin/
16:10 imirkin: |PuLi|: yes, hotplug detect is something supported by nouveau. not 100% sure what you mean by your other question, i guess it depends on some of the specifics of your setup.
16:23 |PuLi|: imirkin: ok, whats wrong in my setup becouse autodetect doesnt work
16:23 |PuLi|: running arch on hp laptot
16:24 imirkin: |PuLi|: pastebin dmesg and xorg logs, and describe the issue
16:25 mupuf: karolherbst: yep, there would be multiple commits with the same commit date
16:25 mupuf: actually, this can only happen if you rebase
16:26 karolherbst: yeah, but still
16:26 karolherbst: at least the commit date is ordered
16:31 mupuf: yep
16:31 mupuf: but then it is misleading to show them in this order...
16:31 karolherbst: why?
16:31 karolherbst: the commit date should be the same
16:31 karolherbst: *ordered the same
16:32 karolherbst: the author date can be different
16:32 mupuf: nope
16:32 karolherbst: sure that the commit date isn't ordered?
16:33 imirkin: author date and commit date are entirely unrelated dates
16:34 karolherbst: I know
16:34 mupuf: yep, they are
16:34 imirkin: although it's safe to say that, other than clock skew, commit date >= author date
16:34 karolherbst: and the order of the author dates can be random
16:34 imirkin: absolutely.
16:34 mupuf: imirkin: well, this is true because the tz is there
16:34 karolherbst: imirkin: yeah, but I am sure that the commit dates are ordered
16:34 imirkin: i reorder my patches all the time
16:35 karolherbst: right, but the commit date gets updated
16:35 imirkin: so author dates can be a bit random
16:35 imirkin: that's right.
16:35 karolherbst: so for the entire history commit.commit_date >= commit.parent.commit_date
16:35 mupuf: karolherbst: maybe not, what about if you push right when the daylight saving time kicks in? Or maybe it is stored as a timestamp
16:35 imirkin: except for clock skew, yes
16:35 karolherbst: right, clock skews always mess up
16:35 karolherbst: but that's true for like everything then
16:35 imirkin: e.g. i commit something, push it out, then you pull, commit, etc, but your time is off by, say, 5 minutes
16:36 karolherbst: mupuf: it stores the timestamp
16:36 imirkin: i know, i'm just saying.
16:36 karolherbst: mupuf: or at least I thought think it does :D otherwise it is crazy
16:36 imirkin: it's not a fundamental invariant
16:36 karolherbst: mhh
16:36 karolherbst: good point
16:36 imirkin: and people with bad local times push things out all the time
16:36 karolherbst: but this is for dev branches
16:36 imirkin: sometimes it's bad by like 5 seconds, and nobody notices
16:36 karolherbst: I think those will only happen by accidence
16:36 imirkin: other times it's bad by multiple hours, and then the commit dates look really weird :)
16:37 karolherbst: :D
16:37 karolherbst: right
16:37 imirkin: i probably notice something like that once every few months on the mesa tree
16:38 karolherbst: mupuf: I am sure you can just assume the commit date being strictly sorted and then just use the newest commit from the set, but all those commits can have the same date anyway
16:38 karolherbst: mupuf: so maybe in the end you should check the parents of those commits or something too :/
16:38 mupuf: yeah, you need to look for the newest commits
16:38 mupuf: then eliminate all the parent ones
16:38 karolherbst: can git give you the newest one from a given set? :/
16:38 mupuf: and pray for having only one at the end
16:39 mupuf: otherwise, you pushed 2 branches
16:39 mupuf: well, we can code this
16:39 mupuf: it is non-trivial
16:39 karolherbst: mupuf: but hey, maybe you should detect this and print an error
16:39 mupuf: but the python bindings are fine
16:39 karolherbst: if the commits are branching in the history, you just error
16:39 karolherbst: until you support multiple timelines
16:39 mupuf: or just show individual reports per branch
16:39 karolherbst: or this
16:40 mupuf: I will need to fix this shit soon-enough, because of bisecting when there are merges
16:40 karolherbst: but in the end you have to build a tree out of the given commits I think
16:40 karolherbst: and most likely you can get the shared parent of two commits
16:41 karolherbst: and if you know the commit date, I think you might be fine
16:41 karolherbst: ahh
16:41 karolherbst: git merge-base :)
16:42 karolherbst: awesome!
16:42 karolherbst: this works
16:42 karolherbst: mupuf: " git merge-base 37912b8774 08da8b123c57" -> 37912b877410e8bb537a3cfa165ec9f3513ecd60
16:43 mupuf: what is this?
16:43 karolherbst: so you can just feed two commits to git-merge-base
16:44 karolherbst: and it will give you the common ancestor
16:44 karolherbst: or more
16:44 karolherbst: and if you feed two commits from the same branch
16:44 karolherbst: you get the oldest one
16:46 karolherbst: yeah git-merge-base is the tool you want to use here :)
17:04 mupuf: oh, that is indeed pretty cool
17:08 karolherbst: mupuf: and if you pass all commits/commit ranges, you get the common ancestor of all and maybe you could run the benchmarks on this commit too and dispaly a nice tree view :) or link to different reports or something
17:09 mupuf: that is pretty nice indeed
17:19 karolherbst: that smarter pow lowering pass has a really huge impact on performance (2.16% in pixmark_piano)
17:19 karolherbst: even 0.25% in pixmark_volplosion
17:20 karolherbst: ohh wait, there is still one commit in between
17:20 karolherbst: but anyway, more perf in some tests and no regression in others :)
17:20 karolherbst: that I like
17:31 mupuf: :)
19:18 karolherbst: mupuf: from where do I get glbenchmark?
19:19 mupuf: karolherbst: you don't? unfortunately :s
19:19 mupuf: or, you pay a lot of money
19:19 karolherbst: :/
19:19 karolherbst: at least lightsmark is free
19:19 mupuf: the new one works on linux
19:19 mupuf: but ... it requires manual intervention
19:19 karolherbst: ...
19:19 mupuf: not saying that we cannot script this
19:20 mupuf: but it will take work
19:20 karolherbst: so if I don't see the window I can't run it?
19:20 karolherbst: or what do you mean?
19:20 karolherbst: because lightsmark seems to be supported by pts
19:22 mupuf: lightsmark is free IIRC
19:22 karolherbst: ohh you were talking about glbenchmark
19:22 mupuf: yep
19:23 mupuf: glbenchmark 4.0 can be download
19:23 mupuf: ed
19:23 mupuf: but ... you need to click on buttons to start the benchmark
19:23 mupuf: and then I do not know how to get the data out
19:23 mupuf: but hey, maybe we can automate this :D
19:23 mupuf: with X, we can do all the shit we want :D
19:28 mupuf:is checking it out
19:28 mupuf: because it bugs me hard that I canot test any of the gfxbench benchmarks on nouveau :s
19:35 mupuf: results.sqlite <-- sounds promising
19:38 karolherbst: where can I get the unreal4 benchmark thing?
19:38 karolherbst: is it the elemantel demo?
19:42 karolherbst: mupuf: by the way the mmio.dumps avatare has changed now :D
19:54 karolherbst: mupuf: there is something funky with the xonotic benchmark :D
19:54 karolherbst: mupuf: either I get like 248 fps or 196 fps
19:55 karolherbst: and the power consumption graph looks really different
20:10 RSpliet: imirkin_: fwiw, Fedora 21 was declared end-of-life in December 2015, after both 22 and 23 were released (6-month release cycle)
20:10 RSpliet: no updates for libdrm will happen for that cornell dude
20:11 imirkin: RSpliet: ok... not-my-problem :)
20:11 RSpliet: heh, I agree on that half :-)
20:13 karolherbst: most likely they want to know with which commit to fix it :)
20:24 mupuf: karolherbst: you can download the ue4 demos from the normal location
20:24 mupuf: any demo works
20:24 karolherbst: ahh okay
20:24 mupuf: i need to improve the test profile
20:24 mupuf: so as we can specify the resolution
20:24 mupuf: will probably make a 720p, 1080p and 64p resolutions
20:24 mupuf: the last one for testing the cpu usage
20:25 karolherbst: I see
20:25 karolherbst: any ideas about the weird xonotic behaviour?
20:28 karolherbst: mupuf: but it is really awesome, that the power consumption graphs are really stable between graphs :)
20:44 mupuf: xonotic is very cpu-bound
20:44 mupuf: and it is often seen that cpu-bound apps get wiidely different performance behaviours between runs
20:44 mupuf: this is often due to different alignments
20:44 mupuf: in the memory addresses
20:45 mupuf: this is something we need to work on
20:52 karolherbst: mupuf: ahh okay
20:52 karolherbst: mupuf: I was curious because there seem to be two different performances in total
20:52 karolherbst: and that I get either the fast or the slow one
21:18 mupuf: karolherbst: yes, very commin :s
21:19 mupuf: that is definitely what I called the inter-run variance
21:25 karolherbst: awesome, lightsmark works :)
21:26 karolherbst: mupuf: I could write a profile for tesseract maybe
21:43 karolherbst: mupuf: okay, I think before we land those reclocking patches, I should at least implement the downclock on high temperature thing, because I reached 101°C on boost 1 and this is something we really want to do
21:43 karolherbst: or would you say it doesn't matter that much fornow?
21:55 karolherbst: mupuf: by the way. In lightsmark, how can I select only the non cpu run?
21:55 karolherbst: the tests are called lightsmark and lightsmark:cpu
21:57 karolherbst: seriously... lightsmark links against libGLEW.so.1.5
21:58 karolherbst: uhh 2008
21:58 karolherbst: k
22:08 mupuf: karolherbst: lightsmark$
22:11 karolherbst: ahh
22:11 karolherbst: good
22:12 karolherbst: and tess_x16 has the highest power usage on my GPU :)
22:13 karolherbst: wierd
22:13 karolherbst: the longer the benchmark runs, the higher the power consumption gets
22:14 karolherbst: and at 100°C the fsrm hits :)
22:15 karolherbst: still at 70W straight
22:15 mupuf: well, this should not be a surprise to you
22:15 karolherbst: right
22:15 karolherbst: okay
22:15 karolherbst: my fans can cool away like 68°C
22:15 karolherbst: ..
22:15 mupuf: I already showed you that when the temperature increases, the power usage does so too
22:15 karolherbst: *68W
22:16 karolherbst: ahh right
22:16 karolherbst: I remember
22:16 mupuf: yeah, seems like your fan cannot dissipate the budget that is set
22:16 mupuf: so... bad design!
22:16 mupuf: or it is a little dirty
22:16 karolherbst: littly dirty it is :D
22:16 karolherbst: after I cleaned my CPU fans
22:16 karolherbst: turbo boost reached 300MHz more
22:17 karolherbst: :)
22:17 mupuf: AHAH
22:17 karolherbst: okay now the important part
22:17 mupuf: seems like gfxbench4 encrypts its database
22:17 karolherbst: do I exceed the budget with nvidia :)
22:18 mupuf: that sounds stupid to do, since the password must be stored locally
22:18 karolherbst: if not I can still increase the voltage :)
22:18 karolherbst: mupuf: right :D
22:18 mupuf: karolherbst: sqlite is at least not linked dynamically
22:19 mupuf: so, it won't be trivial ?D
22:19 karolherbst: I am sure it will be
22:19 mupuf: but .. do they link to openssl? :D
22:19 karolherbst: no, they wrote their own crypto of course
22:19 karolherbst: like every professional does :D
22:19 karolherbst: with stack based random number generators and shit :)
22:20 mupuf: ah ah
22:20 mupuf: yeah, probable :D
22:20 mupuf: well, it definitely looks like it
22:20 mupuf: seriously though....
22:20 mupuf: what the fuck
22:22 karolherbst: yay 72W with nvidia
22:22 mupuf: 70 for nouveau?
22:22 mupuf: now, what about the perf difference?
22:22 karolherbst: nouveau gets to over 80
22:22 mupuf: lol
22:23 karolherbst: yeah, those tests are burner
22:23 mupuf: oh, how do you test with nvidia btw?>
22:23 karolherbst: furmark, and tess_x8 and tess_x16
22:23 karolherbst: ...
22:23 mupuf: do you use -p x11-gl?
22:23 karolherbst: no, I run it manually
22:23 karolherbst: 90°C :)
22:23 mupuf: ok, ezbench is fine with running the blob
22:23 mupuf: the x11-gl profile does not try to recompile anything
22:23 karolherbst: yeah, I just want to hit the budget on nvidia
22:24 karolherbst: 76.7W :)
22:24 mupuf: well, maybe it downclocked
22:24 karolherbst: nope
22:24 karolherbst: not yet
22:24 karolherbst: 96°C :)
22:24 karolherbst: ahh
22:24 karolherbst: it clocks down at 96°C
22:24 karolherbst: 862->836MHz
22:28 karolherbst: sad I didn't hit the budget
22:28 karolherbst: :/ 77.57W maximum
22:29 mupuf: wait for the titan :D
22:29 mupuf: these beast hit budgets like yay
22:29 karolherbst: sure?
22:29 mupuf: yes
22:29 karolherbst: k
22:29 mupuf: let me find you something
22:30 karolherbst: okay, at least I think I know what nvidia does
22:30 mupuf: http://phd.mupuf.org/files/xdc2013-nvidia_pm.pdf <--power limiter on Fermi and newer
22:30 mupuf: figure 11
22:31 karolherbst: wow
22:34 karolherbst: okay
22:34 karolherbst: nvidia uses some time based downclock on exceeding 96°C
22:34 karolherbst: like it checks every 0.1 seconds and if the gpu is still above it, downclock one cstep
22:36 karolherbst: mupuf: idea: when we exceed a special temperature, we check the temperature more often and as long as we are above the "downclock threshold" we reduce the cstate by 1 every check
22:36 karolherbst: and after the temperature felt enough, we remove this limit
22:36 mupuf: but what is the lower threshold that gets rid of this mode? :D
22:37 mupuf: well, easy to reverse :D
22:37 karolherbst: yeah
22:37 mupuf: force the temperature :p
22:37 karolherbst: it is around 90
22:37 karolherbst: and 97 was downclock
22:37 karolherbst: nouveau has 95 and 92 set
22:37 mupuf: well, that is something we need to do too then
22:38 karolherbst: yeah
22:38 karolherbst: but it is funny to watch the clocks fall at 97°C :)
22:39 karolherbst: ohh
22:39 karolherbst: and the clocks are increased slowly too
22:42 karolherbst: funny
22:42 karolherbst: https://gist.github.com/karolherbst/c5f4b7ad3eb0132aa2a92a0bb00c6011
22:42 karolherbst: 97 and 98: downclock slowly
22:43 karolherbst: below 91: upclock slowly
22:43 karolherbst: 99: downclock to min
22:45 karolherbst: FSRM config: 96/99/102/104 => 0/2/e/off
22:45 karolherbst: 96: downclock threshold?
22:45 karolherbst: 99: downlock to min threshold?
22:46 karolherbst: allthough a little bit of the fsrm hits at 99°C already
22:46 karolherbst: mhh at 100
22:50 karolherbst: I don't find 91 or 90 though
23:00 mupuf: well, 96-5
23:00 mupuf: the 5 here may be found in the thermal table
23:00 karolherbst: in the vbios?
23:02 karolherbst: doesn't seem like it
23:05 mupuf: yep
23:05 mupuf: well, then it is fixed
23:05 mupuf: and it is -5°C
23:05 karolherbst: maybe in UNK50
23:06 karolherbst: 0x94ed: 01 ff e0 0b 60 07 00 0c c8 00 12 30 ff ff 60 00
23:06 karolherbst: 0x94fd: 40 00 20 00 80 ff 20 fe d4 30 00 00
23:06 karolherbst: :D
23:07 karolherbst: 0x2 and 0x6 are temperature / 32
23:08 mupuf: that would be weird
23:11 karolherbst: I have no idea how I want to implement this downclock on high_temp, because I really don'T want to push the logic into therm
23:12 karolherbst: clk->temp_cstate_offset and modify it, but that sounds wrong
23:12 karolherbst: *therm
23:13 mupuf: well, where else but therm should you add it?
23:13 mupuf: I would say that yes, the logic needs to be there
23:14 mupuf: and when you call the update function
23:14 karolherbst: yeah but therm shouldn't decide on a cstate_offset
23:14 karolherbst: maybe more like a percentage value
23:14 mupuf: you need to give a parameter that takes multiple values
23:14 karolherbst: mhh
23:14 mupuf: like: free to increase as fast as you want, free to increase a little, not free to increase, decrease a little, decrease a lot, decrease to max
23:15 karolherbst: maybe we could save in therm the time where we went above the downclock threshold
23:15 mupuf: yes, that stays in therm
23:15 karolherbst: and feed clk on the update function on how long we are already above it
23:15 karolherbst: or something like that
23:15 mupuf: no, this is too low-leel
23:15 mupuf: level
23:15 mupuf: just give constraints
23:15 mupuf: like what I said above
23:16 karolherbst: or just a percentage value?
23:16 mupuf: percentage? well, makes no sense to me
23:16 karolherbst: well downclock by 60% :)
23:16 mupuf: but.. before we talk about the design, let's see if there is a table for this
23:16 karolherbst: nvidia seems to use a pretty high accuracy for that
23:17 karolherbst: it seems to go through every cstate
23:17 karolherbst: and then jumps in the middle
23:17 mupuf: well, as I said, let's find if there is any table that controls this
23:17 karolherbst: yeah, maybe it is in the vbios :)
23:17 mupuf: because the thermal table is a joke nowadays
23:18 karolherbst: because there are alos those stupid keplers with 3 cstates
23:18 mupuf: since it got split into many tables
23:18 karolherbst: right
23:18 mupuf: good ridance!
23:18 mupuf: seriously, therm was considered as a script
23:18 mupuf: which is ridiculous
23:18 karolherbst: :/
23:18 karolherbst: yeah
23:19 karolherbst: and then the scripts are all gone and we have to configure the fsrm :)
23:22 mupuf: yeah, pretty sure the FSRM would be configured based on this data
23:22 mupuf: luckily, we do not need to do anything for the primary gpus
23:22 mupuf: but the secondary ones...
23:22 karolherbst: why for the secondary ones?
23:26 mupuf: because they are never POSTed
23:26 karolherbst: ohh right
23:35 karolherbst: I will head to bed now anyway I hope I can find out more about those new tables :)