01:12imirkin: nouveau E[ PGRAPH][0000:02:00.0] M2MF 0x80000003
01:12imirkin: do we know what this means?
01:54AndrewR: ha, found default calibration values in nvclock sources!
01:55huehner: Hi, i am playing wihh my gm206 nouveau again (4.3-rc4 kernel) and we some warnings when switching off/on again connected hdmi display (http://pastebin.com/raw.php?i=rA3LFQ0X), note only happens with hdmi not with vga connected to dvi
01:58huehner: which seems to point to some locking issue:
01:58huehner: WARN_ON(!mutex_is_locked(&mode_config->mutex) &&
01:58huehner: something known or should i report it?
02:01imirkin: huehner: doesn't sound familiar
02:02huehner: on the good side 4.2 -> 4.3-rc4 improved gm206 slightly even, before i had some vertical 1 pixel 'pink line' leftmost on hdmi which is now gone :)
02:03imirkin: cool. that pink line is an issue that happens when we get the aviframe stuff wrong
02:03imirkin: or, you know, totally forget about it
02:03imirkin: which i think was the case for gm20x
02:16huehner: imirkin: looks i'm too late for the locking warning https://bugs.freedesktop.org/show_bug.cgi?id=92307
02:16AndrewR: http://www.fpaste.org/277534/ - does this looks sane? (nvclock used slightly different equation, correction was directly used, without this "-8", I hope nouveau code is more correct
02:16imirkin: huehner: oh well, maybe next time
02:18imirkin: huehner: perhaps chime in with a "me too" and mention that it's easily reproducible by doing XYZ?
02:19huehner: just did that already
02:22AndrewR: damn ...I forgot kernel will not allow float values :/ . lets round them ....
03:05Wildefyr: what's the latest x version that works with nouveau?
03:27AndrewR: hm, adding printk in constantly-called function was bad idea. But then, hacked-in values from nvclock apparently working.
03:30karolherbst: mupuf: is there a way to feed pstate and cstate information into perf_init
03:31AndrewR: http://www.fpaste.org/277555/ -current hack
03:32karolherbst: AndrewR: slope is an int
03:32karolherbst: that's why 792/1000 doesn't work
03:34AndrewR: karolherbst, surprizingly-enough compilation with naive use of float types for both worked, but then I saw warnings at modpost, and recalled exacly recent talk here
03:34karolherbst: yes, it will be 1 or 0
03:34karolherbst: I am not sure which
03:34karolherbst: but I think 0
03:37karolherbst: AndrewR: is this a desktop gpu?
03:37AndrewR: karolherbst, yes
03:38karolherbst: 80°C is really hot
03:38karolherbst: did you try to clean it?
03:38karolherbst: or at least to check if it is really that hot?
03:39karolherbst: sometimes the sensors can simply break
03:39AndrewR: karolherbst, but at least this high temp not caused by non-working (non-rotating) fan ... I tried to change its speed and it responded :} sure, it needs some fixing, but for this I'll need to move things on table ..so, I prefer to use it at low clocks for now.
03:40AndrewR: may be next week ...
03:40karolherbst: ohh, so the fan doesn't get adjusted to temp?
03:41AndrewR: karolherbst, under nvidia it says 'variable' or something like this (user-controllable in theory, but how??). Under nouveau I think it uses info from vbios, and this info says at any perf level it must be 100%
03:42hakzsam: imirkin, cool, I'll have a look at the patches later today
03:42karolherbst: AndrewR: coolbits
03:42AndrewR: karolherbst, but may be this 'fan table parse failed' in my dmesg also hints at something
03:42karolherbst: AndrewR: which driver version are you using?
03:42karolherbst: for blob
03:42hakzsam: imirkin, did you see the patch which fixes compute class for gf110, btw?
03:44AndrewR: karolherbst, ah, ok, will play with this . libglx.so.304.88 - so I think 304.88 :) (surprizingly it survived xserver update 12.3 -> 14.3)
03:45karolherbst: AndrewR: When "4" (Bit 2) is set in the "Coolbits" option value, the nvidia-settings Thermal Monitor page will allow configuration of GPU fan speed, on graphics boards with programmable fan capability.
03:46AndrewR: karolherbst, ok, thanks
04:54pmoreau: Ok, so now that I don't add inputs of size 0, nv50_compute_upload_input seems to take care of them :D
04:58pmoreau: I guess I need to use the nv50_context.globals[x].handle as an offset to the input pointer
04:59pmoreau: It should be similar to how inputs in GLSL are handled in the TGSI -> NV50 IR
05:22Wildefyr: so am I to gather that the 970 isn't covered yet by nouvera? at least by the stable branch?
05:56karolherbst: Wildefyr: 970 is second gen maxwell
06:08Wildefyr: karolherbst, curenntly getting unknown chipset: NV124, the driver loads fine but it the reports the dreaded no screens
06:08karolherbst: yeah, second gen maxwell needs signed firmware from nvidia
06:08karolherbst: which aren't released yet
06:08Wildefyr: oh wow
06:08karolherbst: but basic modesetting should work
06:09karolherbst: you will need a pretty recent driver for that kind of gpu
06:09karolherbst: Wildefyr: linux 4.2 may be fine, but if not you can still compile from current master
06:10karolherbst: you won't get hardware acceleration though
06:10Wildefyr: karolherbst, no problems, I'm on linus kernel git tree and a source based distro
06:10karolherbst: that's weird
06:10karolherbst: because linus kernel git tree should recognize the NV124 :/
06:10karolherbst: what is your current version?
06:11Wildefyr: 4.3.0-rc4 for kernel
06:11Wildefyr: 1.0.11 for nouveau
06:11karolherbst: the nouveau version looks really odd
06:11karolherbst: it should be 1.3 for 4.3
06:11Wildefyr: what's the latest?
06:12karolherbst: or do you mean the X driver?
06:12Wildefyr: the x driver
06:12karolherbst: ohh no worries
06:12karolherbst: do you get the error inside the X log?
06:12Wildefyr: yeah, let me paste bin the output for you
06:12karolherbst: you should use the modesetting driver
06:13Wildefyr: which is where?
06:13karolherbst: it is built in in the latest X release
06:13Wildefyr: ah ok
06:13karolherbst: just remove the nouveau driver
06:13karolherbst: and if you use a X config, which you should not, replace nouveau with modesetting :D
06:13Wildefyr: so get rid of the userland x nouveau driver?
06:18Wildefyr: hm, well this is isn't going smoothly ^^
06:27derstrom: Hello. I'm on Debian 8 (Linux 3.16.x) which has pretty poor support for NV117. I installed the fglrx drivers to do an mmiotrace and moved the resulting firmware files into /lib/firmware/nouveau. I've reverted to the nouveau driver and the firmware is not being loaded. dmesg reports fuc409c as failing to load (-2).
06:27derstrom: I'm not sure what to do at this point!
06:35pmoreau: derstrom: You could upgrade to a newer kernel version
06:35pmoreau: 4.1 should have acceleration support for your card
06:36derstrom: I tried kernel 4.1.x that was available in Debian stable backports which was fine but it never let me go past the GNOME login screen.
06:38derstrom: Sadly I might need to either wait until 2017 for the next Debian stable release or use the fglrx driver :-(.
06:38pmoreau: You never got past the login, which means it crashed before? Do you have any logs from that test?
06:39derstrom: Yes it crashes at the point of trying to login. The login screen actually displays fine but when attempting to login, that is when it crashes.
06:40karolherbst: Wildefyr: what went wrong?
06:41Wildefyr: karolherbst, I got it worked now, but I can't seem to open any rxvt-unicode windows
06:41Wildefyr: or xterm windows
06:41karolherbst: Wildefyr: how do you start X?
06:42karolherbst: you can always go a tty and start applications from there
06:42karolherbst: you only need to set DISPLAY=:0
06:42Wildefyr: I got dmenu2 working fine
06:43Wildefyr: it just won't load them, nor sxhkc bindings work
06:43pmoreau: derstrom: It could be great if you could grab the logs from when it crashed
06:43karolherbst: Wildefyr: okay, but that isn't a nouveau issue anymore then :)
06:43pmoreau: I don't recall if there were any fixes for GM1xx in 4.2 or 4.3
06:43Wildefyr: haha perhaps not karolherbst
06:45derstrom: pmoreau: yes I realise I should have grabbed some logs at the time. I'll look into getting those logs and filing a bug report.
06:47pmoreau: If you can't find 4.2 on debian repos, you can try some images here: https://nouveau.pmoreau.org/
06:47derstrom: latest in backports is 4.1
06:54Wildefyr: best way to get the temperator of the gpu karolherbst ?
06:56karolherbst: Wildefyr: sensors
06:56karolherbst: I mean the command ;)
07:17karolherbst: mupuf: sadly I didn't found the file on reator :/
07:18karolherbst: I bet I can use nvkm_pmu_send to retrieve some data
07:29karolherbst: nice, it works :D
07:50AndrewR: this time patch a bit more real
07:52RSpliet: mupuf: ^
07:53karolherbst: mupuf: if you want to take a look: https://github.com/karolherbst/nouveau/compare/8797739f79bd41fa9eaab4777078637b3677c7f3...master_karol
07:53karolherbst: mupuf: this reports loads between 0 and 255
07:59RSpliet: AndrewR: your VBIOS does not seem to contain this information you added "manually"
07:59RSpliet: or, not where we expect it
08:00RSpliet: possibly it takes hard-coding like you proposed, but the patch is likely to look slightly different
08:01AndrewR: RSpliet, ok, thanks for looking into it
08:03mupuf: RSpliet, karolherbst: i'm back
08:04mupuf: AndrewR, RSpliet: We used to have hardcoded values
08:04mupuf: but not anymore
08:05mupuf: the guy who made nvclock did not get that those values wrong
08:05mupuf: sorry, I mean, chip-dependent
08:05mupuf: not chipset
08:05AndrewR: mupuf, ah ....
08:05mupuf: starting from nv84, nvidia started putting those values in fuses
08:06mupuf: before that, each vbios was unique
08:06mupuf: I guess what we need is to find the exact same coefficient as what the blob uses when there are no coefficients
08:07mupuf: AndrewR: you do not have access to our vbios repo, right?
08:07AndrewR: mupuf, no (nor I can use it in any meaningful way )
08:08mupuf: well, we could look for an average values found on our vbioses
08:08mupuf: and use that one as a default
08:08AndrewR: mupuf, this was my plan, but in absence of any data I looked around and found nvclock :}
08:10AndrewR: mupuf, also, adding some one-time warning might be useful - I added printk and it spammed my console
08:11mupuf: the kernel has this capacity already
08:16AndrewR: mupuf, I just need to learn how to call it, or may be use those nvkm_ macro
08:18AndrewR: mupuf, they not worked in 'random' places by default (completely understanable), so for quick debugging of my voltage problem I just used printk . In once-called parsing functions it worked ok.
08:32mupuf: AndrewR: sorry, I'm back
08:33mupuf: http://paste.pound-python.org/show/aEd5Nl5fhGtEyDhUwJaA/ <-- have fun
08:43RSpliet: mupuf: is the offset num expected to be a large negative value in some cases?
08:43mupuf: RSpliet: yep
08:44mupuf: tested and verified
08:44mupuf: the format changed on nv43 IIRC
08:44karolherbst: mupuf: saw my stufF?
08:44mupuf: karolherbst: yes!
08:44mupuf: it looked ok
08:44mupuf: as i said, in the end, the code looks kind of the same, doesn't it? :D
08:44karolherbst: I disliked your approach to send multiple methods to the falcon just to get all counters
08:45karolherbst: well, there are some API/ABI differences ;)
08:45mupuf: hmm, I did not check that
08:45karolherbst: but I got to lern how to code the falonc
08:45karolherbst: basically I write into data
08:45karolherbst: 0xff000000 pcie, 0x00ff0000 memory, ...
08:45karolherbst: and just report the load on a 0-255 scale
08:46mupuf: ... you should definitely not handle the communication this way :D
08:46karolherbst: also I don't need your mul_32_32_64 function
08:46mupuf: first, you need to poll the counters without the help of the host
08:46karolherbst: I just shr 8 the ticks and div by that
08:47karolherbst: mupuf: I do
08:47mupuf: the host may want to read the values too
08:47karolherbst: this is just for a debugfs interface
08:48mupuf: and I think the way I handled this was just to let the host map the memory of the process, can't really remember
08:48mupuf: since I can update atomically the entire word
08:48mupuf: and that meant no back and forth
08:49karolherbst: mhh okay
08:49karolherbst: I just had the dyn reclock thing in mind while writing the code
08:49karolherbst: I didn't thought of a reason, why the host wants to have the counter values directly
08:49karolherbst: I also need to send some pstate/cstate information to the falcon
08:49mupuf: I really do not see what you could simplify in my code though
08:49karolherbst: max pstates/cstates, max cstate for each pstate
08:50mupuf: why would you?
08:50mupuf: you do not need this information
08:50karolherbst: because I can calculate the next pstate/cstate on the falcon
08:50karolherbst: or should I just check some thresholds and let the host do that?
08:50mupuf: just check the thresholds and send an IRQ when you need to upclock/downclock a perf domain
08:51mupuf: you definitely do not want to do anything more in assembly code :D
08:51karolherbst: to be sure about that, I need at least the max amount of pstate/cstates
08:51karolherbst: or I have to change my algo
08:51karolherbst: well my current algo needs that
08:51karolherbst: cur_cstate += ((load_core - load_tar_core) * cstate_count) / (load_tar_core + (100 - load_tar_core) / 4);
08:51mupuf: you just need to not send another irq until the host tells you that it changed the frequency
08:52karolherbst: mhh right, I also need this
08:53mupuf: what I suggest is to have a int8 that represents how far you are from the target (which has a histeresis)
08:53mupuf: and let the host decide what to do
08:53karolherbst: I could try to find an algo which doesn't need the max amount of pstates/cstates
08:53karolherbst: mupuf: I don't want to bother the host every 0.1 secs though
08:53mupuf: you can keep this algo in the kernel space
08:53mupuf: of course you do not want that :)
08:54mupuf: but as I said, you should not fire another IRQ unless there is an actual change
08:54karolherbst: but I don't mind to code anything more complex in assembly :D
08:54mupuf: do not send two times that you need to downclock one perf domain until the driver tells you : OK, I did change the performance of this domain
08:55mupuf: so you say :D
08:55karolherbst: have to cook some food, I will think about that, maybe I will get a really smart idea or so
08:55mupuf: have fun!
08:55karolherbst: mupuf: sometimes the load is pretty volatile
08:55karolherbst: and we wait long time before we downclock
08:55mupuf: spurous you mean?
08:56karolherbst: like quick loading screens in game
08:56mupuf: what do you mean by volatile?
08:56karolherbst: stuff like that
08:56karolherbst: not exactly bursty
08:56karolherbst: maybe jumpy
08:56mupuf: this is the typical case
08:56karolherbst: like target is 70, and the load moves between 65 and 75
08:56karolherbst: what should the falcon doi then?
08:57karolherbst: request uplock, /downclock all the time?
08:57mupuf: didn't I say hysteresis?
08:57mupuf: nvidia definitely uses one
08:57karolherbst: I really would like to see their algo :D
08:57mupuf: and before coding too much, we need to create this test bench
08:58mupuf:will NAK almost everything until we have it
08:58mupuf: this is the most performance-critical thing we are working on, we need the proper tooling to actually check it
08:58mupuf: and nvidia will kill us if we screw this up!
08:58karolherbst: why? :D
08:59mupuf: because we are not going to have thousands of algo
08:59mupuf: and they want to support tegra
08:59mupuf: on nouveau
08:59karolherbst: I meant, why will nvidia kill us?
08:59mupuf: because their customers would complain?
08:59Wildefyr: do any of the nouveau devs get funded at all?
09:00karolherbst: mupuf: you mean for tegra?
09:00mupuf: Wildefyr: no, but we do work together
09:00mupuf: karolherbst: yes
09:00RSpliet: mupuf: is there a reason why (seemingly) all GPUs with no slope/offset values have a MAX 6649 listed in their EXTDEV table?
09:00Wildefyr: mupuf, shame
09:00Wildefyr: but alsa yay!?
09:00mupuf: RSpliet: hehe, that sounds liek a reason :D
09:00karolherbst: mupuf: I saw their current algo, and that one isn't that smart
09:01mupuf: Wildefyr: they do pay one engineer to work on it almost full time
09:01mupuf: karolherbst: it is one they proved on their testing rif
09:01Wildefyr: well that's something I suppose
09:01Wildefyr: 1 guy!
09:01RSpliet: mupuf: now go and fix :-P
09:01karolherbst: mupuf: the one in the nouveau tegra code
09:01mupuf: karolherbst: I understand :)
09:02mupuf: I don't mean to be rude or to slow you down, I just want you to understand the implication of your work
09:02karolherbst: I know
09:02mupuf: I really value your work and I want to thank you for it!
09:02mupuf: but I will not accept cutting corners when it comes to this
09:03karolherbst: no problem for me
09:03karolherbst: I am only worried if there is no nitpick on my patches :D
09:03Wildefyr: does anyone know what kernel the propietary driver was working on last? I want to just have a separate kernel to go to if I need to do something graphically intensive, although I think I will be using nouveau a lot more now
09:04karolherbst: Wildefyr: you could always use bumblebee and a really nice config setup
09:04mupuf: noooo!! I will have to head downtown to buy an hdmi cable for the jetson!
09:04Wildefyr: karolherbst, no go if
09:04karolherbst: Wildefyr: I have both (nvidia and nouveau) installed and can switch between them in seconds
09:04Wildefyr: I want to have a git rolling kernel
09:05karolherbst: but I also have a laptop, so that's cheating
09:05karolherbst: 4.1 works with blob
09:05Wildefyr: although that's a pretty cool use of bumblebee there
09:05karolherbst: Wildefyr: I don't use bumblebee for nouveau though
09:05karolherbst: the daemon is still running, but it doesn't do much
09:05Wildefyr: my mistake
09:06karolherbst: the nouveau ddx driver is the part with the biggest pain to get that working
09:06karolherbst: 1. dri3 only, 2. the x server isn't allowed to open any fd from the nouveau ddx
09:07karolherbst: mupuf: but you have nothing against the idea to use 0-255 scale instead of 0-100?
09:07karolherbst: it makes the assembly code much easier
09:08karolherbst: though I could divide by 100 :/
09:08karolherbst: but a shift is faster I assume
09:09RSpliet: quite a bit faster, I don't think the falcon has a hardware divider
09:09karolherbst: the doc says 30-33 cycles
09:09karolherbst: for div
09:09karolherbst: RSpliet: ohh div is since v3
09:10RSpliet: ah right
09:11karolherbst: I was wondering if there is a div SD S combination
09:11mupuf: RSpliet: there is a divider
09:11mupuf: it just takes 32 cycles
09:11mupuf: all the other instructions take 1 cycle
09:11mupuf: even mul u16*u16
09:11karolherbst: mupuf: I do four divs :/
09:12RSpliet: mupuf: v3+ only, I don't know if that includes Tesla
09:12mupuf: karolherbst: why do you even care?
09:12karolherbst: mupuf: don't know :D
09:12karolherbst: it is assembly, you _have_to_ optimize it to the last :p
09:12karolherbst: but that makes my code pretty unusable on tesla cards
09:12karolherbst: RSpliet: fermi
09:13RSpliet: karolherbst: 2nd gen Tesla
09:13karolherbst: ohh right
09:13karolherbst: I would need to change the code if I want to use that on 1st gen tesla
09:13karolherbst: is it even possible?
09:14mupuf: karolherbst: no
09:14RSpliet: 1st gen doesn't have PDAEMON at all
09:16mupuf: well, no hdmi cable == no fun with the jetson tonight!
09:16karolherbst: mupuf: have some copper? :D
09:16mupuf: I may work on wtrpm though, to be able to reboot the board
09:17karolherbst: I really would like to do stuff like div $r2 $r1
09:18karolherbst: mupuf: what would be reasons to change the period of the counter reads?
09:18mupuf: consuming less power?
09:18karolherbst: does the falcon draw that much?
09:21mupuf: it does draw
09:25karolherbst: mupuf: okay
10:52karolherbst: mupuf: are there any good theories about creating good benchmarks for dyn reclocks?
10:53mupuf: yes, we need to make apitraces of multiple benchmarks
10:53mupuf: we may not need to for xonotic and unigine benchmarks
10:53karolherbst: okay, and then just run them at max perf vs dyn perf?
10:53mupuf: but we do not it for browsers
10:54mupuf: we need to set how much we accept to lose
10:54karolherbst: and if perf is like 0.5% different it is "okay"?
10:54mupuf: but there is more to it
10:54mupuf: we need to also track how much power we save
10:54mupuf: and that is hard
10:54karolherbst: couldn't we just track which cstate is selected?
10:55mupuf: I guess we could use the voltage as an indicator
10:55mupuf: and only use this one
10:55karolherbst: maybe we could also use the load as a factor
10:55mupuf: you can't
10:55karolherbst: they are some boards for which we can messure the power though
10:55mupuf: because the load depends on the frequency
10:56karolherbst: yeah I know
10:56mupuf: yes, for long benchmarks, it would work, you are right
10:56karolherbst: but on lower load we draw less power
10:56mupuf: yeah, let's do that
10:56mupuf: well, what is better, higher freq but lower load or lower freq and higher load?
10:56karolherbst: do you know if the gpu can collect the power consumption over time somehow?
10:56mupuf: if you can model that, you are the kind of the world :D
10:56karolherbst: mupuf: we don't really know
10:57mupuf: you'll need to integrate it
10:57mupuf: I know we cannot know
10:57karolherbst: in the second version maybe, I don't want to factor also the power consumption in really
10:57karolherbst: we can just assume to be stupid and say: lower cstate less pwoer
10:57karolherbst: lower load, less power
10:57mupuf: not without the RTL and characteristics of the transistors used
10:58mupuf: the load is constant, we make sure of this by making apitraces
10:58mupuf: or using fixed-time benchmarks like xonotic
10:59mupuf: or we should cap the rendering
10:59mupuf: but it is imperfect
10:59karolherbst: we also need benchmarks with high cpu load
10:59mupuf: for example, in the browser case, we really need to have a real time test
10:59karolherbst: where the gpu load is not 100%
11:00mupuf: I wonder if we should not use another method involving downloading the content of a website in local
11:00mupuf: then putting the browser full screen
11:00karolherbst: there are cases, where the gpu will run on like lower cstate, highest pstate and still can't get more perf out of an applicatio
11:00mupuf: and recording the actions of the user
11:00mupuf: and then replay them when we plan on testing the consumption
11:01karolherbst: we should really get the power consumption into the kernel somehow :/
11:01mupuf: yes, but let's use the actual power usage that we integrate to get the average power consumption throughout the benchmark
11:01mupuf: yes, we will need it
11:01mupuf: let's add a kernel-space version of it this week end?
11:01karolherbst: at least I have patches for core voltage already :D
11:02mupuf: I will be plugging the jetson to wtrpm tonight and tomorrow I can work on finishing up my patches to expose the inaXXXX on nouveau
11:02karolherbst: I also planned to add memory voltage, but is this even possible?
11:02mupuf: no, we won't need all this
11:02karolherbst: just say no, I remove that and you could add your stuf fon top of mine :D
11:03mupuf: we will only run the benchmark on devices that have power readers
11:03karolherbst: yeah, but I also want to add support for the vore voltage, unrelated to this
11:03karolherbst: just for debugging
11:03karolherbst: because there are just too many cards where this stuff is semi broken somehow
11:03mupuf: to read it bck?
11:03karolherbst: to have it in perfmon
11:04mupuf: oh, sweet idea, being able to track the frequency in the gallium HUD
11:04mupuf: freq, voltage and other parameters
11:04mupuf: hakzsam is going to love the idea ... NOT :D
11:04mupuf: those are cpu-synchronised anyway, so polling it from the userspace is enough
11:04karolherbst: https://gist.github.com/karolherbst/b20bc4c8183a7277646a *cough*
11:05karolherbst: power is a fake value though
11:05mupuf: yes, you are right, we should expose it through sysfs
11:05karolherbst: any idea how to get the memory voltage?
11:05mupuf: it is a gpio
11:05karolherbst: I know
11:05karolherbst: but I don't kow which voltages are mapped to it
11:05mupuf: that's all we know
11:05karolherbst: so I remove that
11:06mupuf: well, find the datasheet of GDDR5 and see if there are 2 voltages specified
11:06mupuf: pretty sure you will get the info there
11:06mupuf: good luck finding doc on them
11:06karolherbst: mupuf: fyi I need this: https://github.com/karolherbst/nouveau/commit/877a9aac4087ec3a2712e00d84c9a88b8ccb39f2
11:06karolherbst: otherwise voltage is too low
11:07karolherbst: I mean, it still works in like 99% of all cases
11:07mupuf: in the mean time, /me found how to start/stop the jetson with gpios
11:07karolherbst: but this is much more safe
11:07mupuf: and read the power state
11:07mupuf: just need to plug that into wtrpm
11:07mupuf: I hope it works because the voltages are MUCH lower than on ibm-compatible computers
11:08mupuf: the power LED should be fine
11:10karolherbst: mupuf: will you need this? https://github.com/karolherbst/nouveau/commit/ff9fe00939fd2e52ea3a51ce93aec8ad1acfb826 :D
11:12mupuf: yes, I will
11:13karolherbst: I have something more usefull though
11:16karolherbst: mupuf: I did the hwmon bits for the power consumption already here (+ this patch + core voltage in hwmon): https://github.com/karolherbst/nouveau/commits/hwmon
11:18mupuf: ok, I can take those
11:18karolherbst: the hwmon interface is a bit too implicit for me :/ you just have to know how to name those files :D
11:28mupuf: don't get me started on hwmon
11:40mupuf: ok, so I can boot the jetson from wt-rpm ... but the LED state is not updated
11:40mupuf: let's see if I can make this work by changing a resistor :s
11:42mupuf: yeepee!!! the jetson is working as expected!
11:43mupuf: I just plugged the led input to the wrong pins
11:45karolherbst: oh maybe I should do something with my arm dev board here
11:54mupuf: ok, can't go any further without an hdmi cable, it would seem
11:55karolherbst: mupuf: do you know any way to check if nouveau supports reading out the core voltage before doing so?
11:55mupuf: if the volt subdev is there, then it is supported
11:56karolherbst: mhhh, I would like to say yes, but it is not the case, at least not for the card in use
11:56karolherbst: chipset yes, card maybe
11:56karolherbst: like on my card I also had a volt subdev even though pwm voltage wasn't supported
11:57karolherbst: I could juse call nvkm_volt_get
11:57karolherbst: and if the result is an error, the driver can't do that
11:57karolherbst: before actually adding the hwmon entries
11:59karolherbst: but this is kind of ugly
11:59karolherbst: would be nice to have some kind of check, which can also be called inside init, and on failure we could print a warning or something
12:00mupuf: yes, you can try to read the voltage
12:00mupuf: I do that for reclocking too
12:01mupuf: hmm, there is a serial console!
12:01mupuf:will be able to make something of this board even without the hdmi cable
12:01karolherbst: pmoreau: there?
12:01pmoreau: karolherbst: Nope
12:02pmoreau: What can I do for you?
12:02karolherbst: you are lucky you have the same color as mupuf has :D
12:02karolherbst: pmoreau: just test if the voltage entry doesn't show up for on of your gpus
12:02pmoreau: Interesting! :-)
12:02pmoreau: In sensors?
12:03imirkin: Wildefyr: GM20x modesetting has been supported since 3.19 -- if you're seeing unsupported chipset NV124 then you're booting a kernel older than that.
12:03karolherbst: you hade one gpu with N/A
12:03karolherbst: imirkin: the message was in the X log
12:04karolherbst: does 1.0.11 ddx still support gm20x?
12:04pmoreau: karolherbst: And using which version of Nouveau?
12:04imirkin: no ddx supports it. use modesetting.
12:04pmoreau: Cause right now, I have nothing related to voltage in sensors. Not even N/A
12:04imirkin: which it should fall back on automatically btw
12:05pmoreau: imirkin: He was using 3.15 or 3.16 iirc :-)
12:05karolherbst: imirkin: his X started to start after the nouveau ddx was removed
12:05karolherbst: he just had some X problems after that
12:05karolherbst: like xterm not starting automatically
12:05imirkin: ah ok
12:05pmoreau: Oh, no, I mixed with someone else
12:06karolherbst: pmoreau: these patches: https://github.com/karolherbst/nouveau/commits/hwmon
12:06karolherbst: the last two
12:07karolherbst: maybe I should switch the order of them :/
12:08pmoreau: Ok. I need to continue working on some project, but I'll test those before going to sleep.
12:08karolherbst: okay, thanks
12:08pmoreau: Just want to progress on some things, and then make sure to save everything before reloading Nouveau
12:09pmoreau: (though it should work, without any troubles, and I could do it right now, but... computers sometimes...
12:12karolherbst: okay, so I've updated the branch
12:12karolherbst: pmoreau: you only need this now: https://github.com/karolherbst/nouveau/commit/a36204c43374d34fde84db2fe2e0ef0a599b1fa2
12:13karolherbst: pmoreau: though it was more likely that my older version crashed your kernel :D
12:14pmoreau: I'm happy I waited before testing it! ;-)
12:14karolherbst: you already did
12:14mupuf: ok, serial console time now
12:14karolherbst: guess why I know you can only read out voltage on one gpu
12:14mupuf: let's go and dig the serial to usb adapter from the graveyard of electronics
12:15karolherbst: mupuf: I have some of these number leds if you need some :D
12:15karolherbst: ohh wait, even a 4x6 dot matrix
12:15mupuf: that would not be too helpful :p[
12:16karolherbst: sorry, it is a 5x7 one :D
12:16karolherbst: and a rgp led!
12:17karolherbst: I bought a lot of stuff, because I was htinking someday I will play with it....
12:17karolherbst: even a pressure and a light sensor...
12:21karlmag: number leds? 7-segments?
12:22karolherbst: wow, even found some shift registers
12:22karlmag: hook up a couple to read out the voltage? *ducks*
12:23karlmag: quite standard
12:23mupuf: so typical :p
12:23karolherbst: I even have an ATMEGA328 :p
12:24karlmag: think I have a tube or two of the 595s :-P
12:25karlmag: hehe.... no arduino around it?
12:25karolherbst: right, then I have two
12:25karolherbst: but the one is without the arduino
12:26karolherbst: ahh there is my arm board
12:26mupuf:has fancy hw here, sw-defined radios :D
12:26karlmag: rpi? *ducks*
12:30karolherbst: I think
12:30karolherbst: not sure
12:30mupuf: ah, good stuff!
12:30mupuf: I have a bunch of those
12:31mupuf: I started writing an OS for them, mostly based on macros
12:31mupuf: so as the generated code would be as small as possible
12:31karolherbst: I have such a serial to usb adapter by the way:p
12:31mupuf: function calls are horrible :s
12:31mupuf: and all the setup does not deserve it
12:31mupuf: you could change the clocks on the fly with it :D
12:31karolherbst: I just were coding my C on that stuff
12:31karolherbst: fun times
12:32mupuf: yep, a very very simple hw
12:32mupuf: but veru well designed one!
12:32mupuf: the cc430 was a tad harder
12:32mupuf: because of the radio
12:32mupuf: but gosh is it good
12:32mupuf: if I had time for this, I would spend hours on it!
12:33karolherbst: sadly the board doesn't have that many gpios :/
12:34karolherbst: I tried to built that into a mp3 player or something
12:34karolherbst: but it is a lot of work
12:34hakzsam: imirkin, I'm not sure if the GF110 really supports that 0x91c0 class. Did you see that dmesg fail btw? Instead, I would prefer to make a patch which forces GF110 to use that NVC0_COMPUTE_CLASS in the first time, do you agree?
12:34imirkin: hakzsam: did you rebuild your kernel/
12:34imirkin: hakzsam: kernel has to know about the class
12:35imirkin: maybe it really is 92c0 then :)
12:35hakzsam: yes, I know
12:35hakzsam: but I'm sure I updated my kernel
12:35hakzsam: I'll try with 92c0
12:36hakzsam: mupuf, are you using reator?
12:36mupuf: nope, still need to plug what you asked me to
12:36mupuf: gf110 + kepler/
12:37imirkin: hakzsam: make sure to update your kernel as well
12:37hakzsam: I'll double check
12:38mupuf: hakzsam: done
12:38hakzsam: mupuf, let me known when reator is ready
12:38hakzsam: very fast :)
12:38mupuf: yeah, it only took me 2h
12:38mupuf: or let's say 1
12:39hakzsam: that's good ;)
12:40karolherbst: a thing I was always wondering about: do all these windows nvidia vbios overclocking hacky tools have any relation to nouveau?
12:46hakzsam_: mupuf, did you forget to plug the GF110? because I only see the kepler
12:47mupuf: nope, it's there
12:47mupuf: let's try again
12:50hakzsam_: okay, fixed
12:53mupuf: well, that is dumb
12:53mupuf: they indeed have a serial port on the jetson
12:53mupuf: but ... it is a male connector!
12:54mupuf: why is it male? The typical one is female!
12:54mlankhorst: serial port is male..
12:56mupuf: so, we are supposed to have a cable to connect to the serial-to-usb adapter?
12:56mupuf: it looks like you are right though
12:56mupuf: that sucks :D
12:57mlankhorst: a null modem cable probably to connect it. :P
12:57mupuf: well, I guess I will have to make one then...
12:57hakzsam: imirkin, so, what do you think of using 0x90c0 for all Fermi chipsets?
12:57imirkin: hakzsam: fine by me
12:58mlankhorst: mupuf: I think I came to the same conclusion a few months ago :)
12:58mupuf: I only have one female connector here though
12:58karolherbst: mupuf: one thing: nouveau tries to set my fan, allthough it doesn't change anything. I doubt that the gpu can control its fan, but there is this fan GPIO
12:59mupuf: so I will have to improvise with single female-male wirses
12:59mupuf: karolherbst: if the vbios says it has the fan, how nouveau can know if it is plugged or not?
13:00karolherbst: can't the gpio tell?
13:01imirkin: karolherbst: gpio isn't some magic thing. just lets you set voltage high or low :)
13:02imirkin: (or to read in whether voltage is high or low)
13:03karolherbst: mhh right
13:06pmoreau: Ok, time to test those patches
13:06mupuf: Linux tegra-ubuntu 3.10.24-g6a2d13a #1 SMP PREEMPT Fri Apr 18 15:56:45 PDT 2014 armv7l armv7l armv7l GNU/Linux
13:06mupuf: here we go
13:07pmoreau: 3.10 ???
13:07hakzsam: imirkin, http://pastebin.com/raw.php?i=SYKtBPAV R-b ?
13:09karolherbst: pmoreau: android kernel I think
13:09karolherbst: these are kind of "old"
13:09pmoreau: Wow! It's at least equivalent to a debian ultra-stable
13:10imirkin: hakzsam: sure
13:10karolherbst: there is good stuff in the android kernel though
13:10imirkin: at least that's the new one
13:10karolherbst: but you don't want to pick that, because that means porting them :D
13:10imirkin: and not the older 3.4 one
13:10karolherbst: right, my phone is still on 3.4
13:10mupuf: pmoreau: you mean, debian-ultra-dusty?
13:10pmoreau: mupuf: Ssshhhhhhh! ;)
13:11imirkin: mine too =/ and as a result won't be getting an android 6 upgrade because they're lazy sob's
13:11hakzsam: imirkin, thks
13:11mupuf: they should rename stable into dusty :D
13:11karolherbst: imirkin: aren't you using cm?
13:11imirkin: karolherbst: no, but even if i were, that wouldn't change the situation
13:11karolherbst: mhh right, the cm guys are also kind of lazy :D
13:12imirkin: karolherbst: it's a ton of vendor drivers that would need porting
13:12karolherbst: at least your "system" will only take 20% of the space it does with stock rom
13:12imirkin: meh. seems to fit just fine for now
13:12hakzsam: imirkin, and what about the patch which fixes the wrong value of NVC8_COMPUTE_CLASS? I know we don't use it anymore but this could prevent some future fails if someone wants to use it and if the value is still 0x92c0..
13:12karolherbst: I really hate those stock roms
13:12karolherbst: fully reminds me on bought windows computer/laptops
13:12imirkin: hakzsam: we need to determine if the right value is 91c0 or 92c0
13:12karolherbst: it is just worse on a phone
13:13imirkin: karolherbst: meh, the nexus 4 stock rom is fine
13:13karolherbst: ohh right
13:13imirkin: and my policy is to never touch the onboard storage of arm devices :)
13:13karolherbst: why not
13:13karolherbst: it is a lot of fun
13:13imirkin: easy to brick
13:13imirkin: and i need this thing to work
13:13karolherbst: ohh okay
13:14hakzsam: imirkin, well, pretty sure it's 0x91c0 but we need to make sure of it before using it
13:15hakzsam: imirkin, otherwise, the patch which makes use of 90c0 should be mesa-stable, right?
13:16imirkin: hakzsam: if it'll make you feel better. i don't think anyone enables NVC0_COMPUTE=1 :)
13:17hakzsam: yeah, except me :p
13:17imirkin: hence "if it'll make you feel better" :)
13:26karolherbst: any other stuff you always wanted to have exposed via hwmon? :D
13:26karolherbst: despite power consumption there is nothinhg which comes into my mind
13:35pmoreau: Ok, got the patched version running
13:37pmoreau: karolherbst: I have a power1 for both cards, and a GPU core only on the discrete (G96)
13:37karolherbst: pmoreau: you used my branch right?
13:38karolherbst: okay, nice, then it seems to work
13:38karolherbst: the volage changes depending on the pstate I guess?
13:38pmoreau: Probably, I should test :D
13:40pmoreau: Reclocking failed O.O
13:41karolherbst: pmoreau: my branch isn't based on upstream master
13:41pmoreau: Oh!!! You only took the pci patches but not the ones before!
13:41pmoreau: So you don't have the patch from Roy fixing the reclocking regression
13:42karolherbst: You could simple use the one commit on top of your stuff :p
13:42karolherbst: I am still at 4.1 kernel, and I can't really use nouveau master
13:49karolherbst: pmoreau: okay, but at least the voltage entry doesn't show up for your other card, which means nouveau can't revolt that one
13:51pmoreau: Oh, the integrated one? Then that means I also need Roy patches on top to reclock the discrete one
14:08pmoreau: karolherbst: GPU core does change upon reclocking
14:16pmoreau: Anything more to test?
14:17karolherbst: pcie doesn't work on your cards, so no :p
14:27mupuf: gnurou: thanks for your scripts to generate the image for the jetson!
14:28mupuf: and thnaks for having support for arch!
14:29mupuf: too bad it takes forever to clone all the repos
14:29mupuf: and one is particularly slow, ~60kB/s
14:30mupuf: given the size, I would say it is the linux kernel
14:31imirkin: mupuf: fwiw he gave me a script to boot a kernel image directly over usb-otg
14:38pmoreau: The EXT_TAG is also present in the PCIe v1 spec
14:38pmoreau: Have to check in the PCI spec now
14:39karolherbst: I should start to clean up my patches
14:39karolherbst: and make a plan what I want to land when :D
14:40mupuf: imirkin: I wish my bios would run in 200ms like the tk1's
14:40karolherbst: rc4 currently
14:40karolherbst: when is drm merge window?
14:41mupuf: karolherbst: you missed it
14:41karolherbst: for 4.4?
14:41mupuf: rc5 is released tomorrow, and that is usually when dave airlie pressures ben to release his tree :D
14:41karolherbst: so for 4.4
14:41mupuf: given he was very late for the last pull, I would sayhe will not do it again :D
14:42mupuf: and especially not for power management stuff :)
14:42karolherbst: didn't plan anything for 4.4 except the gddr5 patch
14:42mupuf: just work regardless of the linux cycles
14:42mupuf: stuff will land whenever it will
14:42karolherbst: I see
14:42mupuf: the important part is that everything is in ben's repo
14:43karolherbst: I still want to have some rough schedule for myself
14:44karolherbst: okay, what have I done anyway all the time :D
14:44mupuf: gnurou: awake?
14:44mupuf: it is a bit early for you to change nick ... on a sunday morning!
14:45karolherbst: stop stalking him :p
14:45mupuf: can't we stalk friends anymore? :o
14:46karolherbst: that's exactly the problem, you _think_ he is your friend, that's why it is stalking :p
14:47mupuf: ah ah
14:47pmoreau: skeggsb_: I can't seem to find the EXT_TAG in the PCI spec, and according to Wikipedia there are some Tesla that are PCI only.
14:47mupuf: not the same kind of worrysome behaviour I was pretending to have, but that's also a good one
14:48pmoreau: skeggsb_: So, probably best to keep the check in the patch.
14:51mupuf: at this download rate, it won't even be finished by the time I wake up ... let's move on to the power sensors
14:51karolherbst: mupuf: +1
14:52karolherbst: I still need some volunteers for my pcie patches on tesla (g9x+)
14:52karolherbst: I can somehow test fermi myself, but I also would like other to test on more fermi stuff
14:53karolherbst: anyway that is the stuff I am working on somehow: https://gist.github.com/karolherbst/14d4b018899017ed9a70 if somebody wants to help with anything just ask :D
14:53mupuf: karolherbst: you know you can request GPUs for reator, right?
14:53mupuf: right now, there is a gf110
14:53karolherbst: mupuf: I did :p
14:53mupuf: which is quite a beast
14:54karolherbst: is hakzsam still working on it?
14:54mupuf: you asked and I did not plug it?
14:54mupuf: nope, but I am now
14:54mupuf: reator is for me first :p
14:54mupuf: and for every other dev the rest of the time
14:54karolherbst: mhh I am not quite sure now, it was the time where you were a lot away, so
14:55mupuf: oh, sure, I couldn't plug anything when I was in canada or france
14:55mupuf: reator 2 should have more slots
14:56mupuf: that should help with this kind of issues
14:56mupuf: hey, I have been thinking a little
14:56mupuf: it will be hard to run benchmarks on the jetson
14:57mupuf: because X is not supported, only weston/wayland environments
14:57mupuf: I could use gnome 3 and xwlayland
14:57karolherbst: since when do you need a proper DDX for xwayland?
14:57mupuf: well, it has a perf impact :D
14:58mupuf: there is a massive difference between xwayland and native wayland :D
14:58karolherbst: doesn't the jetson use kms?
14:58mupuf: at least for xonotic
14:58mupuf: not by default
14:58mupuf: they use their own kernel
14:58karolherbst: maybe glamor and kms are good enough
14:59karolherbst: wayland without kms?
14:59mupuf: dom't worry, I am installing an upstream kernel
14:59mupuf: the jetson recently got upstream support
14:59mupuf: there is also the problem of having a driver for rendering and one for doisplay
14:59mupuf: which makes it fun :p
15:00mupuf: nouveau is only for rendering on the jetson
15:01mupuf: not sure how gnome will cope with this
15:01karolherbst: it won't :p
15:04glennk: cooling shouldn't be much of an issue during finnish wintertime
15:07karolherbst: well I am not living in finnland, but during winter my home is usually warmer than in spring or autumn :/
15:07imirkin: mupuf: afaik mlankhorst made a good amount of progress with it
15:07imirkin: mupuf: in theory, modesetting + glamor should work just fine
15:08imirkin: mupuf: in practice, not sure
15:08mupuf: imirkin: ack, good to hear
15:08karolherbst: mupuf: so if you are nice enough, I need a tesla g9x+, maybe two of them
15:08mupuf: glennk: you would be surprised how they overheat flats here
15:09mupuf: so, before going to bed, I need to plug that
15:09karolherbst: will do a lot of pcie fun then :D
15:09glennk: mupuf, well, hang server from window
15:10mupuf: glennk: hehe, I have a balconny that could serve that purpose
15:10mupuf: speaking about this, I should probably not leave the rc plane on the balcony
15:10mupuf: it is very cold now
15:11karolherbst: I would like to merge this: https://github.com/envytools/envytools/pull/21/files because I doubt I will get mroe out of these regs
15:11karolherbst: and I already use them in my pcie patches
15:12karolherbst: ohh right, another point for my todo: pcie width changes - very low prio
15:18mupuf: name of my patch to add power sensors support: 0001-giant-pile-of-shit.patch
15:19karolherbst: fair enough
15:20mupuf: and, of course, I forgot to add the new files inside :D
15:20mupuf: well, at least one
15:20mupuf: anyway, I was pretty-far along
15:20mupuf: I had forgotten that I had to add support for 16-bits transactions over i2c for this
15:21mupuf: the ina3221 requires it
15:21karolherbst: you said something about a pdaemon script or so
15:21mupuf: this version will be done without pdaemon
15:22mupuf: whenever we introduce the pdaemon version, the kernel should refrain from polling on its own
15:22mupuf: otherwise, fun happens
15:23mupuf: IIRC, there is a way to physically disconnect the host from the i2c lines whenever pdaemon uses the gpios
15:23karolherbst: sounds good
15:23mupuf: I mean, a GPIO port
15:23mupuf: well, it is not good since the transaction will fail "D
15:24karolherbst: mupuf: hwmon wants the power consumption in uW (for whatever reasons)
15:24karolherbst: just that you know
15:34mupuf: I know
15:34mupuf: it is a good idea
15:56karolherbst: mupuf: we could also implement an avarage value through hwmon, I just don't know if that's a good idea when the hardware can't do that
16:00mupuf: it is not
16:02karolherbst: mupuf: anyway, will go to bed now, will you push your changes on your freedesktop reporitory or somewhere else? I really would like to test it :D
16:03mupuf: I will, tomorrow
16:04karolherbst: okya, thanks :)
23:33AndrewR: imirkin, speaking about my mesa bug (GLexcess demo via wine on nv43). Sadly, I recompiled mesa with --enable-debug and got this on stdout: "Mismatched color and zeta formats, ignoring zeta."