07:58karolherbst: skeggsb: saw that "fb: 0 MiB DDR3" bug comming up on a few machines?
10:33RSpliet: karolherbst: a few patches have disappeared from the tip of Bens tree. One I recall being related to detecting the correct amount of DRAM
10:34karolherbst: RSpliet: yeah... I kind of remember that something happened regarding this, but I forgot all the details
11:49karolherbst: does anybody have access to a gm108 and could create an mmiotrace for me?
13:40dboyan: hakzsam: I came up with a dirty hack to fix percentage values for AMD_perfmon in nouveau.
13:40dboyan: hakzsam: https://hastebin.com/asajajivup.cs
13:41dboyan: hakzsam: I don't think it'll break hud, but the code is not that clean for now.
13:41tagr: RSpliet: no disagreement here =)
21:11Lyude: mupuf: alright, looking at the clockgating stuff again. It looks like all that was really left to do was testing, am I correct? (don't see any responses to my v3 patch
21:11mupuf: oh, so sorry I missed your v3!
21:12karolherbst: there was a v3? :/
21:12mupuf: where the heck did you send it "D?
21:12Lyude: i can resend if you want
21:12karolherbst: I think it got lost
21:12karolherbst: I don't see it on the list
21:12mupuf: yeah, I can't see it either
21:13mupuf: I don't even see the v2
21:13Lyude: alright, lemme rebase it and i'll resend in a bit
21:13karolherbst: mupuf: true
21:14mupuf: ah! It was in my ri-devel folder
21:15karolherbst: mupuf: was the nouveau list in CC or anything?
21:15Lyude: ah cool, so we're good? (shouldn't need a rebase, since it rebased cleanly here
21:15karolherbst: mupuf: super odd
21:15karolherbst: mupuf: date?
21:16karolherbst: now I see it
21:16mupuf: Lyude: you forgot about setting all the SLPC and ELCG regs
21:17mupuf: there are quite a few of them
21:17Lyude: mupuf: huh, alright
21:17karolherbst: ohh right those
21:20karolherbst: Lyude: that "if (!ret) nvkm_therm_clkgate_" part is a bit tricky... I wouldn't like to see it depending on the return code really. Usually !ret means something is wrong and we shouldn't continue by enabling more stuff
21:20karolherbst: let me read the entire source though
21:21karolherbst: ohh. I am silly
21:22karolherbst: I shouldn't do reviews when I am super tired
21:33Lyude: btw mupuf, where are the rnndb entries for the registers you're talking about?
21:36mupuf: BLCG and SLCG
21:36mupuf: that's the names I was looking for
21:36karolherbst: Lyude: now a real comment: if the clkgate.c file won't get bigger with the adjustments mupuf mentioned, you could just put nvkm_therm_clkgate_engine into base.c
21:37Lyude: yeah, I was thinking that
21:37Lyude: such a small lonely file
21:37mupuf: karolherbst: it won't, what I am talking about is a one-time write and should be part of the engine/subdev init
21:37karolherbst: yeah, most likely
21:37mupuf: Lyude: https://android.googlesource.com/kernel/tegra/+/b445e5296764d18861a6450f6851f25b9ca59dee/drivers/video/tegra/host/gk20a/hw_gr_gk20a.h may contain information about these regs BTW
21:38mupuf: Lyude: take mmiotraces from the vbios repo, compare them
21:38mupuf: and make the same writes
21:38karolherbst: Lyude: usuall we put such dispatch calls always into base.c even if there is more real stuff later one
21:38karolherbst: and usually also do pointer checks
21:38Lyude: holy crap what is with all of these inline functions
21:38karolherbst: if (therm && therm->func->clkgate_engine)
21:39mupuf: Lyude: isn't life amazing? :D
21:39karolherbst: Lyude: it's called from outside therm, so therm could be NULL actually
21:39Lyude: mupuf: this is tegra e.g. not nouveau right
21:39mupuf: Lyude: of course :D
21:39karolherbst: yes, those are fun
21:39Lyude: god damn i didn't realize nvidia was that bad
21:39mupuf: It is nvgpu
21:39Lyude: amd has some competition in that field it seems
21:39karolherbst: I think this is generated code?
21:39Lyude: ooh, that would make more sense
21:40karolherbst: yeah, AMD is like 90% headers and 10% source :D
21:40Lyude: ehhhh, i dunno about that one. there's a -lot- of source
21:40Lyude: it's just, not good source
21:40mupuf: ah ah
21:40mupuf: of course it is auto-generated :D
21:40Lyude: i have more irq cleanups for cik and r600 on the way and i think i probably removed another 1000 lines from their driver
21:40mupuf: _f == field
21:40karolherbst: well, maybe it'S 10% after removing all that duplicated code?
21:40mupuf: _v == default value
21:41Lyude: karolherbst: yeah that sounds about right :P
21:41karolherbst: allthough that was a pure guess, is there a lot of duplicated code? :D
21:41Lyude: oh my god yes there is
21:43Lyude: karolherbst: if you are curious how much duplicated code btw, just look at some of the diffs for the commits from here https://github.com/Lyude/linux/tree/wip/radeon-cik-irq-cleanup-v1
21:47karolherbst: oh crap
21:49Lyude: yeah, it's -bad-
21:53karolherbst: I hope we get access to Dawn of War fast, so that I can try it out :)
22:06karolherbst: I get notification spamming from the PMU
22:07karolherbst: when I set min/max thresholds and have something running at full load, I can't really tell the PMU to say: please don't notify the host on high loads anymore
22:07karolherbst: I also need to add some kind of order, like if one domain is between min/max and everything is below min, there is no point in poking the host to reclock as well
22:08karolherbst: I think I already solved that problem with my old PMU code
22:09karolherbst: mupuf: by the way, do you mind taking a look at my most recent pmu counter series?
22:10mupuf: karolherbst: yes, you did solve this before: send one IRQ and nothing else until it gets acked
22:10karolherbst: no, it's a different issue
22:10karolherbst: after the PMU pokes the host, it sets max to 0xff and min to 0x0, so it won't send anything, but I was always acking now... I was talking about a different issue though
22:11karolherbst: but basically I know now how to fix it
22:12karolherbst: I make the thresholds 16 bit so that I can set max to 0x100
22:13karolherbst: and max gets set to 0x100 if the domain has the highest clock, min to 0x0 on lowest clock
22:13karolherbst: and if one domain is between min/max and every other below min, the host won't get poked, because there is no reason to
22:14karolherbst: notifications only when at least one domain is above max or every domain is below min
22:16mupuf: hmm, but how does this work with the cstate then?
22:16karolherbst: what do you mean?
22:17mupuf: you never lower the cstate when it is too high, unless all the other domains are below min?
22:19karolherbst: mupuf: imagine that video engines are also clocked by cstates or something else. Then you would have it always at load 0x0, but if the GPU renders something, the core domain is always up
22:20karolherbst: so the PMU would spam with IRQs, because the video engines could be downclocked
22:20mupuf: no, vdec engines are not part of the cstate
22:20mupuf: there is only one clock, dude ;)
22:20karolherbst: yeah I know, but those are still at 0 load
22:20mupuf: sure, and?
22:20karolherbst: and we can't really downclock pstates either if we have to set high cstates
22:21karolherbst: and if I set the core domain to min 0x70 and max 0x100, the load varies between 0xe0-0xf0 and video at 0x0, should the PMU send IRQs?
22:22mupuf: dude, can you first tell what these number mean :D?
22:22karolherbst: on some GPUs, highest cstates are only enabled on pstate 0xd+ and 0xa doesn't allow the most highest ones
22:22karolherbst: mupuf: loads are represtended between 0x0 and 0xff
22:22karolherbst: *as values
22:23karolherbst: min/max are simply thresholds when the PMU should poke the host, so if the load drops below min, it should notify the host about that
22:23mupuf: basically, for the core domain, only care about the cstate. You just change the pstate up and down based on the rest of the domains
22:23karolherbst: well, this won't work
22:23karolherbst: I need to care about pstates as well for core domain
22:23mupuf: basically: pstate = max(vdec.wanted_pstate, mem.wanted_pstate, core.wanted_pstate, etc...)
22:24mupuf: no, you don't. It just comes as a dependency of the cstate
22:24karolherbst: mhh, okay, true
22:24karolherbst: but this isn't the issue I am talking about though
22:24mupuf: you sure about that? :D
22:24karolherbst: the host side is not interesting here really
22:25karolherbst: I am more concerned about when the PMU should send IRQs
22:25mupuf: well, what you want is to let the PMU tell you when a reclock needs to happen
22:25karolherbst: but I also want to prevent IRQs spamming just because one domain has a load of 0
22:26karolherbst: so I need a way to tell the PMU from the host: don't bother to notify me, just because the video engines has nothing to do
22:26mupuf: remember what I wrote above
22:26mupuf: pstate = max(vdec.wanted_pstate, mem.wanted_pstate, core.wanted_pstate, etc...)
22:27karolherbst: yeah, the PMU doesn't know about the relationships
22:27mupuf: so, an irq should be fired when all the loads are low-enough
22:27mupuf: (well, aside from the cstate, let's keep it on the side for now)
22:27karolherbst: I need to be able to set some flags for the counter slots then
22:27karolherbst: from the host side
22:28mupuf: you need to be able to set the min thresholds of all counters, yes
22:28mupuf: and only when all are under, then you fire an irq
22:28karolherbst: this would be a good way
22:28mupuf: that will work for all the domains but the cstate
22:29mupuf: as for upclocking, any domain above a certain load needs to trigger an IRQ too
22:29mupuf: when you are at the highest, set the threshold to 0x100, like you already do
22:29mupuf: but there is one more thing missing from your code
22:29mupuf: downclocking should only happen if all domains are under a threshold for a certain time
22:30mupuf: you can't be downclocking at 10Hz
22:30karolherbst: I know, I was just rewriting all the code from scratch basically
22:30mupuf: but seriously, stop with the PMU for now and do it on the kernel side, if not in the userspace
22:30mupuf: make it work, then put it in the PMU
22:31karolherbst: what do you mean now? I don't really do anything on the PMU except checking the thresholds
22:31mupuf: do nothing there
22:31mupuf: prove your algorithm first
22:31mupuf: in the userspace
22:31karolherbst: well the PMU read out the counter slots
22:31mupuf: you don't have to do it there, you are just making it harder for you
22:31mupuf: and it is just a way to avoid doing the real work: coming up with good algorithms :D
22:33mupuf: with that being said, I will go to bed, and review your code when possible!
22:33karolherbst: the code doesn't contain any of that anyway
22:33karolherbst: it's just the part to provide the loads
22:33mupuf: I know :)
22:33mupuf: and that is nice
22:34karolherbst: yeah I guess I should just do more real research and concentrate on implementing late when I know what I need for sure
22:35karolherbst: good night
22:36mupuf: thanks, same to you!
22:36mupuf: I really need to get back to all this. So much fun (and frustration) to be had!
23:13pmoreau: Maybe we should have a Trello team, so that anyone in the team can access all the boards, without needing to add people manually to each board.
23:14pmoreau: Plus it would be easy to see all the team’s board without pinning/star'ing them all. :-)
23:14pmoreau: I had completely forgotten about that CTS board
23:24pmoreau: imirkin: I created a public Trello team and added you as an admin. Could you please change the CTS board from public to team, and pick the Nouveau team? If it works fine, and remains public, I’ll add everyone to the team and switch the main one to the team.
23:32pmoreau: imirkin: Looks like you can simply go to Settings -> Change Team and select Nouveau.
23:38imirkin: pmoreau: iirc that's a non-free feature...
23:38pmoreau: To have public boards in a team?
23:39imirkin: to have teams at all... i guess we'll see
23:39imirkin: anyways, changed
23:39pmoreau: Seems to work
23:40imirkin: maybe it's to have private + team
23:40pmoreau: Teams are free, but you have some limitations to them in that you can change many settings (https://trello.com/nouveau8/account)
23:40imirkin: i see
23:42imirkin: Lyude: in case you want to add more fun GM200+ features, ARB_location_samples should be *relatively* straightforward, but i suspect it's a lot of typing.
23:43Lyude: imirkin: sure, probably going to see if I can finish up clockgating first though
23:43pmoreau: I think I added everyone from the board to the team.
23:43imirkin: Lyude: whatever you like to work on. just pointing things out that are semi-similar to other things you did
23:43Lyude: ahh, cool
23:44imirkin: Lyude: i have no agenda here... it'd be nice to work on useful things, but fun things tend to rule the day
23:46imirkin: pmoreau: thanks for setting the team thing up - that's def a good idea.
23:47pmoreau: Cool, the URL of the boards did not change after adding it to the team! :-)
23:47imirkin: always a nice little bonus.
23:47pmoreau: imirkin: You are welcome! That way it will be easier to add someone to the boards, and track all the boards we create.
23:48imirkin: yeah. i think that the "nouveau" board has been getting a lot of unrelated lists, which perhaps make it harder to use
23:48pmoreau: I do not remember if Karol created a separate board for falcon… I’ll have to ask him tomorrow.
23:48pmoreau: True. On the other hand, I am not sure how I would split things up.
23:49pmoreau: One thing I would change, would be the "OpenGL compiler" list, to "NVIR compiler", or just compiler, as it applies to OpenCL and CUDA as well. :-)
23:51pmoreau: Maybe a board for the compiler which is shared across APIs, one for the kernel and another for the DDX, and then one for each graphic API?
23:51pmoreau: And if a card should be categorised as "compiler" rather than "OpenGL", it is very easy to move the card between boards without losing any information.
23:52imirkin: pmoreau: go for it
23:52imirkin: OpenGL compiler -> NVIR compiler
23:53imirkin: but yeah... some of this stuff can be reorganized a bit
23:53imirkin: the opengl was there more to differentiate it from, say, kernel
23:53imirkin: or dd
23:53pmoreau: imirkin: I think I’ll go for my bed first, let the night pass, see the reactions tomorrow morning, and then do something. ;-)
23:53pmoreau: Makes sense
23:58Lyude: btw mupuf, in that hw_gr_gk20a.h file you showed me do you have any idea what l1c is?
23:58skeggsb: level 1 cache, probably
23:58skeggsb: ltc == l2c == level 2 cache, so, that'd be my guess
23:59Lyude: oh yeah, that seems to make sense here