00:13gnurou: skeggsb: airlied: sent a fix that is not a hack for the dma_to_phys() issue (against the Nouveau tree for now - Dave, let me know if you want it against the kernel as well or if we can survive with your fix for a short time)
00:21vinceh: Hello nouveau, I'm trying to set the ZBC color from user space. I suppose I can do that through nvif, right?
00:21vinceh: the precedure looks like nvif_client_new -> nvif_device_new -> nvif_object_init for GR -> nvif_mthd for ZBC mthd
00:24vinceh: but I failed to init the object. it seems that's because the gr must under a channel object? any ideas?
00:25vinceh: btw, I'm using the nvif in k3.18.. I know the interface changed recently..
03:15karolherbst: how can I check if I have hang the pmu?
03:35karolherbst: ohh crap, got a hang in nvkm_pmu_send :/ I bet I have to do some stuff before we can trigger calls from the pmu itself :/
03:40karolherbst: RSpliet: when I send something from the pmu to the kernel, and this triggeres a call on the pmu (like memory reclocking stuff for example) can this hang the entire pmu somehow?
03:40karolherbst: mhh, as it seems the pmu still works
03:41karolherbst: but nvkm_pmu_send just get into hangs
03:41RSpliet: not entirely sure tbh... can't recall whether you need to ack a msg receive or not
04:44karolherbst: RSpliet: I think I have to call wake_up(&pmu->recv.wait); :D
04:50karolherbst: seems like it wasn't that :/
04:52karolherbst: RSpliet: that's my current change: https://github.com/karolherbst/nouveau/commit/58096903386dabe10e9e7ebe9e68eac205ea1512
04:55karolherbst: wake_up isn't called at all, because nvkm_clk_pmu_reclk_request isn't returning
06:02karolherbst: mhh debugging symbols inside the nouveau module are helpful...
06:02karolherbst: RSpliet: it waits at this line: https://github.com/karolherbst/nouveau/blob/master_karol_no_touchy/drm/nouveau/nvkm/subdev/pmu/base.c#L82
06:03karolherbst: and it did stuff inside nvkm_memx_init
06:05karolherbst: RSpliet: do you know with call(send) is synchronues?
06:45karolherbst: it works
07:10karolherbst: how can I use a # inside a macro like #perf_reclk_last_gr
07:12imirkin: #define hash #
07:12imirkin: #define foo(bar) hash ## bar
07:15karolherbst: then I get hashperf_reclk_last_gr
07:15karolherbst: #define hash #
07:15karolherbst: #define common() ld(b8, $r14, hash ## perf_reclk_last_gr)
07:15karolherbst: ohh right, I also call a macro there :p
07:18karolherbst: imirkin: ohh ## merges both string as they are together
07:18karolherbst: hash don't get evaluated
07:32karolherbst: imirkin: the painfull part is, is that cpp is invoked twice and even when the first one finishes with #perf_reclk_last_gr, the second one will try to process that
07:37karolherbst: anyway, pmu side dynreclocking stuff is done I think, at least for core reclocking
07:39RSpliet: karolherbst: good stuff!
07:39imirkin: karolherbst: moral of the story - invoke cpp once :)
07:40karolherbst: RSpliet: I have to tweak it a little, because currently I have a desigb not involving any replies from the host
07:40imirkin: actually i dunno what #foo does if foo isn't a macro param
07:40karolherbst: which should work for like 95% of all cases, but there are some tricky ones
07:40imirkin: error: '#' is not followed by a macro parameter
07:40karolherbst: eg: if the target is 50% load
07:40karolherbst: and you request reclock at 60%
07:40karolherbst: you don't need a ack
07:41karolherbst: because if the load decreaes, the core was either reclocked or the load really went down, or maybe the load goes up (because there is more load and the host didn't reclock)
07:41karolherbst: then you request another one at 61% ore more
07:51RSpliet: karolherbst: what kind of control does the host have over the monitoring?
07:58karolherbst: RSpliet: none
07:58karolherbst: it is all set up on the pmu itself
08:00RSpliet: so what happens if the card is already at the highest perflvl? or the lowest? or both? :-D
08:01karolherbst: RSpliet: the pmu will only send another request when the current load either goes further away from the target or is growing into reverse direction. if target is 50%, last request was made at 70%, and current load is 44%, the pmu will request a reclock
08:01RSpliet: you might want to think about keeping host in control, and let nouveau send a message to "arm" it (with a lower bound and a higher bound) instead
08:01karolherbst: there is a saftey margin of 5% though, so between 45% and 55% the pmu won't send anything
08:02karolherbst: I think we will know those bounds at compile time already
08:02karolherbst: so we can just share constants between host and the pmu code
08:03karolherbst: I still have to decide to which p/c-state to clock on the host
08:03RSpliet: risking to bikeshed here, my opinion:
08:03RSpliet: the bounds are tweakable, and you might want to vary them between the various perflvls (it's not a linear perf increase)
08:04RSpliet: whereas the overhead of adding the bounds to the message are negligible :-)
08:04RSpliet: the more important bit though is that it would be nice to disable the "lower bound" interrupts if you're already in the lowest perflvl
08:04RSpliet: and the "higher bound" interrupts when you're all the way up
08:05RSpliet: they just needlessly interrupt the system, even if you have a clever heuristic to only do it twice or three times :-)
08:05karolherbst: RSpliet: yeah I know, but I decided it isn't worth the effort much, because the pmu will only start sending reclock requests when teh load decreases a lot
08:05karolherbst: so it will do one or two requests more than necessary
08:06karolherbst: I mean we can improve it later anyway, I just try to find a really simply design, which can be simply improved later on
08:06karolherbst: currently it is basically two compares and some ld/st stuff
08:07RSpliet: I'll just leave you play with it then ;-)
08:08RSpliet: if it doesn't have too many corner cases that could lead to many interrupts I guess it's a good start :-)
08:08karolherbst: this is basically the change
08:08RSpliet: mmm, not going to read it just now
08:08RSpliet: still at work
08:31dcomp: [ 1.484295] nouveau 0000:07:00.0: enabling device (0006 -> 0007)
08:31dcomp: [ 1.550054] nouveau ![ DEVICE][0000:07:00.0] unknown Maxwell chipset
08:31dcomp: [ 1.550060] nouveau E[ DEVICE][0000:07:00.0] unknown chipset, 0x118010a2
08:31dcomp: [ 1.550064] nouveau E[ DRM] failed to create 0x00000080, -22
08:31dcomp: [ 1.550259] nouveau: probe of 0000:07:00.0 failed with error -22
08:31dcomp: Anything I can do?
08:33imirkin: dcomp: search bugs.freedesktop.org for NV118 and look at the suggestions within
08:34imirkin: dcomp: basically copy the gm107 handling for gm108 and live happily ever after
08:35imirkin: (except not so happily, since maxwell has lots of issues)
08:45karolherbst: RSpliet: I just hope the kernel code is fast enough to handle three or more reclock requests every 0.1 seconds. I had some dead locks while reclocking that fast through the pstate interface I think
09:00RSpliet: karolherbst: so many reclocks are undesirable
09:00karolherbst: RSpliet: I know
09:01karolherbst: but we will get two within 0.1 seconds sometimes
09:01karolherbst: imagine the host decides to clock down after a request and then there is a spike load and has to upclock the very 0.1 seconds later
09:01karolherbst: *load spike
09:02RSpliet: just don't trigger events while reclocking, that's a bit pointless
09:02karolherbst: I already want to skip sending reclock requests for about 5 seconds after the the load drops below the target, just to catch unstable loads
09:03RSpliet: I'd imagine load drops during clock change because PFIFO is paused
09:03karolherbst: RSpliet: not noticable
09:04karolherbst: RSpliet: the load can even go higher even with reclocking within this 0.1 seconds period
09:04RSpliet: even if it doesn't, you don't want to send an interrupt while the kernel is busy changing clocks ;-)
09:04karolherbst: I know
09:05karolherbst: it is done inside a worker anyway and this is mutex locked already
09:05karolherbst: but still there is an issue somewhere there I think
09:08karolherbst: what means fifo: LB_ERROR by the way?
10:04karolherbst: imirkin: I get some FB_FLUSH_TIMEOUT and LB_ERROR, how _serious_ are those errors?
10:06RSpliet: karolherbst: I think FB_FLUSH_TIMEOUT is quite serious
14:51Flyoc: is nouveau video hardware decoding supposed to work with sid ? I get a "[vo/opengl/vaapi] vaDeriveImage(): operation failed" when I try to use it with mpv
14:52imirkin: Flyoc: http://nouveau.freedesktop.org/wiki/VideoAcceleration/
14:53Flyoc: imirkin: yeah I've read that a few times now
14:53Flyoc: extracted the firmwares
14:53imirkin: Flyoc: pastebin vdpauinfo
14:55Flyoc: imirkin: http://pastebin.ubuntu.com/13232547/
14:56imirkin: great, looks like you're all set then.
14:56imirkin: did you try the mplayer command on the page?
14:56Flyoc: imirkin: hmm actually, what does "width" and "height" mean in there ?
14:56imirkin: max width/height of video
14:56skeggsb: vinceh: yes, gr objects need a channel as a parent
14:57skeggsb: vinceh: i'll likely push an attempt at using the zbc methods in nouveau's userspace shortly, i've been preparing our userspace to be able to use those interfaces recently
14:57Flyoc: imirkin: I have not, I'm trying to make it work with mpv
14:57imirkin: Flyoc: mplayer works, everything else is kinda meh.
14:59imirkin: Flyoc: from your message it looks like you're trying to use vaapi? that won't work without that vdpau <-> vaapi converter dealie
14:59imirkin: which you may or may not have installed, dunno. seems like a huge waste.
14:59imirkin: also doing opengl + vdpau at the same time is going to end poorly.
14:59imirkin: just use mplayer and all will be well.
15:00Flyoc: imirkin: I just ran the mplayer command from the page, my video is hw decoded but it's slow. It's "only" 1080p though
15:00Flyoc: imirkin: I would have expected hw decoding to be faster that sw decoding ?
15:01imirkin: what gpu?
15:01Flyoc: imirkin: GeForce GTX 560 Ti
15:01imirkin: what freq does it boot up at?
15:01imirkin: pastebin your dmesg
15:03Flyoc: imirkin: is http://pastebin.ubuntu.com/13232628/ enough ?
15:04imirkin: yeah. so i guess 50mhz ain't enough :)
15:04imirkin: the -- line is the current level
15:04imirkin: i bet your cpu speed is higher :p
15:05imirkin: engine speed reclocking might actually work on fermi... dunno. you'd have to hack the code a bit to allow that.
15:05imirkin: memory reclocking def doesn't, but you might be able to get away without changing memclock speeds
15:05imirkin: definitely not an "out of the box" situation though, sorry!
15:06Flyoc: imirkin: should I boot with nouveau.pstate=1 ?
15:06imirkin: won't help
15:07imirkin: you can change the clk code to allow reclocks
15:07imirkin: while disabling memory reclocks
15:07imirkin: and hope for the best :)
15:08Flyoc: imirkin: where is that tweaked ?
15:08imirkin: mmmm.... sorry, don't quite remember.
15:08imirkin: grep for NvMemExec?
15:08imirkin: it's been a while since i've looked at it.
15:08imirkin: i think ben's rewritten all of it at least twice since then, so my info may be out of date :)
15:10Flyoc: https://wiki.freedesktop.org/nouveau/KernelModuleParameters/ imirkin
15:10imirkin: i wrote that page :p
15:10Flyoc: "NvClkMode: Force a particular clock level on boot. Note that this does not parse hex, so for clock mode f, pass in 15."
15:11Flyoc: so I guess just tweak NvClkMode ?
15:11imirkin: when i say you have to modify code, you can trust me
15:11imirkin: pretty sure that won't do anything but generate an error on load about not being able to switch states.
15:14Flyoc: imirkin: can I damage my card ?
15:14imirkin: probably. i've never heard reports of the gpu being damaged as a result of futzing with reclocking though.
15:15Flyoc: I'll give 07 a try.
15:20Flyoc: well, that didn't do anything
15:40Flyoc: thanks imirkin for your help ! I guess I just have to wait
15:44imirkin: probably for the best... unfortunately nouveau h264 decoding is slightly buggy
17:27vinceh: skeggsb: good to know that. what's the userspace btw?
17:28vinceh: skeggsb: do you mean you have some ideas to solve the dependency problem? if yes, could you please show me how briefly? :)