00:45 gnurou: anyone (skeggsb maybe?) knows why the check on CONFIG_SWIOTLB in nouveau_bo.c? I'd like to avoid that code path on ARM64, where CONFIG_SWIOTLB is also enabled and would like to understand in which circumstances it needs to be used
00:50 mupuf: hakzsam: any problem with me putting the maxwell gpus in?
00:50 mlankhorst: I guess it uses the ttm dma api directly, instead of manually..
00:52 mupuf: hakzsam; I removed the GK208
00:52 mupuf: and put the GM107
01:17 hakzsam: mupuf, too late :)
01:32 karolherbst: how does that GSOC stuff works anyway?
01:43 xexaxo: karolherbst: you will look for a project/mentor and fill in a proposal - people vote on it, once accepted you get to crack on it and get some $5500 (iirc) for ~three months work
01:44 karolherbst: yeah, but currently I am not a student, I was just curious on the support side, because I saw some messages about this on the ML
01:46 xexaxo: "support" side ?
01:48 karolherbst: yeah I mean I won't be a mentor or something, but how much is the community/devs allowed to help and stuff. I guess I should just read the rules there .D
01:49 xexaxo: pretty much anyone can help afaik. would that be ideas or code review
01:50 karolherbst: okay
01:50 karolherbst: yeah nice, because I really like the idea of adding support for nvenc in nouveau
01:50 karolherbst: this is something really usefull if you are cpu limited
02:27 mupuf: cool, wayland also got accepted
02:27 mupuf: otherwise, they would have been part of the xorg one anyway
02:35 pq: whee
02:50 mupuf: pq: congrats :)
02:50 mupuf: I published an article on g+ to announce that
02:51 pq: mupuf, thanks! We're brewing some announcements too.
02:52 mupuf: pq: you should recommend students to submit their proposals to both x.org and wayland
02:52 mupuf: and we will need to coordinate at the end
02:52 mupuf: if we have a shortage of slots
02:54 pq: mupuf, yes indeed, Kat told me that
02:59 karolherbst: I really like those nouveau projects, would have done those things myself if I wouldn't be cought up with other stuff
03:00 pq: yeah, making up project ideas for GSoC are often such things :-)
03:00 mupuf: karolherbst: you may still add some more
03:01 mupuf: I merely copy-pasted those projects from last year
03:01 karolherbst: good idea, but I think it is all covered I have on my todo list :/
03:01 mupuf: and got rid of one because it was not needed anymore
03:01 karolherbst: well I also have "pcie width changes" on my list, but meh :/
03:01 karolherbst: this is so minor
03:01 karolherbst: and unimportant
03:01 karolherbst: ahhh
03:01 karolherbst: power gating
03:01 karolherbst: of course
03:02 pq: and then qualification tasks that are trivial to regular devs, you have to fight the urge to just finish them yourself as low-hanging fruits ;-)
03:02 karolherbst: pcie width is really minor
03:02 karolherbst: it doesn't even work on most gpus
03:02 karolherbst: and then only on some tesla cards
03:02 RSpliet: karolherbst: doesn't mean the impact can't be big ;-)
03:02 karolherbst: I will care more if we have gpus booting at x1 width
03:03 karolherbst: RSpliet: find me a tesla gpu with working power sensor and is able to change pcie width, then we can messure :)
03:04 karolherbst: but I already kind of figured it out already, so it's more like puting the reg read/writes in nouveau and we are done with it
03:04 karolherbst: power gating would be a great projects though
03:05 RSpliet: karolherbst: for power sensors there's plenty of other solutions - like a WattsUp on the mains -, but lane width changes could improve max throughput?
03:05 karolherbst: on kepler+ it is trivial to clock gate the engines kind of, on pre-kepler it is more work
03:05 karolherbst: RSpliet: yeah, but all the gpus I found boot at max width by default
03:07 karolherbst: mupuf: https://gist.github.com/karolherbst/a40513aed64870462a54
03:08 RSpliet: karolherbst: I wouldn't bother with "older GPUs" personally
03:09 RSpliet: Tesla is already losing relevance rapidly
03:09 karolherbst: yeah I know :/
03:09 karolherbst: kepler+ would be good
03:10 karolherbst: I think for beginers working on kepler is easier anyway, because the mmio design seems to be much cleaner than before
03:10 karolherbst: for some parts at least
03:10 RSpliet: also: keep in mind there is at least one known hw bug - where BLCG on some GT21x under "conditions" causes the ctxswitch program to be erased or corrupted from it's memory - hence regularly the firmware needs to be re-uploaded if you enable it
03:11 karolherbst: and Fermi is also a mess
03:11 mupuf: RSpliet: :o, nice one
03:11 RSpliet: mupuf: explains the frequent uploads in trace - but don't ask me about the conditions that trigger it
03:11 karolherbst: clock gating on Kepler is kind of easy to enable though, but there is a lot more to it
03:11 mupuf: hehe
03:12 karolherbst: mupuf: also clock gating on your maxwell gpu: 9.5W => 8.0W
03:12 RSpliet: karolherbst: it's up to the student to propose the exact chunk of work they want to take on - you can merely do suggestions
03:12 mupuf: the GM206?
03:12 karolherbst: I think so
03:12 karolherbst: or the gm10x
03:12 mupuf: nope, the latter has no power sensor
03:12 karolherbst: mupuf: k, then gm206
03:12 mupuf: Yeah, we will need to go for the power efficiency when dyn reclocking is sort of done
03:12 mupuf: and boost is OK
03:13 karolherbst: well the clock gating stuff is pretty easy on kepler+
03:13 karolherbst: we can do this anytime we want
03:13 karolherbst: the blob also doesn't disable it
03:13 karolherbst: only on fermi it goes crazy
03:13 mupuf: ack
03:13 mupuf: I mostly investigated it on tesla + fermi and it was not trivial!
03:13 karolherbst: no
03:13 karolherbst: I got a headache.. .D
03:13 karolherbst: :D
03:14 karolherbst: it just looks so random
03:14 karolherbst: anyway, this would be my suggestion so far
03:15 RSpliet: think I pointed to it before, but take a look at the tegra android driver for how Kepler can be handled
03:15 RSpliet: that's a mere porting effort, not a reverse engineering job, I wouldn't say Kepler is 12 weeks of work
03:15 karolherbst: well I could also kind of help somebodea doing dynamic reclocking, but ... well there is a lot of ground work to do like getting the pmu rock solid
03:16 RSpliet: karolherbst; I've been thinking of documenting some sort of calling convention - and asserting whether every function adheres to it
03:16 karolherbst: RSpliet: that's not what I meant sadly. I meant more the pmu itself
03:16 RSpliet: karolherbst: let me finish
03:17 RSpliet: the fecs code has at least one bug where $r0 is not zero - and currently it's impossible to determine what causes it because there's no convention
03:17 RSpliet: being strict about this would help in verifying all the falcon code we have
03:17 karolherbst: ahh okay
03:17 karolherbst: I just now that having a really fast timer can easily lockup the pmu somewhere
03:18 karolherbst: with fast I mean below 10ms
03:19 RSpliet: yes... it's a pain spotting these bugs currently
03:19 RSpliet: calling conventions help
03:20 karolherbst: anyway, did you now that the pmu fuc5 is kind of brocken?
03:21 karolherbst: maybe I messed around with mupufs gk20x too much, but the pmu just didn't work as expected
03:21 karolherbst: and I somehow doubt that nobody noticed before
03:23 karolherbst: mupuf: will you have some time today to put in a maxwell gpu into reator? 1g prefered, but 2g should be also fine if the firmware is installed
03:23 mupuf: karolherbst: I already did
03:23 karolherbst: ahh awesome :)
03:23 mupuf: GM107
03:23 karolherbst: hakzsam: how long do you want to claim reator today?
03:24 karolherbst: mupuf: nice :) I want to give memory reclocking a shot, because it looks just like kepler
03:24 mupuf: well, that would be great!
03:24 karolherbst: yeah
03:24 karolherbst: I checked your mmiotrace with mine and it was like 90% identical
03:24 karolherbst: and most of the time just the reg values were different
03:25 karolherbst: it just looked like it was another kepler gpu
03:42 RSpliet: karolherbst: fwiw, most requests we get on the ML for GSoC applications simply require a referral to
03:42 RSpliet: [1] https://developers.google.com/open-source/gsoc/faq
03:42 RSpliet: [2] http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code/
03:42 RSpliet: those pages explain, amongst many things, the application process
04:33 karolherbst: !!!1
04:33 karolherbst: maxwell: 1115.894112 frames/sec - 1245.337829 Mpixels/sec glxspheres :)
04:33 karolherbst: it works
04:33 karolherbst: awesome
04:34 karolherbst: AC: core 1164 MHz memory 5100 MHz
04:35 karolherbst: soo, who has a maxwell and want to try full reclocking on it? :)
04:35 mupuf: karolherbst: how many changes did you make in the end?
04:35 mupuf: Just changing a few regs?
04:36 karolherbst: mhh my reclokcing stuff
04:36 karolherbst: and nothing else
04:36 mupuf: oh well :D
04:36 mupuf: congrats!
04:36 karolherbst: this branch: https://github.com/karolherbst/nouveau/commits/maxwell_reclocking
04:36 karolherbst: well the maxwell "fix" is this: https://github.com/karolherbst/nouveau/commit/fff4239440e78a0188e31e4509684977c48bb5a6
04:36 karolherbst: :)
04:36 mupuf: many changes I need to review :D
04:37 mupuf: But honestly, thanks a lot for all your work
04:37 karolherbst: yeah, there is also the volt stuff and everything
04:37 karolherbst: and the fuc5 pmu fixes
04:37 karolherbst: ohh I could try without them
04:37 mupuf: so, gm206 tonight? :D
04:37 karolherbst: yeah
04:39 karolherbst: k, without my pmu changes it hangs
04:40 karolherbst: so yeah, pmu on fuc5 is messed up
04:42 karolherbst: mhh
04:42 karolherbst: yeah those pmu changes seems important
04:42 karolherbst: only "318.611791 frames/sec - 355.570759 Mpixels/sec" with glxspheres now
04:42 karolherbst: allthough AC: core 1164 MHz memory 5100 MHz is shown
04:43 karolherbst: mupuf: so it would be really awesome if you review this: https://lists.freedesktop.org/archives/nouveau/2016-February/024166.html
04:44 karolherbst: when this gets merged, we can enable memory reclokcing on maxwell
04:44 mupuf: karolherbst: what do you mean, I thought I already R-Bed everything
04:44 mupuf: oh wait, no
04:44 mupuf: sorry
04:45 karolherbst: :)
04:45 mupuf: yes, I will check them out tonight
04:45 karolherbst: even reclokcing while glxspheres is running works
04:45 karolherbst: :)
04:45 karolherbst: awesome
04:47 karolherbst: there might be something wrong with the voltage though
04:47 karolherbst: I get 1.5V ...
04:48 karolherbst: but this is most likely my fault I guess
04:49 mupuf: 1.5 is ... impossible
04:49 karolherbst: hwmon reports that
04:50 karolherbst: it just calls nvkm_volt_get
04:51 karolherbst: I am sure it is my fault that the pwm is set to something really hight
04:52 karolherbst: still shouldn't happen, odd
04:52 mupuf: the max voltage is 1.2V
04:52 karolherbst: yeah, but the pwm can be set to something higher
04:52 karolherbst: I mean the reg
04:53 mupuf: lol, then it is a bug in your parsing
04:53 karolherbst: yeah, as I said, might be my fault
04:53 mupuf: duty = min(duty, div)
04:53 karolherbst: yeah, but let's leave it like that, so we know something is fishy
04:53 karolherbst: because we shouldn't set any voltage higher than max anyway
04:53 mupuf: a dmesg warning would be better :D
04:54 karolherbst: right
04:54 karolherbst: mhhhh
04:54 karolherbst: something doesn't feel right
04:56 karolherbst: why is 20344 0
04:56 karolherbst: ahh -c1
04:56 karolherbst: yep, 20344 gets 0x90
04:56 karolherbst: k, where does it come from
04:58 karolherbst: uhhhh
04:58 karolherbst: -- ID = 7, mode: 3 link: ff, voltage_min = 600000, voltage_max = 1500000 [µV] c0 2058 c1 0 c2 0 c3 0 c4 0 c5 0--
04:58 karolherbst: okay
04:58 karolherbst: mode3 doesn't mean voltage_max
04:58 karolherbst: this is the voltage entry for pstate 0xf
04:59 karolherbst: and currently I do min(pstate_vol, cstate_vol)
04:59 karolherbst: 1.07V, much better :)
05:00 karolherbst: yay, still runs :)
05:00 karolherbst: so my voltage stuff doesn't seem that bad then
05:00 karolherbst: except this mode 3 thing
05:02 mupuf: karolherbst: please check the voltage diff with the blob
05:02 mupuf: this is critical :s
05:02 karolherbst: I know, and it will be different
05:03 karolherbst: last time I checked on your maxwell it was 83% stock nouveau compared to 90% with my changes
05:03 karolherbst: ...
05:04 mupuf: see, I really hate < 100% here
05:05 mupuf: power efficiency should come *after* making sure that stuff works :)
05:08 pq: ..and doesn't go up in smoke? :-p
05:09 mupuf: pq: funny how everyone seems to think that the hardware is that badly designed :p
05:09 mupuf: the maximum voltage is a safe value 99% of the time
05:09 pq: well, it's a consumer device, isn't it? :-D
05:10 mupuf: it is becoming problematic when we go above the TDP, which is not happening often with nouveau because we still suck at instruction scheduling :p
05:10 mupuf: but it may happen
05:14 karolherbst: mupuf: ohh wait, clock readings are actually wrong maybe
05:14 karolherbst: mupuf: it was also wrong on Tom^s nvf1 card
05:14 karolherbst: the nouveau code reported a lower clock than set
05:14 karolherbst: have to verify this
05:15 karolherbst: blob performance by the way: 2671.034481 frames/sec - 2980.874481 Mpixels/sec
05:16 karolherbst: with memory reclokcing being below 50% is still a bit disappointing though, but glxspheres is now real benchmark, so
05:16 karolherbst: *no
05:19 karolherbst: mupuf: ohh I was wrong, it's at 97% now
05:20 karolherbst: mhh wrong card..
05:22 karolherbst: mupuf: anyway how I can select which gpu to use?
05:23 karolherbst: *any idea
05:27 karolherbst: ahh -a flag
05:29 karolherbst: yep
05:29 karolherbst: the clock reading code is wrong
05:31 mupuf: the clock tree may have changed
05:31 karolherbst: 1228 is set by nvidia, but nouveau reads 1088
05:33 karolherbst: yay
05:33 karolherbst: with fixed clock: 101% voltage
05:38 karolherbst: mupuf: so if you are up to it, we could just push the volt table parsing like it is on my gpu and add a big TODO to figure it out later the really right way. It seems to fit by 97%-102% across the gpu I tested then
05:38 karolherbst: which is really good
05:39 karolherbst: I would rather clean up all my patches now and try to get the stuff upstreamed currently
05:39 karolherbst: and after that I will take a closer look again
05:39 karolherbst: at least that is what I planned
05:39 mupuf: yep, sounds good
05:39 mupuf: it is a major improvement
05:39 karolherbst: and if somebody gets higher voltages, nouveaus fan code should be good enough
05:40 mupuf: but I do not guarantee I will not NAK some patches that will block the plan
05:40 karolherbst: the only problem I see, is boosting too much, that's why I want limit to the boost clock by deafult and don't go above
05:40 mupuf: but I am happy to give it a try
05:40 mupuf: yep
05:40 mupuf: you can introduce a new option to allow boost
05:40 karolherbst: base clock sounds too low and too much users will complain about dropped perf
05:40 karolherbst: yeah
05:40 karolherbst: already did
05:41 karolherbst: https://github.com/karolherbst/nouveau/commit/db2fa4485d9739819305f87df0325f8197c737e0
05:41 karolherbst: NVKM_CLK_BOOST_FULL is what nvidia does
05:41 karolherbst: NVKM_CLK_BOOST_AVG might cause problems if you run a power hungry OpenGL applications + video decoding + video encoding at the same time :D
07:26 karolherbst: yay!!!
07:26 karolherbst: mupuf: I found a way to get the right power_budget :)
07:27 karolherbst: mupuf: POWER BUDGET header+0x6
07:27 karolherbst: there is still more to it though :/
07:27 karolherbst: but this has definetly an effect on the downclocking on high power usage
07:32 karolherbst: this table is really messy though
07:34 karolherbst: mupuf: https://gist.github.com/karolherbst/9e23a71c99feec7d4519
07:35 karolherbst: but entry 0 has also affects the clock with the default header :/
07:35 karolherbst: so there is still something left
07:41 karolherbst: gotcha, SENSE table entry+0x2 also points to a budget
07:49 karolherbst: and then there is a third thing I don't see :/
08:12 pmoreau: karolherbst: https://github.com/karolherbst/linux/commit/560ac3f796c8c64a2101c44a8f66a5bcfc739e55 is the latest version of your mmio fix patch, right?
08:18 karolherbst: yeah
08:20 pmoreau: Ok, compiling the kernel with that patch to try it
09:11 Yoshimo: karolherbst: is it possible that the maxwell branch of yours doesn't compile with the 4.2 kernel?
09:11 karolherbst: yes
09:11 karolherbst: I might be able to backport it to 4.3
09:11 Yoshimo: is it based on 4.4?
09:11 karolherbst: yeah
09:12 karolherbst: but rebasing it on top of 4.2 might be possible, not sure head
09:12 Yoshimo: i can grab the 4.4 mainline kernel package from the ubuntu ppa, no problem
09:12 karolherbst: ahh okay
09:13 karolherbst: Yoshimo: well I got it to work on 1gen maxwell already and it worked :)
09:14 Yoshimo: so you say i don't have to test anything? ;)
09:14 karolherbst: well you should get acceleration working anyway
09:14 karolherbst: at least this is something you might want to have
09:15 karolherbst: or are you fine with software opengl? :p
09:15 karolherbst: also 2g maxwell can be different
09:15 Yoshimo: of course, was a rhetorical question
09:16 karolherbst: did you already compiled nouveau once out of tree?
09:16 Yoshimo: yea for the 560ti i also own
09:16 karolherbst: ahh okay
09:17 Yoshimo: the evil thing was switching back to binary afterwards for the 980, was a bit messsy
09:17 Yoshimo: with a bit of luck that won't be necessary this time
09:17 karolherbst: no
09:17 karolherbst: I don't think so
09:20 Yoshimo: while i wait for the firmware repo to finish downloading, what messages should appear if it works?
09:20 karolherbst: well glxinfo should print usefull stuff, but the firmware loading will only work with 4.6 I think
09:20 karolherbst: so you will need my tree anyway
09:21 karolherbst: Yoshimo: but when you are using the maxwell_recklocking branch (make sure of it) you should see a boost: MHz and a base: MHz line in dmesg
09:22 karolherbst: Yoshimo: and you might want to update the branch because I put in an important volt fix
09:22 Yoshimo: indeed there is a merge conflict when i pull , so you sure changed something
09:23 karolherbst: yeah
09:23 karolherbst: git reset --hard origin/maxwell_recklocking
09:24 Yoshimo: i did so already, but without your obvious typo
09:25 karolherbst: :D
09:25 karolherbst: right
09:26 Yoshimo: how big is the firmware repo btw?
09:26 karolherbst: no clue
09:27 karolherbst: Yoshimo: which was your gpu gm208?
09:27 karolherbst: ohhh gm206
09:28 karolherbst: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia
09:28 karolherbst: just grab the files you need
09:28 karolherbst: or wait :D
09:28 Yoshimo: NV124 (GM204) GeForce GTX (970, 980) according to the wiki
09:29 Yoshimo: gm208 isn't listed, does it exist?
09:29 karolherbst: no, my mistake
09:29 karolherbst: or
09:29 karolherbst: I think it is new
09:29 karolherbst: nope, I think it doesn't exist
09:47 karolherbst: Yoshimo: and finished with downloading=
09:48 Yoshimo: yea, just updating the kernel and when i come back it will get intresting
09:53 karolherbst: mupuf: did you found the unk12 field in the power_budget?
10:47 mupuf: karolherbst: i'm back from my class
10:49 karolherbst: mupuf: so you are ready to put in the gm20x?
10:49 mupuf: karolherbst: who is using reator?
10:49 karolherbst: not me
10:49 karolherbst: hakzsam then
10:49 mupuf: hakzsam: tell us when you are done
10:50 karolherbst: he wanted to finish gm107 compute_shaders
10:50 karolherbst: I think
10:50 mupuf: yep, something like that
10:50 karolherbst: maybe not finish, but working on it
10:55 mupuf: he said he was working on adding the BAR instruction
10:55 mupuf: and that should fix most of the issues
10:56 karolherbst: :) nice
10:57 karolherbst: anyway, I will eat something now, so he can still work a bit :D
11:02 hakzsam: mupuf, hehe it's always me! :p
11:02 hakzsam: mupuf, have fun, but could you please re-plug the gm107 after?
11:03 hakzsam: compute shaders still need some work
11:03 hakzsam: mupuf, and yeah, BAR has fixed a lot of tests
11:04 hakzsam: the last thing to do is to fix shared+atomics
11:16 Yoshimo: karolherbst: https://pastee.org/qy7x3 , can you confirm that i atleast didn't screw up the installation process? ;)
11:19 mupuf: hakzsam: very nice!
11:19 mupuf: well, maybe maxwell 2 did not change things too much :)
11:19 hakzsam: mupuf, I hope
11:19 hakzsam: but I doubt :)-
11:23 karolherbst: Yoshimo: well you should use my branch
11:23 karolherbst: Yoshimo: because the firmware loading code isn't in 4.4 yet
11:25 Yoshimo: i installed 4.4 , i checked out your repo, i compiled it i copied it over to the modules directory and rebuild initiram , so why am i supposedly not using your branch?
11:26 Yoshimo: did i forget something?
11:28 karolherbst: Yoshimo: did you rebuilt initramfs?
11:29 karolherbst: Yoshimo: ahh maybe you didn't changed the branch
11:29 Yoshimo: updateinitramfs -u , should do it, well i try again, i was sure to have switched the branch last night, but it was late
11:46 karolherbst: hakzsam: how long do you want to still use reator?
11:50 hakzsam: karolherbst, I don't use it
11:50 karolherbst: ohh
11:51 karolherbst: ahhh mupuf already put the gm206 in :)
11:51 karolherbst: well
11:54 karolherbst: mupuf: the firmware is still missing, right?
11:55 karolherbst: and the arch package is still too old :/
11:56 karolherbst: ohh it is there
11:56 karolherbst: odd
11:58 karolherbst: is there anything required to get the secboot stuff working?
11:58 karolherbst: only firmware files and those patches, right?
12:00 mupuf: karolherbst: hey
12:01 mupuf: everything is in place normally
12:01 karolherbst: mupuf: I still get only llvmpipe :/
12:01 mupuf: I can check again
12:01 karolherbst: yeah the firmware files are ther
12:01 karolherbst: secboot: 2 managed LS falcons, WPR size is 131072 bytes
12:01 karolherbst: seems okay
12:02 karolherbst: ohh [ 2549.471] EGL_MESA_drm_image required.
12:02 karolherbst: [ 2549.471] (EE) modeset(0): glamor initialization failed
12:02 mupuf: yep
12:02 mupuf: sorry, you need to do something to get it to work :D
12:02 karolherbst: :D
12:03 mupuf: until mesa 10.2 is released and lands in arch, you need to use my own mesa
12:03 karolherbst: you mean 11.2?
12:03 mupuf: yep
12:03 karolherbst: k, where is it?
12:04 mupuf: source src/nouveau_env.sh
12:04 mupuf: and then you can run X
12:04 mupuf: just checked, seems to have worked ok
12:04 karolherbst: ahh better
12:05 karolherbst: stock clocks: 506.140514 frames/sec - 564.852814 Mpixels/sec
12:05 mupuf: :) that was quick
12:05 karolherbst: mhh, pstate returns -ENODEV...
12:06 mupuf: ah ah
12:06 karolherbst: ohh no clk subdev
12:06 karolherbst: is that stuff different than gm107?
12:08 karolherbst: seems okay
12:10 karolherbst: damn you pmu :/
12:11 karolherbst: mupuf: do we have access to the pmu yet?
12:11 mupuf: karolherbst: well, no-one checked :D
12:11 karolherbst: k
12:11 mupuf: I did check a bit the gm107, but not extensively
12:11 karolherbst: k
12:12 mupuf: but if nouveau reports the same clocks as the blob, I guess it is fine
12:12 karolherbst: well it worked on gm107, so we should be able to get it working on the gm206 too
12:12 mupuf: as for the pmu, we will not have access to it
12:12 karolherbst: ohhh
12:12 karolherbst: mhhh
12:12 karolherbst: then no memory recklocking I guess
12:12 mupuf: so, memory reclocking will need to happen on the host
12:12 mupuf: yep
12:12 karolherbst: bummer
12:13 mupuf: gnurou will fix that soon, right? :D
12:15 karolherbst: ehm... volt: Using GPIO mode
12:15 karolherbst: that sounds wrong
12:16 karolherbst: ohh even nvbios
12:16 karolherbst: ohh no, it has VIDs
12:16 karolherbst: strange
12:17 karolherbst: wtvr
12:18 karolherbst: k, the pmu doesn't reply,
12:18 mupuf: karolherbst: guess why :D
12:18 karolherbst: :D
12:18 mupuf: We did not upload our own fw :p
12:19 karolherbst: but
12:19 mupuf: yeah, this is weird that it is using GPIOs :s
12:19 mupuf: I saw that
12:19 karolherbst: yay, more perf
12:19 karolherbst: 604.883762 frames/sec - 675.050279 Mpixels/sec
12:19 mupuf: and the reported clocks are the same as nvidia's?
12:19 karolherbst: AC: core 1290 MHz memory 810 MHz
12:19 karolherbst: no clue
12:19 karolherbst: ohh wait, I cap at boost clock
12:21 karolherbst: yay AC: core 1392 MHz memory 810 MHz
12:21 Yoshimo: karolherbst: sorry, i can't find anything wrong with my process and your lines do not show. I also do not get to the graphic login screen since i activated nouvau, it stays black. Terminal works though . I admit defeat
12:22 karolherbst: mupuf: so mhh, without memory recklocking testing perf is kind of pointless
12:22 karolherbst: mupuf: it seems to work though
12:22 karolherbst: gnurou: unlocked pmu would be soooo nice now :p
12:22 mupuf: karolherbst: unlocked PMU will never come
12:22 karolherbst: :O
12:22 karolherbst: ahh secured PMU then
12:22 karolherbst: with nvidias interface?
12:23 mupuf: yep
12:23 karolherbst: mhh okay
12:23 mupuf: we will need to move to the same interface, same script interface, same everything
12:23 karolherbst: :/
12:23 mupuf: all the fun we are going to have :D
12:23 karolherbst: I assume we will move with all chipsets to it then
12:24 karolherbst: though it shouldn't be that work, because there will be just some numbers changed I hope
12:26 karolherbst: mupuf: there is no magic switch to execute the pmu script on the host, right?
12:26 mupuf: well, you can write an interpreter
12:26 mupuf: but it is going to suck
12:26 mupuf: and no putting the card off-bus means unstable reclocking also
12:26 karolherbst: yeah :/
12:27 karolherbst: k so until we have full maxwell2 recklocking we wait until the pmu stuff is done
12:29 karolherbst: but it's nice to know that the kepler stuff works on maxwell
12:29 mupuf: well, one could test to interpret the script from the host
12:29 mupuf: it should be quite easy to write
12:29 mupuf: that could be enough for manual reclocking
12:29 karolherbst: mhhh
12:29 karolherbst: basically it is just the memx interface right?
12:29 karolherbst: I could jut map them to actual writes and see how that goes
12:30 mupuf: yep
12:30 mupuf: you to disasm the instructions and execute them, but that should be trivial since it is easy in asm
12:31 karolherbst: why not just map nvkm_memx_wr32 to nvkm_wr32?
12:31 karolherbst: ohh there is also nvkm_memx_train
12:31 karolherbst: mhh
12:32 pmoreau: mupuf: I have to check that magic source file to get rid of that EGL_mesa_image thing
12:33 mupuf: pmoreau: magic source file?
12:33 pmoreau: 21:04:11 mupuf | source src/nouveau_env.sh
12:33 Yoshimo: i wish you the best of luck with maxwell
12:33 mupuf: pmoreau: you need to recompile mesa
12:33 mupuf: nouveau_env.sh is boring
12:34 mupuf: export LD_LIBRARY_PATH=$NVD/lib
12:34 karolherbst: mupuf: doing memory training on the host might be messy :/ I think we should just wait until the pmu stuff is ready then
12:34 pmoreau: I tried with a recompiled mesa… didn't helped though. I'll have to retry again
12:36 Yoshimo: karolherbst: no further ideas about my maxwell?
12:36 mupuf: pmoreau: did you make sure the x server uses it at boot time?
12:36 pmoreau: Not at boot time, but I killed it and restarted a new one which should have used it.
12:36 karolherbst: Yoshimo: not really :/ except maybe you should really check if you are on the right branch
12:37 mupuf: pmoreau: you replaced the system libraries?
12:37 mupuf: brb
12:37 Yoshimo: if i switch to maxwell_reclocking it said it is the same as origin/maxwell_reclocking and so far that seems to be correct
12:38 pmoreau: mupuf: No, using `export LD_LIBRARY_PATH=`, like I do when I experiment with OpenCL on a custom build mesa
12:38 Yoshimo: which subfolder should the nouveau.ko land in, inside the modules folder? maybe i copied it to the wrong location
12:39 karolherbst: Yoshimo: /lib/modules/$kernel_version/kernel/drivers/gpu/drm/nouveau
12:39 karolherbst: just remove the old one
12:39 Yoshimo: i did that, so i am really lost
12:40 Yoshimo: do the bus faults show something major in my paste?
12:40 karolherbst: yeah
12:41 karolherbst: well you would also need a recent mesa and everything to get it working, maybe it would be much easier to just wait for now :/ I never went through the process so I can't really help fixing up userspace to get it working for real :/
12:43 mupuf: pmoreau: then you did not get what I said
12:43 Yoshimo: i have oibafs 11.3 ppa linked in, so i would expect it to work
12:43 mupuf: X has to use this version of mesa
12:43 mupuf: that means you need to set the LD_LIBRARY_PATH before running X
12:45 Yoshimo: apart from that, shouldn't your message show regardless of mesa being the right version?
12:45 pmoreau: But if I kill X and restart it with the LD_LIBRARY_PATH before the second, it should still work, right?
12:46 karolherbst: Yoshimo: right
12:46 karolherbst: Yoshimo: maybe you have a nouveau module inside extras?
12:47 karolherbst: pmoreau: do you use LD_LIBRARY_PATH on an installed mesa or only into the build/lib folder?
12:47 Yoshimo: i had that for a while, but it is identical to the one inside the drm folder, removing it did not seem to change anything
12:47 karolherbst: Yoshimo: well you have to rebuild initramfs after removing it
12:47 Yoshimo: been there done that
12:48 karolherbst: Yoshimo: then find for anything called nouveau.ko(.xz) inside /lib/modules
12:48 karolherbst: Yoshimo: ohh you copy into the 4.4 right?
12:49 pmoreau: karolherbst: LD_LIBRARY_PATH=path/to/custom/installed/lib
12:49 karolherbst: mhh
12:50 Yoshimo: karolherbst: sure, 4.5 didn't compile with it and 4.2 neither, so what else should i do?
12:50 pmoreau: And it seems to work, as it complains about not finding the swrast driver (which I didn't build), whereas it finds it otherwise using the system libs
12:50 karolherbst: ahh okay
12:51 karolherbst: Yoshimo: find /lib/modules/ -iname "nouveau.ko*"
12:52 Yoshimo: so you suspect duplicate files somewhere?
12:54 karolherbst: pmoreau: by the way, did the mmiotrace fix still work?
12:54 pmoreau: Haven't tried it yet, will do that soon
12:54 pmoreau: But it is compiled :-)
12:57 karolherbst: :)
13:00 karolherbst: mupuf: if you want you can put the gm107 back into reator
13:00 karolherbst: maybe I will try to figure out what nouveau misses for reading out the right clock
13:10 mupuf: karolherbst: ok!
13:10 mupuf: done
13:11 karolherbst: k, thanks
13:11 karolherbst: which CLK is the gpc?
13:12 mupuf: supposed to be core
13:12 karolherbst: I meant which number actually
13:12 mupuf: ah, hmm, check nvbios
13:12 karolherbst: 0
13:12 mupuf: I seem to remember they are listed in the right order there
13:12 mupuf: but not too sure
13:12 mupuf: you can check in the code
13:13 mupuf: of nouveau*
13:13 karolherbst: PCLOCK.CLK0_CTRL => { UNK12 = 0 | PLL_PWR | PLL_LOCK | 0x20 } mhhh
13:13 karolherbst: what 0x20 might be
13:14 Jayhost: karolherbst is it normal for valgrind mmt -option [nouveau file.bin] to write gigabytes of data
13:14 karolherbst: Jayhost: yeah
13:15 karolherbst: once I tried to figoure out a bug with apitrace, and apitrace writes less than mmt, and got like a 50GB apitrace :)
13:15 karolherbst: so depending on the issue, you might want to have a lot of space :)
13:15 Jayhost: haha ouch
13:15 RSpliet: karolherbst: a secret, apparently: https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gm107/trim.h
13:15 Jayhost: I've spent a bit of time trying to clean hard drive space and truncating file
13:16 karolherbst: mhhh
13:17 karolherbst: I will so annoy the blob now :D
13:17 karolherbst: well the clock is also read out wrongly on gk110
13:17 karolherbst: but I doubt mupuf has any of them :p
13:27 Jayhost: What gm107 stuff are you all working on?
13:34 karolherbst: mupuf: concidence that nouveau reads the clock 1/8 too low?
13:36 mupuf: karolherbst: wrong clock tree parsing :p
13:37 mupuf: but that is a funny one indeed
13:37 karolherbst: 137008 10000000 PCLOCK.CLK0_UNK8
13:37 karolherbst: this looks funny
13:52 mupuf: karolherbst: I wonder how you are going to RE that
13:52 mupuf: wait, sorry
13:52 mupuf: of course, nvatiming
13:52 mupuf: it just does not work for clock gating
13:52 mupuf: but it does for the clock tree
14:04 karolherbst: mupuf: why not just set that reg with nouveau and see if the performance changes?
14:07 karolherbst: mhh well that reg seems to be read only anyway
14:13 mupuf: karolherbst: nope, please just use nvatiming
14:14 mupuf: checking out the perf is the last resort
14:14 karolherbst: well first I limit cstates until I find the clock where nouveau equals nvidia clock
14:14 mupuf: :)
14:15 mupuf: going to bed!
14:15 mupuf: the sickness is not going to go away unless I sleep. Have fun!
14:15 mupuf: I will have a look at your other patches tomorrow
14:15 karolherbst: :D
14:15 karolherbst: thanks
14:16 karolherbst: k, mode 3 does something funny
14:19 karolherbst: I think I found it
14:20 karolherbst: https://gist.github.com/karolherbst/b2bf786ed20503d1714c
14:20 karolherbst: and nouveau calculates the same clock for both
14:20 karolherbst: 1518750/2
14:21 karolherbst: yeah, nouveau gets 759
14:21 karolherbst: when the lower 16bits of 13700C are 0, we are the same
14:21 karolherbst: if not, then we have to adjust
14:22 karolherbst: that was kind of easy
14:25 karolherbst: ohh and 0x13700c only got a meaning since gk110 :)
14:26 mupuf: well, many bits to RE then :D
14:26 karolherbst: they are inside hwref though
14:26 mupuf: nice
14:26 karolherbst: https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gm206/trim.h#L40-L43
14:26 mupuf: SDM?
14:26 karolherbst: https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gk110/trim.h#L40-L41
14:26 karolherbst: and of course it is different on gk110
14:26 karolherbst: ....
14:27 karolherbst: ahh well, just some bits added
14:27 karolherbst: no idea
14:27 karolherbst: sigma-delta mod- ulator
14:27 karolherbst: ?
14:28 mupuf: hmm hmm, that makes no sense
14:28 mupuf: sigma delta is used for ADCs
14:29 mupuf: I do not see how you could modulate with this
14:29 mupuf: but, it is possible
14:29 karolherbst: I just googled pll sdm
14:29 mupuf: oh well, then it likely is this, read up on it and see what you can get out of this :)
14:30 karolherbst: sigma delta modulator for fractional N-PLL
14:30 karolherbst: seems to be a thing
14:30 mupuf: oh shit, fractional N :D
14:31 mupuf: well, sounds good!
14:31 karolherbst: well the bits are like 0xf0f0
14:31 karolherbst: or someting
14:31 karolherbst: well this is work for tomorrow anyway
14:31 mupuf: hehe
14:31 mupuf: some changes will need to be made to make use of the added precision :)
14:32 karolherbst: yeah
14:32 karolherbst: well I already implemented it for gddr5 anyway
14:32 mupuf: oh, great!
14:32 karolherbst: never noticed that gddr5 memory clock is on spot?
14:32 mupuf: anyway, bed time!
14:33 mupuf: karolherbst: unfortunately, I had a blackout on nouveau for a few months
14:33 karolherbst: mupuf: https://github.com/karolherbst/nouveau/blob/master_4.4/drm/nouveau/nvkm/subdev/fb/ramgk104.c#L1026-L1029
14:33 mupuf: make it many months
14:34 mupuf: going back to it as time permits :)
14:34 karolherbst: :D
14:34 karolherbst: k good night then
14:34 karolherbst: I will also head to bed
14:35 Jayhost: Alright I got file-bin.log at only 400 Gigabytes
14:39 karolherbst: and then it crashed?
14:39 karolherbst: ohh you are so screwed, you know that? .D
14:40 karolherbst: send that file to Imirkin, he will be happy
14:40 Jayhost: No I crashed it because dmesg gets me the gpc error
14:41 Jayhost: Haha I don't know which parts are jokes
14:42 Jayhost: Should I run it until it crashes
14:44 karolherbst: I am off to bed now, so I won't be of any help
14:44 karolherbst: anyway
14:44 karolherbst: a mmt is just a trace of what was send to the driver
14:44 karolherbst: I doubt you can just rerun it
14:44 karolherbst: but it can be used to help understanding what went wrong
14:45 Jayhost: Alright sounds good. Will bug mirkin
14:46 karolherbst: but if there is only the GPC part in dmesg, it might be useless :/
14:46 karolherbst: there need some error on a subchannel
14:46 karolherbst: and so on
14:46 karolherbst: best if you just save the entire dmesg output
14:48 Jayhost: got it. If you have any reading material I'd like to check out related to the error or Reclocking. I only have Rspliet and Marcin's paper
14:50 hakzsam: karolherbst, done with reator? coz I need to make a MMT with SHFL on GK104 :)
14:51 hakzsam: well, seems like
15:35 gnurou: mupuf: karolherbst: definitely working towards releasing the PMU firmware ("unlocked" is not the word I would use here sadly). No timeframe nor promise at this point though
15:55 hakzsam: skeggsb, hi, I think you can merge this PR btw https://github.com/envytools/envytools/pull/41
18:23 Jayhost: /join #hurd
21:48 Jayhost: imirkin I was able to get 400GB file-bin.log file from mmt
21:59 Jayhost: But I get a really small text file when I use demmt
22:04 Jayhost: nouveau website is down
23:34 pq: #freedesktop has been notified of issues with fd.o web services