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