13:12karolherbst: mupuf, skeggsb_: people are waiting for my clk patches, please review if you find some time ;)
13:28mupuf: karolherbst: yes, I will do it tonight and tomorrow
13:28mupuf: it would be cool ot report progress on that at FOSDEM
14:04Naglfar: hello, is it possible to use pwm for NV35 [GeForce FX 5900XT] ?
14:28RSpliet: Naglfar: What do you want to pulse-width modulate?
14:29Naglfar: fan speed control
14:31Naglfar: it's running at 100% rpms
14:33RSpliet: Fan speed control should be supported by nouveau transparently to the user. Your VBIOS will contain the necessary information to tell nouveau how to operate them. Does the official driver speed down the fan when idle?
14:34RSpliet: (... this being said, I don't see nv35 thermal being hooked up in nouveau anywhere or a code base existing. mupuf is the man who should know more about the details)
14:58Naglfar: RSpliet, not the official driver, but nvclock0.8b4 allow speed control it
15:14mupuf: Naglfar: I unfortunately do not own any of these GPUs
15:14mupuf: they are all AGP IIRC
15:14Naglfar: I have one
15:14Naglfar: I use it
15:14Naglfar: 01:00.0 VGA compatible controller: NVIDIA Corporation NV35 [GeForce FX 5900XT] (rev a1)
15:15mupuf: and I do not have any AGP mobo (I could get one, but not sure how fun it will be)
15:15mupuf: well, want to have fun and write support for it?
15:15Naglfar: what should I write ?
15:15mupuf: the problem is that nvclock's license is not GPL
15:15mupuf: or it is
15:15mupuf: and nouveau is MIT
15:16mupuf: so you can't read the source code, because it may leak to nouveau
15:16mupuf: maybe if you read it and wrote the rnndb docu,entation for it, it would be more acceptable to then make a patch for it
15:16mupuf: or I could make the patch for you in nouveau and you would test it
15:18Naglfar: what code whould I patch?
15:19mupuf: first, let's write documentation
15:20mupuf: grab envytools
15:20mupuf: compile it and use nvapeek/poke to change your fan speed
15:20mupuf: you can read nvclock to find which register to use I guess
15:23Naglfar: do you mean to read nvclock source code?
15:23vries_: pmoreau: Hi. Which compiler do you use to compile nvir_from_spirv.cpp ?
15:23pmoreau: vries_: Hello. I use a regular C++ compiler, with C++11 enabled.
15:24pmoreau: I‘ve been using clang 5.x (and maybe GCC 7.x as well)
15:24vries_: pmoreau: I'm using gcc 5.4.0 with c++11 enabled, and get compilation errors
15:25vries_: pmoreau: so I was hoping to hear something more specific
15:25pmoreau: Which errors are you getting?
15:25vries_: pmoreau: ah, I see
15:27vries_: pmoreau: https://pastebin.com/agHEmdt0
15:28vries_: pmoreau: I'll try with the versions you mention. Thanks.
15:30pmoreau: Please let me know if that solves things or not. I don’t think those are C++14 features, but I’ll need to investigate why it doesn’t work with gcc 5.4.0 and C++11 enabled.
15:31vries_: pmoreau: will do
16:11orbea: apitrace crashed nouveau after replaying a trace of a wine64 game and then making the window full screen. Here is dmesg. http://dpaste.com/2NQJGQ8 I've seen mpv crash nouveau the same way when going full screen as well... This is with a 4.14.14 kernel. Here is the trace (Not that it seems to show other issues). http://ks392457.kimsufi.com/orbea/stuff/trace/wine64-tob.trace.xz
16:12orbea: any ideas how to debug this further? Its kind of bad to have apitrace crash nouveau...
16:13orbea: the game works well in nouveau at least.
18:36heis2201: Hi everyone, I have a quick question regarding geforce GT1030 (Pascal // NV138 // GP108): What's the current status? Is it supported by the nouveau driver?
18:40gnarface: https://nouveau.freedesktop.org/wiki/FeatureMatrix/ https://nouveau.freedesktop.org/wiki/VideoAcceleration/
18:40gnarface: heis2201: dunno off the top of my head, but here's the charts
18:44heis2201: gnarface, thanks for the links!
19:09Lyude: grrr, just noticed in v2 of the clockgating series I messed up the conditional in gf100_clkgate_init() so it wasn't actually writing any of the BLCG or SLCG registers. mupuf, would mind terribly if I added a nvkm_trace() in gf100_clkgate_init() for the next series so we can actually verify things are being written in the future? (additionally since sometimes it's easy to mess up the mmiopack format sometimes
19:09Lyude: when writing new ones)
19:35mupuf: Lyude: please do!
19:35mupuf: this is a great idea
19:36mupuf: but doesn't the highest debug mode actually dump every single write?
19:36Lyude: yeah, now that that is fixed as well I had the bright idea of trying to continously reclock the card again to make sure everything is working and I'm seeing some engine hangs now on k2 :(
19:36Lyude: mupuf: I don't believe so? I thought we removed that at some point
19:36mupuf: oh, I just remember from the begining then
19:37mupuf:'s gray hair are maybe a real sign of being old and having bad memory
19:37Lyude: anyway, going to see if I can figure out what's breaking here and see if k1 is having the same issues as well with reclocking...
19:38mupuf: be consistent when checking the stability of reclocking
19:38mupuf: 1M reclocks, count the number of failures
19:38Lyude: 1M = 1 million?
19:39Lyude: hoping I just wrote some register wrong soemwhere
19:39mupuf: clock gating increases the dI/dt, so it is no wonder you have more chances of crashing
19:39Lyude: at the very least though, we bring back up the engines properly!
19:39mupuf: oh! I got an idea!
19:39mupuf: before reclocking, force the clock gating to RUN
19:40mupuf: wait a ms, then reclock, then reset the clock gating
19:40Lyude: mhm; that's something I was considering doing
19:40mupuf: this is the safest bet
19:40Lyude: it doesn't look like the nvidia driver does that but maybe the driver knows how to reclock in that regard better then we do
19:40mupuf: well, it also limits how often it reclocks
19:40Lyude: first I need to see if this is actually a problem with reclocking though, or if it just falls over on high clock rates in general
19:41mupuf: and it tests more thouroughly things
19:41Lyude: ahhh, interesting
19:41mupuf: we don't copy exactly what the blob does, but we are super close
19:41Lyude: bleh, sorry for this coming out so late btw! i bet it probably never came up before because i was reclocking every 15 seconds last time I tried
19:42Lyude: every 1 second just makes it fall over
19:43mupuf: does it make it fallover, or is it just the fact that you can try more iterations that kills it?
19:44mupuf: the answer: There is no way to know without a super fast scope
19:44mupuf: I used to reclock 30 times per second on my nv86
19:44Lyude: I don't think it's the iterations, it's the time between them. I remember when I initially tested this, I had a bash script cycling through the power levels every 15 seconds and just left the machine running overnight
19:45Lyude: which would coincide with what you mentioned; nvidia waiting a moment before reclocking
19:45mupuf: and with one second, how quickly does it crash?
19:45Lyude: pretty quickly, takes about a minute at most
19:45Lyude: that's with load
19:45mupuf: hmm, but with load, it is fine?
19:46mupuf: anyway, what I am talking about is microseconds
19:46mupuf: not seconds
19:46mupuf: the voltage controler has a pretty huge bandwidth
19:46Lyude: yeah, without reclocking and just running it with load on the highest clock it's perfectly fine
19:46mupuf: ok, but reclocking every 15 seconds under load?
19:47Lyude: lemme see
19:47mupuf: I think the problem has nothing to do with the frequency, it is just that we screw up idling the GPU
19:47mupuf: add 20ms after idling before actually reclocking and see if it improves
19:48mupuf: yes, that has always been the problem
19:48mupuf: that's why I was reclocking over 3 million times to test stability
19:48mupuf: while running xonotic in a loop
19:48Lyude: (also, think I'm going to throw together a small python script to help out testing this
19:49mupuf: sounds good!
19:49mupuf: reliability test!
19:49mupuf: make sure to sync the file to disk often!
19:49Lyude: sure thing
19:50mupuf: but seriously, put no delay between reclocks
19:51mupuf: if you have to put a delay in the userspace to prevent crashes, it means you do not do the reclocking properly
19:51mupuf: unless you are reclocking at more than 1kHz
19:52karolherbst: that sounds interesting
19:53mupuf: Lyude: the userspace should never be able to break anything. If you need to have special timings, enforce them
19:53karolherbst: mupuf, Lyude: I only got your last three lines due to joining and it sounded like Lyude fixed a reclocking bug by putting in some delay in userspace
19:53Lyude: nah, I found a reclocking bug with powergating
19:54karolherbst: how reliable?
19:55karolherbst: mupuf: we can't dump mmio reads/writes anymore, it got removed at some point ;)
19:55Lyude: pretty reliable if we reclock quickly
19:56mupuf: karolherbst: thx
19:56mupuf: Lyude: also, it is great to make a reliability test suite, so as users can report issues
19:57karolherbst: Lyude: do you have two states with same memory clock?
19:57karolherbst: but different engine clocks?
19:57karolherbst: memory reclocking slows down the reclocking process quite a lot, so you can't really stress test engine reclocking
19:57karolherbst: I think with memory reclocking you get a rate like 70 reclocks per second at most?
19:57karolherbst: with just engine you can get up to 1000 reclocks per second
19:58karolherbst: Lyude: or take the boost debugfs file patches from my branches
19:58karolherbst: then you can just switch the boost level and trigger an engine reclock
19:59karolherbst: allthough I think it would also reclock memory without my other patches?
20:01Lyude: karolherbst: https://paste.fedoraproject.org/paste/Y4oc23qDjWIxFWUoS5UE-A from my k2
20:01karolherbst: Lyude: mhh, I think you need my reclocking patches
20:01karolherbst: because there I am actually checking for state changes
20:01Lyude: yay! not my bug! :D
20:01Lyude: anyway, mind linking them?
20:01karolherbst: like if the memory has already the target clock, I skip the memory reclock
20:01karolherbst: or well
20:02karolherbst: I skip changing the pstate
20:02karolherbst: I guess I don't skip reclocking if the clocks are the same though
20:02karolherbst: Lyude: https://github.com/karolherbst/nouveau/commits/clk_cleanup_for_real
20:02karolherbst: starting with the bios/vpstate patch
20:23mupuf: Lyude: do you plan on sending a v3 soon or should I review it now?
20:23Lyude: mupuf: I am planning on sending a v3 soon yeah, v2 doesn't actually write any registers :P
20:24mupuf: will this be the only difference?
20:24Lyude: hopefully :), but I won't know until I test reclocking with those patches
20:24Lyude: unless we're OK with pushing them upstream either way and fixing that part later
20:25Lyude: (that part == reclocking with clockgating very quickly)
20:27mupuf: yes, I am OK with that
20:27Lyude: yes! :)
20:28Lyude: alright, then I will send the v3 out in just a little bit
20:35mupuf: I mean, reclocking is still unknown, if users can save some power with clock gating and have no stability issue, then it is great
20:35mupuf: and reclocking under load is also not supported
20:35mupuf: reclock at your own risk
20:36mupuf: if clockhating + highest perflvl is stable, then it is ready from my point of view
20:39mupuf: anyway, the goal of merging the patches is to get testers
21:00Lyude: sending out now
21:04Lyude: mupuf: sent
21:04Lyude: we need to remove firstname.lastname@example.org from the MAINTAINERS list BTW,I keep getting undelivered mail errors from that address