00:16karolherbst: hakzsam_: are you planning on working on the reator today?
00:21hakzsam_: karolherbst, hey, probably this afternoon but if you really need it I can leave the place :)
00:22karolherbst: ohh no, it is fine, I am just annoyed that nouveau locks up somewhere and I have to reboot :/
00:22karolherbst: it doesn't even crash my machine
00:23karolherbst: and nouveau still works except sending stuff to the pmu
00:25karolherbst: okay, I am done anyway for today I guess, found enough issues I can take care of locally
00:26karolherbst: and the kepler gpu is unstable at highest perf level, so this is also kind of useless
00:30prettychimp: hello allmighty ducks of nouveau, today i would like to ask stuff about setting breakpoints
00:31prettychimp: firs if the xml document of pgraph includes a string NV_MMIO , does it mean that those methods are both usable with mmio and pushbuf also?
00:37prettychimp: mwK: are you with me..?
00:37prettychimp: mwk: i think the question is retorical i mean the answer should yes, but just confirming
00:51prettychimp: *should be, but seems prettychimp as talking to himself again
00:53prettychimp: is even, so cheers.
02:30karolherbst: RSpliet: I read in the source, that currently only one transfer at the time to the pmu is possible and I guess this also means, the pmu can't send anything in between. Any idea how we could support multiple transfer at the time?
02:33karolherbst: RSpliet: I bet I have to use PDAEMON.DATA_INDEX[0x1] and PDAEMON.MUTEX_TOKEN[0x1] for commands from the pmu to the host
02:33karolherbst: then we could support single transfers from pmu->host and single transfer host->pmu at the same time
02:55RSpliet: karolherbst: sorry, I believe this code was mostly written by Ben and Martin
02:55RSpliet: I don't know all the details
03:38RSpliet: mwk: I'm looking for a description of the NV50+'s scheduler arbitration algorithms (which warp/block/grid to pick) and what could trigger a context switch. Do we have any docs on the NV50+ scheduler(s) beyond the rst placeholders? Or should I start dumpster-diving for whitepapers?
03:47mwk: RSpliet: dumpster diving
03:47mwk: also, a google patent search may turn out something
04:34mistnim: my computer freezes randomly when nouveau is not blacklisted
04:35mistnim: if I blacklist it though, I lose 2 hours of battery capacity
04:36mistnim: any suggestions?
04:44karolherbst: mistnim: could you retrieve dmesg after it froze?
04:44karolherbst: you could also try out nouveau.runpm=0, but then you loose battery capacity again
04:44karolherbst: other idea: install bbswitch and boot with bbswitch.load_state=0
04:45karolherbst: mistnim: do you want to use your nvidia gpu by the way?
04:45karolherbst: mistnim: and what gpu do you have?
11:04karolherbst: mupuf: when I want to do more pmu<=>host transfers at the same time, do I have to use PDAEMON.MUTEX_TOKEN[0x1], PDAEMON.DATA_INDEX[0x1] and PDAEMON.DATA[0x1] or is there something else I forgot?
11:06karolherbst: I was thinking about leaving the 0x0 ones for host=>pmu=>host communication and use 0x1 for pmu=>host=>pmu
13:38karolherbst: mhh, anybody any idea how I can tell the host from which data slots it has to read after an interrupt? :/
13:51Spencer_H: Do the developers need anything from an 840M chipset?
13:51imirkin_: what chip is it?
13:51imirkin_: (lspci should provide a code like GMxxx or GKxxx or whatever)
13:52pmoreau: GM107 maybe?
13:52imirkin_: Spencer_H: you need to look at https://bugs.freedesktop.org/show_bug.cgi?id=89558 if you want to get things going
13:53imirkin_: i have no idea why skeggsb hasn't pulled it into the main tree yet...
13:53imirkin_: i'm gonna go with "forgot"
13:55mupuf: karolherbst: hey
13:55karolherbst: mupuf: hi
13:55karolherbst: I am messing with the pmu :D
13:55mupuf: well, I would advise you to use a mutex in the kernel space
13:55mupuf: no need to use the hw mutexes
13:55karolherbst: got some ramp to max/min proof of concept code working
13:56karolherbst: yeah, that's not the problem
13:56karolherbst: mupuf: imagine this: pmu sends to the host, hey I want to reclock, then the host decides, well I want tor eclock memory now
13:56karolherbst: and this somehow really messes up the lcoking code
13:57karolherbst: and because I now we may want to communicate more with the pmu in general, I was thinking we could allow more calls at the same time
13:58karolherbst: also my current_load debugfs interface does some pmu communications
13:58karolherbst: so I really wnat to handle that right
13:59mupuf: yes, just use a mutex on the kernel side in the pmu driver
13:59mupuf: as simple as this
13:59mupuf: as for the reclocking part of it, did you implement what I said before to avoid re-sending IRQs?
13:59karolherbst: mhh okay, I tried that but it seems I messed up
13:59mupuf: probably yes
14:01karolherbst: mupuf: well, I came up with a simple way to avoid nacking reclocking requests at all for now, though a ACK from the host can be added simply to improve the actualy code, no redesign needed.
14:02karolherbst: Basically I only resend a request when the loads get further away from the target or if it gets on the other side
14:02mupuf: so, you may at every tick send a new IRQ if the load increases slowly?
14:02mupuf: sounds pretty bad
14:03karolherbst: I know
14:03karolherbst: but how can we handle that otherwise?
14:03mupuf: please don't do that
14:03karolherbst: even if the kernel won't ACK
14:03karolherbst: we have to resend if the load goes even higher
14:03mupuf: double hysteresis window
14:03karolherbst: because then the host may reclock
14:03mupuf: and ACK on reclocking
14:04karolherbst: I think RSpliet came up with the idea, that the host can ACK with some information added
14:04mupuf: like what?
14:04karolherbst: like, bother me again, when the load goes below this or above that
14:05mupuf: yeah, you may reconfigure the thresholds at run time
14:05mupuf: does not sound too bad, but it will be complex to come maintain
14:05mupuf: but again, why are you working on this when we do not even know how the policy should look like :p
14:05karolherbst: I know :/
14:05karolherbst: to get base stuff working
14:06karolherbst: it has to be stable that pmu=>host call thingy
14:06karolherbst: I got my kernel locked up too many times alreads
14:06Spencer_H: Alright. So I should go get the version with these patches?
14:06mupuf: well, you can call it teaching yourself, but I doubt it will be that useful in the end
14:06mupuf: time will tell
14:07mupuf: but we really need to get going on the test framework
14:07mupuf: env_dump does what you need now, it gets you the node
14:07mupuf: and much more: http://cgit.freedesktop.org/~mperes/ezbench/tree/utils/env_dump/README#n64
14:10karolherbst: thanks a lot
14:10karolherbst: I think I wanted to get used to pmu programming a bit more
14:10karolherbst: and just try stuff out a bit
14:16mupuf: sure, good learning experiment :)
14:16mupuf: Just don't waste time polishing code we may not need
14:16mupuf: and if you start coding this way then you will not be free to explore possibilities
14:16mupuf: the goal is to create the best possible solution, then try to cut corners to make it as good as possible with the simplest possible code
14:17karolherbst: I know, I know
14:17karolherbst: I already know most of the flaws of the current code and stuff
14:17karolherbst: it was just to try the concept out of sending stuff from the pmu to the host and do something
14:17karolherbst: because that doesn't happen that way I think currently
14:19karolherbst: this is code that has to be written one way or the other anyway
16:20imirkin_: hakzsam_: why do you need inputOffset *and* localOffset?
16:20imirkin_: hakzsam_: isn't one of them always going to be 0x10?
16:25imirkin_: hakzsam_: also there's no code to use the newly-added one, so...