01:09 hakzsam: imirkin, pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed.--> maybe the same issue as indirect draw+compute when we submit too fast?
02:11 mupuf: karolherbst: almost no chance yeah... But we can ask!
02:12 karolherbst: mupuf: mhh time would be better spend figuring it out ourself
02:12 karolherbst: because that's the only thing left anyway
02:12 mupuf: great! Just one value?
02:12 karolherbst: well
02:12 karolherbst: one factor
02:12 karolherbst: without the weight figured out yet
02:13 mupuf: how many cards did you test your code on?
02:13 mupuf: and what tests did you run?
02:13 karolherbst: mhh around >5
02:13 karolherbst: usually my voltage compare tool
02:13 karolherbst: I didn't really checked for stability yet
02:14 karolherbst: but having a similiar voltage should be okay for now
02:14 karolherbst: there are some other engines issues I think
02:14 karolherbst: especially memory reclokcing has issues I didn't figure out yet
02:14 mupuf: yes, the voltage compare tool is exactly what should be run
02:15 karolherbst: I fixed up a branch with rather trivial things I would like to push into 4.6
02:15 karolherbst: with important things I rely on later
02:15 karolherbst: but no functional changes
02:16 karolherbst: mupuf: this is something nice I found: https://github.com/envytools/envytools/commit/011c342c798c993ede250027b59f935b6f50c3ae
02:16 karolherbst: both entries give us a "max voltage" entry the blob never volts above (neither of both)
02:16 karolherbst: but I didn't figure out yet what the difference is between those two
02:17 mupuf: lol
02:17 karolherbst: one is 1.175V and the other 1.25V for me
02:17 karolherbst: so it is pretty unimportant on my gpu
02:17 karolherbst: but other high end gpus with high voltages are limited by these on nvidia
02:18 karolherbst: and they behave the same currently
02:19 karolherbst: mupuf: these are the things I would like to get into 4.6: https://github.com/karolherbst/nouveau/commits/trivial
02:19 karolherbst: nothing scary, but everything kind of important
02:20 RSpliet: karolherbst: I don't think your nouveau/blob voltage tool belongs in the kernel tree
02:21 karolherbst: RSpliet: nouveau git tree
02:21 karolherbst: RSpliet: below drm
02:21 mupuf: RSpliet: it is not in the kernel tree
02:21 karolherbst: or is it above drm?...
02:21 karolherbst: :D
02:21 RSpliet: I know what it is
02:21 karolherbst: it doesn't make sense to build this against nva
02:22 karolherbst: and if it isn't in a nouveau tree, then the libnouveau stuff has to be installed somewhat with header and pc files we can rely on
02:22 mupuf: karolherbst: no commit to crazy indeed
02:22 karolherbst: yeah, the crazy ones are in my other branches :D
02:23 mupuf: but we will need to add one process on temperature polling
02:23 karolherbst: I know
02:23 mupuf: as in, update_voltage(temp)
02:23 mupuf: that should not be too invasive
02:23 karolherbst: and we will need to calculate at which temperature we need to change voltage and so on
02:23 karolherbst: and change it on the fly
02:23 mupuf: nope, don't do that, just update it every second
02:24 karolherbst: okay, and if the set voltage doesn't change, do nothing
02:24 RSpliet: karolherbst: https://github.com/karolherbst/nouveau/commit/2ed36f2423ea77f11605ccb1ad6033b766716ca4 <- what is mode and how do I interpret that?
02:24 mupuf: karolherbst: yep, that wou;ld be safer
02:24 karolherbst: RSpliet: this https://gist.github.com/karolherbst/3618ce3bf994779a3e0d
02:24 karolherbst: c0-c5 are parameters in the voltage map table entries
02:24 karolherbst: and depending on the mode, they are used differently
02:24 karolherbst: T is temperature
02:25 RSpliet: hmm okay
02:25 karolherbst: mode >=4 nvidia won't load by the way
02:26 RSpliet: I see how that'll be hard to encode in a more descriptive name... hmm... let me have a think about that :-D
02:28 karolherbst: mupuf: where should such a process be added? Therm?
02:28 mupuf: yes, on polling hte temperature, you just call the function to update the voltage
02:28 karolherbst: k
02:29 karolherbst: will do that when pushing my actualy voltage thingies though, because it has no use currently anyway
02:29 karolherbst: maybe I will spend some time to add a "no write" mode to nouveau, so that we can use every subdev in tools
02:29 RSpliet: https://github.com/karolherbst/nouveau/commit/b3301403ebe124fddd1fef39cc13172ac088afdd <- that's trivial, but in it's current form a bit pointless to push forward - temp isn't actually being used to determine the mapping
02:29 karolherbst: which means, that ctors and init functions don't write anything
02:30 RSpliet: better hold that back until you start using temp :-)
02:30 karolherbst: RSpliet: yeah, but I don't want to change the interface again later .d
02:30 karolherbst: :D
02:30 karolherbst: I could also just pass 0 to the function for now
02:31 RSpliet: doesn't make it less pointless
02:31 karolherbst: mupuf: funny story: my tool didn't detected the right cstate on Tom^s card. I suspect that the clock calculation has some other parameter nouveau doesn't respect yet
02:31 RSpliet: I'd advice against making interface changes until you have the implementation details done as well
02:32 karolherbst: RSpliet: I have: https://github.com/karolherbst/nouveau/commit/abe6f89d3160925f51a456deee768ada835db743
02:32 RSpliet: gives you the freedom to rethink your solution while implementing :-)
02:33 RSpliet: karolherbst: understood, but as a tree maintainer I wouldn't accept b330140 without abe6f89
02:33 karolherbst: RSpliet: k
02:33 karolherbst: yeah I don't mind
02:33 karolherbst: mupuf: I was thinking, I could give a talk about the general boosting/clocking situation on fermi+ covering the entire GPUBoost (tm) thing
02:35 karolherbst: mupuf: ohh I now what the TDP base clock is all about: no matter what load you have, you will always stay under the TDP... makes sense
02:35 karolherbst: but this should be equal to the normal base clock anyway
02:35 karolherbst: which it always is
02:37 karolherbst: funny that officially gpu boost was added with kepler, but on fermi we have already all that stuff in the vbios
02:55 karolherbst: k, update commits: https://github.com/karolherbst/nouveau/commits/trivial
02:55 karolherbst: *updated
02:58 vita_cell: karolherbst how is going memory reclock on maxwell g1?
02:58 vita_cell: still resists?
02:58 karolherbst: vita_cell: I don't have any g1 maxwell
02:58 vita_cell: ahhhh
02:58 vita_cell: ok
02:58 RSpliet: vita_cell: nobody is working on that at the moment
02:58 vita_cell: you working on kepler still
02:59 karolherbst: mupuf: by the way: https://github.com/karolherbst/nouveau/commits/pmu_fixes
02:59 RSpliet: karolherbst is, I'm investing some of my free time in Fermi
02:59 karolherbst: RSpliet: nice :)
02:59 vita_cell: Fermi, nice!
02:59 RSpliet: don't get your hopes up too high yet though, my free time is rather limited :-P
02:59 vita_cell: still can't reclock my gtx460 or gt520
03:00 karolherbst: it will be a bloody mess though :/ I really hope that we don't need a lot of different code paths for different situations, but it really looks like it
03:00 vita_cell: yes, I know, this project is volunteer
03:35 mupuf: "ohh I now what the TDP base clock is all about: no matter what load you have, you will always stay under the TDP" --> Didn't know you did not get that
03:56 karolherbst: mupuf: the thing was, nvidia doesn't really seem to care about it, because the "base" clock already has this meaning
03:57 mupuf: oh, sorry, I misread your sentence
03:57 karolherbst: also if you lower the power budgets, nvidia will drop below those clocks anyway
03:57 mupuf: ok, got your point
03:57 mupuf: this is indeed weird
03:57 karolherbst: yeah, maybe the PM guys were really smart, but the driver devs doesn't really care that much
03:58 karolherbst: the boost clock inside this table also doesn't affect anything
04:55 karolherbst: mupuf: I don't think I will fail cstate creation based on the voltage anymore, because when we parse the vmap table right, it is tricky to get right, so in the end pstate will print something like 300-1450, but we will end up with 1250 being the highest clock
04:57 mupuf: karolherbst: As much as possible, we should avoid this situation
04:58 mupuf: otherwise, we will have to constantly tell enthousiasts: This is an excepted behaviour and no, there is nothing wrong with our code
04:58 karolherbst: well I still do that when we limit the max clock based on the NvBoost option: https://github.com/karolherbst/nouveau/commit/db2fa4485d9739819305f87df0325f8197c737e0
04:58 karolherbst: mupuf: yeah I know :/
04:59 karolherbst: but the pstate file will move away anyway and they will complain, that the get lower clocks out of the sudden anyway
04:59 karolherbst: thing is, we don't really know what the highest possible clock will be
04:59 mupuf: it should only depend on temperature in the end :s
04:59 karolherbst: yeah, and that is the problem
05:00 karolherbst: do we know that we get the highest voltage when temp is 6?
05:00 mupuf: brb
05:00 karolherbst: or maybe some vbios is stupid and the highest voltage is for cstate 45 with 95°c, but an even higher voltage for cstate 44 with 5°C (because the vbios is stupid)
05:01 karolherbst: mupuf: well we could drop those, where each linked-summed volt.min entry is above max_uv, this is easy enough
05:04 karolherbst: this will drop 10 cstates on Tom^s card, dropping max clock from 1306 to 1176 (and nvidia clocks around 1100MHz)
05:08 mupuf: that would already help quite a lot :)
05:09 karolherbst: yeah and easy that we don't do something wrong
05:31 karolherbst: mupuf: yeah, this is really easy to do :) I just hope nobody will mind if nouveau clocks around 100MHz below that, though I think even nvidia-settings reports higher clocks
05:31 karolherbst: Tom^: can you check what is the clock range in nvidia-settings for your card on the highest pstate and what the highest actual clock is under load?
05:46 mupuf: karolherbst: it does
05:46 mupuf: ~100 MHz does not sound too bad
05:46 karolherbst: mupuf: ahh okay, because it never did for me
05:46 karolherbst: but I think this is expected on mobile chips, because the voltages are much lower
05:48 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/201c6dc9e1abcc0f4d607050eaa58df4284a20f1 and https://github.com/karolherbst/nouveau/commit/fe5960c428b423782b2e6efeb643e1ba32090413
05:49 karolherbst: thought this can be later optimized a bit if we have _stable_ entries which don't get affected by anything
05:50 karolherbst: but because we don't know for sure yet, this is good eough
05:51 karolherbst: those max voltage entries in the vmap table are a pain....
05:51 karolherbst: -- ID = 2, mode: 1 link: ff, voltage_min = 1137500, voltage_max = 1200000 [µV] c0 21467255 c1 0 c2 -97 c3 0 c4 0 c5 0--
05:51 karolherbst: temperature depending overall max voltage.. why...
05:53 karolherbst: ohhh
05:53 karolherbst: this makes actually sense
05:53 karolherbst: this entry is resonsible for the downclocks on high temperature
05:53 karolherbst: :O
07:36 Tom^: karolherbst: according to nvidia-settings, core 549 - 1306 mhz, but at highest it never goes below 980 and never above 1097 , mem is 7000 at all times.
07:38 RSpliet: Tom^: memory is not expected to change clocks between cstates, it really is a different beast. doesn't have a thermometer, no fine-grain control over voltages..
07:39 Tom^: karolherbst: just a thought, is the core clock only changing depending on the current volt set? , and the volts gets changed depending on load, temp and power budget?
07:40 Tom^: RSpliet: ah ok
07:57 karolherbst: Tom^: 980 is your base clock
07:57 karolherbst: it is the clock the gpu is on non boosted
07:58 karolherbst: your boost clock is 1045 MHz
07:58 karolherbst: which means, you should expect your gpu to boost to that
07:58 karolherbst: but the driver can do more if possible
07:58 karolherbst: 1306MHz, mhh that's high
07:59 karolherbst: that's the highest cstate
07:59 karolherbst: mupuf: seems like nvidia-settings just shows you the highest cstate
08:00 karolherbst: Tom^: mhh boosting is implemented in a way to limit your available cstates depending on temperature and stuff we don't know yet
08:00 karolherbst: through the temperature the voltages changes for each cstate and also the max possible voltage changes
08:01 karolherbst: the higher the temperature, the lower the highest voltage possible => cstates gets invalid, cause they need voltages above the max votlage
08:01 Tom^: mmh
08:01 karolherbst: I doubt load is a factor here
08:01 karolherbst: load is only important to calculate which cstate you want to have
08:02 karolherbst: it could be that power consumption is important though
08:02 karolherbst: but no idea how
08:02 karolherbst: I just now that if the power consumption goes above the power budget, nvidia clocks down
08:03 karolherbst: Tom^: try running gputest_furmark
08:03 karolherbst: I could imagine that the clock is lower with it
08:05 karolherbst: ohh do you know with which gpu I want to play around? those 128+64 bit GTX 660 (Ti)s
08:06 karolherbst: and 550 Ti
08:29 RSpliet: whoa, seriously uncool :-D if I run two instances of glxgears on my NVE7 syncing to vblank, they both run at 30fp
08:29 RSpliet: s
08:40 orbea: I get that too with my gtx 780 ti....
09:26 karolherbst: RSpliet: :O
09:26 karolherbst: RSpliet: does setting various vblank_mode values help?
09:42 karolherbst: :O
09:42 karolherbst: the SEQ script of gen1 maxwell looks really like mine from my kepler card :O
09:43 karolherbst: only minor differences
09:43 karolherbst: around 90% the same
09:43 Yoshimo: why should they re-invent the wheel each time?
09:44 karolherbst: well they usually do
09:44 karolherbst: why can't we use the kepler memory bits on fermi?
09:44 karolherbst: mupuf: wanna put your gm107 into reator?
09:44 karolherbst: I want to try something
09:45 karolherbst: hakzsam: are still both keplers in reator?
09:58 karolherbst: but this sounds great, if that just works, maybe maxwell reclocking is done
09:58 karolherbst: Yoshimo: didn't you had a 1gen maxwell card?
09:58 karolherbst: or was it 2gen?
09:59 Yoshimo: 980
09:59 karolherbst: do you setup the acceleration stuff?
10:00 Yoshimo: GM204 so it should be the second generation
10:01 karolherbst: yeah, but did you install the firmware stuff and get opengl working?
10:02 karolherbst: we could try out if the memory stuff works on your gpu if you are up to it
10:08 Yoshimo: i haven't tried yet, but we can certainly mess around with it this week just let me grab some lunch first
10:25 karolherbst: Yoshimo: yeah no problems, I would have to create a branch with a lot of patches for you anyway
10:29 Yoshimo: so you can prepare that and i will see what i can do about the new firmware stuff
10:54 hakzsam: karolherbst, yep
11:24 csb: Hello. I have a laptop with a K1000M NVidia card, and it locks up everytime I close the laptop lid.... It only occurs when Optimus is disabled via BIOS and the discrete card is enabled.
11:25 csb: I cannot get any debug logs out of kern.log or Xorg.0.logs as well. The OS doesn't post any event leading up to the lockup. Any idea on how to get more logs out of nouveau or X?
11:29 karolherbst: csb: does it happen on wakeup or before suspend?
11:31 csb: I have disabled suspend all together with closing the lid
11:32 csb: The power manager is set to lock the screen only. This does not happen if I have the intel card enabled (but I cannot run dual monitors....)
11:34 csb: OS: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux running nouveau 1.0.11-1
11:34 csb: K1000M video card on W530 Thinkpad
11:45 karolherbst: csb: ahh so the display goes out and then nothing happens anymore
11:49 csb: Well, the display stays on. The entire laptop is lockedup. I have to hard reboot the machine by holding the power button.
11:55 karolherbst: csb: can you run dmesg -w and check if new message come up before it locks up?
11:55 karolherbst: otherwise you could try to do that over ssh
12:01 karolherbst: if anybody wants to tryout maxwell recklocking, I created a branch based on 4.4 with all the needed stufF: https://github.com/karolherbst/nouveau/tree/maxwell_reclocking
12:01 karolherbst: I have no idea if that just works or not, but the memory bits look pretty similiar to kepler, so it might be worth a shot
12:22 AlexAltea: does anyone know anything about the meaning of the values in the following uint32_t blob?
12:23 AlexAltea: nv40_ctx_voodoo -> https://gma500.googlecode.com/svn/trunk/libdrm-poulsbo/libdrm-poulsbo-2.3.0/shared-core/nv40_graph.c
12:23 AlexAltea: > static uint32_t nv40_ctx_voodoo[] = { 0x00400889, 0x00200000, 0x0060000a, 0x00200000, ... };
12:23 AlexAltea: looks like magic to me, not sure what is going on
12:35 karolherbst: Yoshimo: what kernel have you running?
12:36 Yoshimo: the default of Kubuntu 15:10
12:37 Yoshimo: 4.2.0-25 or so
12:41 Yoshimo: i am still trying to fix a nameserver under linux issue so don't rush it
13:25 Yoshimo: so, fixed that, how far are you karolherbst ?
13:29 csb: I was able to record the dmesg -w output via SSH on a different computer. This is the pastebin to the output: http://pastebin.com/m9tG90A4
13:41 csb: karolherbst: strangest thing as well. I can suspend the PC with systemctl suspend, close and open the lid, and it unsuspends OK.
13:50 Yoshimo: karolherbst: ill check back in tomorrow , kernel after updates is now 4.2.0-30 , cu
13:50 csb: karolherbst: I guess suspending the system before closing the lid is as good a fix as any
13:51 karolherbst: csb: there are no nouveau errors?
13:51 karolherbst: csb: and are you sure the system is unresponsive? maybe the display just stays black
13:52 csb: karolherbst: there are no nouveau errors. The SSH connection to the laptop in question goes down.
13:54 csb: karolherbst: the screen is not black, it is frozen on whatever image was present before closing the laptop lid.
13:55 csb: karolherbst: since I am using dual monitors the other monitor remains up when the lid is closed. Sometimes responsive when the lid is closed but once the lid is opened, the system freezes.
13:57 csb: karolherbst: Maybe it isn't a nouveau driver problem? I only thought so because this issue only occurres when I have the discrete NVIDIA card enabled, not with integrated/Optimus.
14:24 karolherbst: csb: is there some kernel thread at 100%?
14:26 karolherbst: csb: well it should work nethertheless. When you have optimus enabled, intel drives the display, maybe even all of them
14:26 karolherbst: you could try if having only one display works
14:32 csb: karolherbst: I tried with one display and with all the USBs unplugged. Unfortunately I cannot know if a kernel thread is pegging the system. All open ssh connections are immediately closed. Thanks for your help through!
14:32 csb: karolherbst: It might just be one of those HW driver things that are never solved.
19:00 crocket: Does nouveau match proprietary linux driver on CUDA support?
19:07 karlmag: crocket: unless someone did some magic when I didn't pay attention lately, I believe that answer is "no".
19:41 crocket: ok
21:30 bms20: Anyone familiar with Nouveau's vdpau engine here? I'm running into kernel problems running video decoding + opengl interop rendering..