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