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