00:28 pmoreau: Wow! Even after your closing bugs pass there are still so many lefts? O.O
00:28 pmoreau: I thought we were somewhere around 200 opened bugs before the closing pass…
00:31 imirkin_: yeah you wish
00:31 imirkin_: 271 in Driver/nouveau alone right now
00:36 pmoreau: Oh! I had Mesa as well!
00:37 pmoreau: Which totals to 325
00:45 imirkin_: yeah
00:45 imirkin_: not pretty.
00:45 pmoreau: No :/
00:45 pmoreau: And not that many left that are more than one year old. :D
00:45 imirkin_: my hope is that i'll be able to close a bunch of the reports i pinged
00:46 imirkin_: errr... dunno. i have a ton here
00:46 imirkin_: about 1/3rd of the Driver/nouveau ones
00:46 pmoreau: Oh right, I just can properly look properly at where my scroll slider is… --"
00:47 pmoreau: s/can/can't
01:10 careym: mwk: just a heads up that http://reblog.0x04.net/ is giving out nginx "502 Bade Gateway" here in NZ
01:12 imirkin_: *great* -- someone broke edgeflags on nvc0 =/
01:13 imirkin_: if someone wants to bisect mesa to see when 'bin/gl-2.0-edgeflag -auto -fbo' started failing, that'd be useful
01:13 imirkin_: it was passing on a checkout from 9/28
01:15 mwk: careym: thanks for the info, looking into it
01:16 imirkin_: errrrr... hrmph. it might be something more subtle. looks like it fails with a pretty old mesa as well.
01:17 mwk: careym: fixed
01:18 imirkin_: ... but it passes with gbm?? wtf.
01:18 mwk: seems uwsgi just stopped responding to requests for no good reason
01:19 careym: thank you appreciate your work!
01:19 mwk: should've stayed with wordpress, no application server, no problems
01:27 vinceh: Hello nouveau experts, I have a question about the init order in core/device.h
01:27 vinceh: Is there any reason that the clk subdev must be inited after mmu/ltc/pmu?
01:28 vinceh: I'm not familiar with the dependency in dGPU, so please forgive me if the question is too stupid :)
01:31 mwk: vinceh: I'd guess you need PMU to manage the clocks
01:31 mwk: and MMU to start the PMU
01:32 vinceh: mwk: I recall I was told the clock of dGPU depends on the PMU, so that's true?
01:33 vinceh: I know PMU depends on MMU btw
01:36 mwk: vinceh: I don't think the clock itself depends the PMU, but you need the PMU to properly pause stuff to change memory clock safely
01:37 mwk: ie. you can change clocks without PMU, as long as no other device is running
01:44 vinceh: mwk: Oh, could you point me where is the code? :)
01:59 mwk: vinceh: not really, I haven't looked at the implementation
02:02 vinceh: mwk: thanks! I will try to figure that out
02:04 mupuf: vinceh: good to see you back :)
02:13 vinceh: mupuf: Hello Martin :)
02:13 mupuf: :)
02:13 vinceh: I should ask questions more frequently here :)
02:13 mupuf: as in, you are tasked with working more on nouveau or just that you do not usually dare?
02:14 vinceh: the later :P
02:15 mupuf: hehe, well, don't hesitate
02:16 mupuf: as for your question, I guess the general rule would be for us to initialize stuff as late as possible
02:16 mupuf: but clock should probably be moved much earlier
02:16 vinceh: yeah, that could speed up the init procees, isn't it?
02:16 mupuf: especially on tesla desktop gpus where there is only one reclocking happening at boot time (and it is easier when nothing is running)
02:17 mupuf: because we would reclock the bus clock?
02:17 mupuf: I doubt this would change anything, but I never profiled our boot time
02:17 mupuf: that could be an interesting thing to do
02:17 mupuf: I expect the slow part to be the probing for i2c sensors
02:17 vinceh: not for the GR init?
02:18 mupuf: uploading the golden context may take time indeed, but the bus would be the liniting factor I would guess
02:19 mupuf: we do not reclock the gpu at boot time anyway so there should not be any dependencies as far as I know of
02:19 vinceh: got it. I should learn more about how to think the dGPU way actually
02:19 vinceh: because there are a lot missing in tegra
02:19 mupuf:fails to see how it is different on tegra
02:19 mupuf: except you have no PCIe bus
02:19 mupuf: and you get your data from the DT
02:19 vinceh: no
02:19 vinceh: and no I2C
02:19 mupuf: that too
02:19 mupuf: wait a sec!
02:19 mupuf: sure about that?
02:20 vinceh: no memory reclocking
02:20 RSpliet: in fact, no memory at all :-P
02:20 vinceh: yes, we have emc scaling intead
02:20 mupuf: yeah, the memory reclocking is nothing new to us, nvidia used to make chipsets
02:20 mupuf: like the nvidia ion
02:20 mupuf: no vram there either
02:20 mupuf: the new thing was the platform bus
02:21 RSpliet: there still are a few PFB bits scattered around on ION from my recollection
02:21 mupuf:added support for it in envytools btw
02:21 RSpliet: probably bandwidth-related tweakables
02:21 mupuf: I need to rework it a bit and push it
02:21 mwk: mupuf: is it merged yet?
02:21 mupuf: nope
02:21 mwk: good, good :)
02:21 mupuf: I will whitelist gpus
02:21 mwk: I don't suppose we have a pre-K1 Tegra around to test on?
02:21 mupuf: nope, tagr would
02:22 mupuf: and I may simplify the code because the bus address is always the same for all the tegra platforms
02:22 mupuf: so I could just use the modalias as a check
02:22 mupuf: to see if the gpu is supported or not
02:22 RSpliet: mupuf, mwk: would lynxeye have a pre-K1 to play with?
02:22 mupuf: then we will need to check with a non-upstream kernel
02:22 mupuf: oh, sure
02:23 mupuf: tegra 2 and 3 should be within his reach
02:23 mupuf: not sure about tegra 4
02:37 tagr_: mupuf: why would you even want to bother checking envytools on anything pre-K1?
02:37 mwk: tagr_: to tell apart a K1 from a pre-K1
02:38 mwk: right now it tries to attach to anything with "nvidia" in its name
02:38 tagr_: what's "name"?
02:39 mwk: umm, one of the sysfs files
02:39 mwk: not sure which
02:43 mupuf: tagr_: I check the modalias
02:43 mupuf: tagr_: maybe one day, someone will want to have a look at those, but right now, I want to make sure I do not run on those
02:43 tagr_: mupuf: but there's no "GPU" device on pre-K1
02:45 mupuf: oh, great!
02:45 tagr_: there is gr3d, which is probably the closest
02:46 mupuf: I should have a look at some device trees for older hw
02:46 mupuf: but if there is no gpu entry, I guess my code will avoid it already
02:47 mupuf: which means I just need to rework the code a little before pushing it
02:47 mupuf:wanted to do it last week end but ended up working on environment dumping for our reclocking policy testing effort
02:48 tagr_: mupuf: yeah, the code I looked at last week shouldn't find any matches on pre-K1
02:48 mupuf: perfect, thanks for the info
02:49 mupuf: I wonder if it will work on the tegra kernel though
02:49 mupuf: but meh, if it does not work on it, we'll write another patch
02:50 tagr_: what are the requirements?
02:50 mupuf: the device tree should contain the word gpu
02:50 mupuf: and the modalias should contain nvidia
02:50 mupuf: \that's it
02:51 tagr_: why wouldn't that work on the Tegra kernel?
02:51 tagr_: oh, perhaps you mean the downstream kernel?
02:53 tagr_: the downstream kernel is missing the unit-address, the node is simply called "gpu"
02:53 karolherbst: mupuf: any objections about patches adding pdaemon counter support for gt215+ and exposing current loads through debugfs?
02:54 mupuf: no objections if you don't mind rewriting the interface later
02:54 mupuf: the pmu interface
02:55 karolherbst: yeah, I don't mind
02:55 karolherbst: it is just one function + a struct
02:55 karolherbst: https://github.com/karolherbst/nouveau/commit/963e93baf8f4b0547aa5501cef09bd5de79f80f0#diff-9cbb8760502a5191362f3e70d6853aea
02:55 mupuf: I doubt it iwll be that simple later on
02:55 karolherbst: depends on what we want to do with that
02:56 karolherbst: do we want to use then for anything else besides load?
02:56 mupuf: no
02:56 mupuf: I meant the pmu interface
02:56 mupuf: but hey, remember that the polling needs to be done consistently
02:56 mupuf: so, do not wait on the kernel space to ask for it
02:56 mupuf: you should return immediatly
02:56 karolherbst: this function doesn't poll the counters
02:57 mupuf: AKA, return the latest read out
02:57 karolherbst: the falcon triggers the host to save the current counters
02:57 karolherbst: yes
02:57 karolherbst: but yeah, the values might change while reading them :/
02:58 karolherbst: ohh wait
02:58 karolherbst: I do ask the falcon in my current implementation :/
02:58 karolherbst: I thought I already changed that
02:59 mupuf: ah ah
02:59 mupuf: pdaemon should have a loop polling the counters everything 100ms
03:00 mupuf: every*
03:00 mupuf: and the host should be able to query the counters
03:00 mupuf: on demand
03:00 karolherbst: ohh wait, right I cache the values on the falcon
03:00 mupuf: if you want to implement dyn reclocking, you need to implement the decision there
03:00 mupuf: I already told you how I see it should be done
03:01 mupuf: but I am open for suggestions, of course!
03:01 karolherbst: yeah, I just want to keep as much as possible on the falcon for that :/
03:01 karolherbst: especially for laptops this is quite important
03:02 karolherbst: and if we find a way to reduce wakeups on the host, we should use that then
05:42 karolherbst: mupuf: currently I try to think off a good API between the host and the falcon to fetch those counter values. I think it doesn't make much sense to send the counter values to the host, but rather counter/ticks ratio (between 0 and 255). That way we could read all with a single read from the pmu
05:42 karolherbst: somehow I don't want to make 8 reads in total :/
05:44 karolherbst: mupuf: in the end we should have one slot used per clock domain (somewhat, on tesla we have only 3 slots (1 for ticks), so there we need 2 slots for all domains) + memory (dedicated slot)
05:47 karolherbst: what is nv_clk_src_daemon, pdaemon?
05:48 karolherbst: mhh, then we only need a slot for a domain, which actually is changed through p/cstate
05:55 karolherbst: mupuf: by the way, the blob uses higher clock values for hub07, rop and hub06 then stated in the vbios
07:07 mupuf: karolherbst: good to know for hub7, rop and 6!
07:07 mupuf: I think polling all the counters in one go is a good idea
07:21 karolherbst: mupuf: okay, how much data can I get with one call?
07:21 karolherbst: 2x 32bit?
07:21 karolherbst: or more
07:23 mupuf: can't remember how command submission works upstream
07:23 mupuf: I made a system that had unlimited arguments and return values (to some degree)
07:24 karolherbst: currently I do it through this *_recv thingy
07:24 karolherbst: and call(send)
07:25 mupuf: sounds about right
07:25 mupuf: but as I said, no idea if this is the right hting
07:25 karolherbst: yeah I know, it already works and stuff
07:26 mupuf: 64 bits would be enough
07:26 karolherbst: send has a message and two message data arguments
07:26 karolherbst: so it is kind of 64bit
07:26 mupuf: it is
07:26 mupuf: this will do for now I guess
07:27 karolherbst: yeah
07:42 karolherbst: mupuf: rop seems to be the freq stated in the cstates though
07:42 karolherbst: have to check nouveau later
07:44 karolherbst: mupuf: and any idea how nouveau should handly clocks lower the cstates, but for ranges states in the boost table?
07:44 karolherbst: mhh, when I think about that, would the power consumption be lower with same voltage but lower clocks?
07:45 karolherbst: at full idle
11:29 imirkin_: glennk: in case you were curious, this is how blob does edgeflags: http://hastebin.com/pabesosija.m
11:30 glennk: question though does it do that on quadros too?
11:30 imirkin_: don't have a quadro but i can only assume so
11:31 imirkin_: actually i do have a quadro... my nv42 :) but too painful to get blob to run on it
11:32 imirkin_: (i also have some of the fake-o quadros, i assume they wouldn't get actual special treatment)
11:32 imirkin_: like quadro nvs-type stuff
11:33 imirkin_: there aren't exactly a *ton* of places to hide that functionality
11:59 pmoreau: How does headergen work?
12:00 pmoreau:would like to re-generate the headers for NV50 compute
12:01 pmoreau: I tried `headergen nv_mmio.xml` to test, but nothing happened.
12:03 imirkin_: heh
12:03 imirkin_: it's actually a huge pain
12:03 imirkin_: esp since someone renamed NV50 to G80
12:04 imirkin_: you have to feed it the right files... i forget exactly but i've used it to regenerate the nv50/nvc0 3d stuff
12:04 mlankhorst: it's probably in the headers themself
12:04 pmoreau: Using the rules-ng-ng.txt file?
12:05 pmoreau: mlankhorst: Oh, you're right! :o
12:05 imirkin_: pmoreau: s/G80/NV50/ afterwards
12:06 pmoreau: Right
12:09 pmoreau: Meh, need some more testing to get the correct data out of it
12:21 pmoreau: Ah, ok. Even though multiple files were used for the generation, you only need to specify one, the one you want a generated header for.
12:48 karolherbst:
12:49 imirkin_: karolherbst: is this still a thing? https://bugs.freedesktop.org/show_bug.cgi?id=91310
12:49 karolherbst: imirkin_: not with the gog version
12:49 karolherbst: but the steam version :/
12:49 karolherbst: I really suspect an engine thing, but well :/
12:49 imirkin_: karolherbst: you've retested with recent-ish git?
12:50 karolherbst: no, I can today if you want
12:50 imirkin_: have you in the past couple of weeks?
12:50 imirkin_: as i was landing all my buffer management and fence changes
12:50 karolherbst: no
12:50 imirkin_: ok, would be nice if you could retest then
12:52 karolherbst: imirkin_: wanna a mesa ebuild with the possiblity to disable nouveau_vieux? :D
12:52 imirkin_: not really... i plug old gpu's into my box every so often
12:52 karolherbst: ohh okay
12:53 karolherbst: I kind of added support for all stuff of things, disabling classic/gallium swrast, stuff
12:57 karolherbst: imirkin_: have to verify the steam files first :/ this might take a while
12:57 imirkin_: no worries
13:08 karolherbst: imirkin_: what about the metro issue though? (the out of memory issue in the kernel)
13:08 imirkin_: what about it?
13:09 karolherbst: anything I could help with that?
13:09 imirkin_: yeah, you could figure out what's going on
13:27 karolherbst: imirkin_: there is still flickering :/
13:27 imirkin_: karolherbst: that's on witcher2?
13:27 karolherbst: wait, this didn't happen before :/
13:27 imirkin_: mind updating the bug with the stack you're using?
13:30 karolherbst: mhhh
13:31 karolherbst: imirkin_: what do you want to know there?
13:31 imirkin_: kernel + mesa
13:32 karolherbst: well kernel :/ there I use my custom branch currently. Somehow it's bens first cleanup version + some stuff of mine
13:33 karolherbst: but I have a new nice screenshot
13:34 karolherbst: I added it on the bug with the info about mesa
13:34 karolherbst: strange is, that it only happens from some view directions and not with all objects
13:34 imirkin_: anything in dmesg?
13:34 karolherbst: I really think this is an engine issue, because the gog version of that game works without any issue
13:34 karolherbst: s
13:35 karolherbst: nothing
13:35 karolherbst: only my CPU cores being too hot :D
13:35 karolherbst: I will check if that happens with the blob though
13:37 karolherbst: ohh nice, with the blob it crashes
13:38 imirkin_: heh
13:39 karolherbst: yeah, forget about the bug, this version is just not playable
13:39 karolherbst: will try out the non beta brnach once with the blob though
14:28 needspeed: I am quite confused. Is it a known fact that nouveau doesn't support 3840x2160 over HDMI?
14:28 imirkin_: it is.
14:28 imirkin_: nouveau (incorrectly) limits hdmi to 165MHz pixel clocks
14:30 needspeed: Yeah read something about this. As someone not that well educated about the field: I ask myself how hard it would be to change that.
14:31 imirkin_: very easy
14:31 imirkin_: we just don't know what the correct upper limit is for any particular card
14:31 imirkin_: needspeed: see http://lists.freedesktop.org/archives/nouveau/2015-August/021841.html and http://lists.freedesktop.org/archives/nouveau/2015-August/021839.html
14:32 imirkin_: it's wrong though -- at least some fermi's support 297MHz and i'm pretty sure all keplers do too
14:33 needspeed: Oh wow thanks. I think I'll get myself a bit familiar with the code. Maybe I'll get it to work myself.
14:33 imirkin_: just apply those patches and replace 225 with 297
14:33 imirkin_: what gpu do you have?
14:35 needspeed: NV108 (GK208)
14:36 imirkin_: ok. well i have a GK208 and i'm pretty sure my max is 297MHz, so in that second patch, just replace 225000 with 297000
14:36 imirkin_: which should get you 3840x2160@30
14:36 needspeed: nice. gonna try it
14:37 imirkin_: actually might have to be @24
14:38 imirkin_: or some sort of reduced-blanking mode
14:38 imirkin_: which cvt is refusing to spit out =/
15:55 danofsatx: Greetings. I'm being affected by http://bugs.freedesktop.org/show_bug.cgi?id=92504 and was able to get some extra information about it today. This was spewed into the console window where I had manually restarted plasmashell earlier, these errors are from when the system returned from sleep: http://fpaste.org/282718/
15:57 imirkin_: danofsatx: did you apply the kernel patch that fixes the issue for other people?
15:58 imirkin_: [wow, that's a lot of buffers... feels like there's a bufctx leak somewhere =/ ]
15:58 danofsatx: no, I don't know how to do that :(
15:59 imirkin_: danofsatx: then you need to wait until there's a kernel release that includes my patch... 4.3-rc7 should have it
15:59 imirkin_: danofsatx: this is the patch: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=2a6c521bb41ce862e43db46f52e7681d33e8d771
15:59 danofsatx: the video card has 2GB of memory on it - could that explain the amount of buffers?
15:59 imirkin_: no
16:00 imirkin_: i guess it could be from a ton of draws using diff resources? anyways, not a problem in and of itself
16:00 danofsatx: yeah, I saw that in the report today. I've figured out a temporary workaround - plasmashell and Chrome are the only two applications that affect it. I simply restart those two programs and continue on my way.
16:00 imirkin_: hehe
16:00 imirkin_: problem solved ;)
16:01 danofsatx: heh
16:51 needspeed: @imirkin_ the patch did work for me (just had to change it to gf119.c in patch1)
16:52 needspeed: thanks a lot!
16:53 imirkin_: great