12:46 Eliasvan: tobijk: Hi!
13:00 Eliasvan: pmoreau: Hey
13:00 pmoreau: Eliasvan: Hey !
13:00 Eliasvan: pmoreau: This time I did another mmiotrace of reclocking, using the nvidia-settings tool
13:01 pmoreau: Cool :)
13:01 Eliasvan: pmoreau: The only problem is that the GUI might generate a lot of excess data because of the sensor read-outs
13:02 Eliasvan: pmoreau: Do you think developers will manage to see through the 'noise'?
13:02 mlankhorst: easy
13:02 pmoreau: Eliasvan: I guess they (we) develop some denoising functions
13:03 mlankhorst: no we just check where the reclocking stuff starts
13:03 mlankhorst: and look at the interesting parts
13:03 Eliasvan: ah, ok :)
13:03 Eliasvan: so how can you tell where reclocking starts?
13:04 Eliasvan: are there special commands only used for reclocking purposes?
13:07 Eliasvan: FYI, the easy part was that there are only 2 perf-states: low (http://oi61.tinypic.com/if9w86.jpg) and high (http://oi61.tinypic.com/j7vwgn.jpg), which were (by luck) controllable with the "Adaptive" (Low state) and "Max Perf" (High state)
13:07 Eliasvan: in case anyone is interested ;)
13:08 Eliasvan: I'll send the results to the mmio dumps mailbox, have fun with it! ;)
13:14 pmoreau: Eliasvan: I've been doing the same on my G94 to get some reclocking traces. ;)
13:14 Eliasvan: pmoreau: aha, cool :)
13:14 tobijk: Eliasvan: hey the third! :)
13:15 pmoreau: I'll have to ask RSpliet for some neat tricks about extracting useful info from then / generating useful traces
13:15 Eliasvan: tobijk: huh?
13:15 tobijk: i'm the third guy saying hi ;-)
13:16 Eliasvan: pmoreau: ah, so you also did reclocking tests by using "nvidia-settings"?
13:16 Eliasvan: tobijk: ah well, Hi!
13:16 pmoreau: Eliasvan: Yep, didn't find a better way to do it
13:16 pmoreau: (And was kinda sleepy already)
13:16 Eliasvan: pmoreau: I'm very curious whether my first way (with vbios) did work
13:17 Eliasvan: pmoreau: but I also did some interesting experiment:
13:17 pmoreau: By putting some fake perflvls in it?
13:18 Eliasvan: pmoreau: I set all the vbios perf levels, except the highest one, to 0xff,
13:18 tobijk: yeah that should give you the highest perf level
13:18 pmoreau: Ah ah ah! Ack :)
13:19 pmoreau: I guess you could check using nvidia-settings
13:19 Eliasvan: pmoreau: then I started nvidia module, then I started nvidia-settings, and to my surprise, the GUI said it managed to return from the highest state to the lowest state... How is that possible?
13:19 pmoreau: Oh
13:19 pmoreau: Was it correctly displaying the lowest state?
13:20 tobijk: and or other states?
13:20 pmoreau: (only 2 perflvls)
13:20 Eliasvan: pmoreau: And if I did "nvagetbios -c0 > vbios.rom && nvbios -p perf vbios.rom", I really say the 0xff in front of all non-highest states...
13:20 Eliasvan: it did display like this: http://oi61.tinypic.com/if9w86.jpg
13:21 pmoreau: Either it doesn't bother about the 0xff, or it maybe also check some other places
13:21 Eliasvan: yeah, I guess...
13:21 Eliasvan: nvidia should tell us!
13:21 pmoreau: :)
13:22 tobijk: have a nice time trying... ;-)
13:22 pmoreau: Meh, you can have min-max value inside a perflvl? didn't know
13:22 tobijk: pmoreau: yeah we actually support that as well already :)
13:22 pmoreau: tobijk: They do answer some times :)
13:23 Eliasvan: Another hypothesis is that the displayed perflevel in the GUI is the desired state (calculated by DVFS)
13:23 Eliasvan: but that it cant actually realise that state
13:25 tobijk: Eliasvan: just xz -9 the result and make it available
13:25 pmoreau: tobijk: Do you change between min-max simply by changing some divider rather than doing a "full" reclock?
13:25 Eliasvan: tobijk: Done: "[NVD7-GT620M]: reclocking trace, take 2"
13:26 tobijk: pmoreau: sorry i dont know, it just happens that my card has these min-max in a perflevel, so the observation is from there
13:26 Eliasvan: tobijk: check mmio.dumps at gmail dot com
13:26 pmoreau: tobijk: Ack, I hoped you were more knowledgeable about it than I am.
13:27 tobijk: pmoreau: sorry but changing some divider sounds like a acual plan :-)
13:27 tobijk: Eliasvan: i dont have access to that, i think imirkin has
13:27 pmoreau: :)
13:27 Eliasvan: tobijk: FYI, the dumps with the vbioses go under the title "[NVD7-GT620M]: reclocking traces"
13:27 Eliasvan: tobijk: Oh, that's a pity
13:28 Eliasvan: tobijk: should I make it available somewhere else?
13:28 tobijk: nah thats allright, they are not lost
13:28 Eliasvan: the trace is quite big (uncompressed 40MB)
13:29 Eliasvan: compressed 2MB
13:29 tobijk: thats pretty small actually :)
13:30 Eliasvan: ah, the traces I saw in imirkins repo were a lot smaller
13:30 pmoreau: Made some traces on plugging an external, the uncompressed one was 540MB big
13:30 pmoreau: *external screen
13:30 Eliasvan: wow
13:31 tobijk: i have an old trace which is 14mb compressed actually
13:31 pmoreau: Compressed to 25 (or 40) MB by xz -9 ;)
13:31 pmoreau: Uncompressed it should have been ~300MB
13:31 Eliasvan: pmoreau: and I've got an extra issue to deal with when running the live-iso: when passing beyond 50MB, I'm getting those "ext4 buffer" errors
13:32 Eliasvan: pmoreau: so I had to 'cat' the dumps straight into a usb-flash drive
13:32 pmoreau: Eliasvan: Hum… I'll have to dig into the extra permanent storage
13:32 tobijk: ext4 erros?
13:32 tobijk: *errors
13:32 Eliasvan: yes, apparently the ramdisk is too sensitive to 'extra data'
13:33 Eliasvan: a solution is to put the files you need into the airootfs directory, prior to compiling the ISO
13:33 mlankhorst: pmoreau: xz -9 is harmful :p
13:34 Eliasvan: but of course for live dumps, that's not an option ;)
13:34 mlankhorst: https://lists.debian.org/debian-devel/2014/09/msg00013.html
13:34 pmoreau: mlankhorst: It drinks your coffee and compresses your cat?
13:35 mlankhorst: no it just uses like 512 mb more memory for almost no compression gain
13:36 tobijk: heh that right, it is hught while unpacking :)
13:36 pmoreau: I could try on the images to see how big they are using just the default level
13:38 Eliasvan: gtg, bb!
13:39 pmoreau: See you!
13:39 tobijk: bye
13:40 tobijk: pmoreau: btw, you know if there are systems out there accessible to run the blob on recent hw? (nvc0+)
13:42 pmoreau: tobijk: No, sorry… I don't remember which cards were inside reator, and anyway, I guess it's not yet back online.
13:42 tobijk: ah allright
14:08 pmoreau: skeggsb: Ping
15:52 uriah: hello
15:56 uriah: does anyone here use an fx5700le with dual monitors? i'm just wondering whether there's a way to make it less slow... i'm using kernel 3.14.28 (because i need rt linux for audio recording), nouveau xorg driver 1.0.11, xorg-server 1.16.3, mesa 10.3.5... anything else you need to know?
15:57 uriah: oh, and libdrm 2.4.58
15:58 uriah: ...are there any kernel command-line options i can set to enable something experimental in the nouveau driver that might speed things up?
16:37 fbe: hi
16:38 fbe: is it possible to read the current clocking of my card somewhere in /proc?
16:49 tobijk: fbe: you need a recent kernel and boot it with nouveau.pstate=1, you'll find a pstate entry in "/sys/class/drm/cardN/device/" which will print out the clocks
17:03 fbe: tobijk: thanks!
18:55 uriah: tobijk: do you know whether nouveau.pstate=1 might have a negative effect on performance?
19:29 tobijk: uriah: no it does not. Actually on some cards you may reclock to another profile (experimental)
19:31 uriah: nice
19:31 uriah: tobijk: would 3.14 have these options, or should i get something >3.16?
19:32 tobijk: starting with 3.17 the pstate option is available imho, but its unlikely your fx5700 can be reclocked, whats the for a chip? nv30?
19:33 uriah: tobijk: yeah, nv36
19:38 uriah: tobijk: so i guess there's nothing that can be done atm to increase the card's performance, eh?
19:39 tobijk: i dont think so, but maybe something got fixed in newer kernels, using them is never wrong ;-)
19:40 tobijk: s/using/trying/
19:40 uriah: tobijk: unfortunately, the rt patches are only available for 3.14.25 ;) i pushed it a bit, however, and was able to fix the patches to go up to 3.14.28
19:41 tobijk: well you can try an kernel without rt to test the card for once and only invest if the nwer kernels bring you a performance boost/bug fixes
19:42 uriah: true
19:42 uriah: i might
21:16 imirkin: uriah: iirc nv3x doesn't have reclocking support on nouveau
21:17 imirkin: uriah: nv4x does though
21:18 uriah: hmm, ok
21:18 uriah: that's unfortunate :)
21:18 uriah: and i guess "it'll be ready when it's ready" ;)
21:18 imirkin: uriah: tbh, nv3x is in a pretty crappy state wrt 3d support... and that's very unlikely to change
21:19 uriah: oh, i don't really care about 3d
21:19 uriah: i just want proper 2d accel
21:19 imirkin: although it _ought_ to be fairly simple to get reclocking to work on there
21:19 imirkin: i don't think you had to change memory or anything clocks... just a few register writes here and there
21:19 uriah: http://nouveau.freedesktop.org/wiki/PowerManagement/
21:19 skeggsb: istr that those usually come up at full clocks anyway
21:20 uriah: reclocking is mostly done
21:20 uriah: skeggsb: really? cause, well, something's not right then
21:20 imirkin: uriah: that page is _very_ misleading
21:20 uriah: lol, k
21:20 imirkin: and/or incorrect, depending on one's mood
21:21 skeggsb: "mostly" also depends on what you mean by mostly :P
21:21 imirkin: skeggsb: it implies that something works but not everything
21:21 imirkin: in fact, that more things work than not
21:22 skeggsb: not "the code is mostly written but probably won't work" ?
21:22 skeggsb: :P
21:22 uriah: :>
21:22 imirkin: skeggsb: well, it's all defined at the top of the page...
21:22 skeggsb:is just being an idiot
21:23 imirkin: :)
21:23 imirkin: skeggsb: what's the latest on GM204 btw?
21:23 skeggsb: latest news is, shockingly, no news
21:23 skeggsb: no response to my last pings on a few things..
21:24 imirkin: did you ever try to upload the blob graph code?
21:24 skeggsb: yes, nvidia sent me their blobs, but forgot that, well, you can't upload them without PMU's help..
21:24 skeggsb: and, i don't have those blobs
21:24 imirkin: ah... i meant via traces
21:25 imirkin: but... easier to just wait on them. plenty of other things :)
21:25 skeggsb: PMU's doesn't show in traces, and I somewhat suspect you can't read it back anymore when in heavy secure mode
21:25 imirkin: how does it get uploaded?
21:25 skeggsb: system memory i presume
21:25 imirkin: oh, via dma from the card
21:26 imirkin: i remember now... you mentioned it.
21:26 skeggsb: the situation is... extremely frustrating
21:27 imirkin: presumably you could trace the thing that tells the card to do dma
21:27 skeggsb:will work on atomic and mst in the meantime
21:27 skeggsb: yeah, probably by hacking up mmiotrace some more i could do something
21:27 skeggsb: but
21:27 skeggsb: that's pointless, because noone else is likely to want *that* pain
21:27 imirkin: right
21:28 skeggsb: i guess there's always finding them in nvidia.ko, wherever they're hidden away now
21:28 imirkin: yeah :(
21:29 imirkin: well, something else productive, but much much much harder would be the recovery stuff :)
21:29 imirkin: MST seems more fun since you get to play with big monitors
21:29 skeggsb: there is *also* the possibility that i *can* use nvidia's fecs/gpccs blobs somehow even without pmu firmware and i'm just screwing up somehow
21:30 skeggsb: uploading through imem/dmem mmio definitely doesn't work though
21:30 skeggsb: buuut all these questions i've asked, and had no answers to :P
21:30 skeggsb: i'm loathe to waste time figuring it out myself when it's entirely likely it's impossible and the hardware will just say "fuck you"
21:31 imirkin: esp when there's other things to be done
21:36 skeggsb: yeah, plus i've already spent a *lot* of time playing with it, and i'm very angry about the whole thing :P
21:37 imirkin: i don't suppose switching to kepler reclocking would help...
21:38 skeggsb: that's also annoying, but at least bogus "security" restrictions aren't getting in the way there ;)
21:39 imirkin: didn't you say you matched what the blob was doing and it still didn't work?
21:40 skeggsb: yes, but i know why - i need to figure out a whole heap of magic isohub values to get a "safe to switch memory frequency" signal to our PMU ucode
21:41 imirkin: oh
21:41 imirkin: didn't realize you had gotten that far
21:41 skeggsb:has been doing work, despite what the git log looks like :P
21:43 imirkin: haha
21:43 imirkin: i'm sure you have been :)
22:22 mlankhorst: morning
23:05 tagr: skeggsb: anything in specific I could ping people about?
23:06 mlankhorst: skeggsb: hm any idea why I get psychedelic colors with my skip vt switch patch?
23:06 mlankhorst: the display initializes correctly, but I get a really weird color pattern with tons of garbage/noise
23:07 skeggsb: tagr: lots of things ;)
23:07 skeggsb: tagr: nah, the primary concern is an update on what's happening with ucode releases
23:07 skeggsb: mlankhorst: hm, lut not being reloaded correctly would be my first guess
23:08 mlankhorst: oke
23:08 mlankhorst: well that's probably right
23:08 mlankhorst: if vt switch works correctly for me mind if I resubmit that patch?
23:10 skeggsb: it's something that'd be nice to have working, i didn't even realise it was possible tbh
23:10 mlankhorst: me neither
23:10 tagr: skeggsb: I seem to remember some recent internal email, let me check
23:10 mlankhorst: I found out about it by helping debug some userspace touchpad driver
23:10 skeggsb: haha random
23:11 mlankhorst: on optimus setups it worked, but on pure intel there was no vt switch :P
23:11 mlankhorst: so it broke during suspend/resume
23:11 mlankhorst: hm can I move the nv50_crtc_lut_load from display_create to display_init ?
23:12 skeggsb: without looking, probably. i'd say we're currently depending on fbcon to do the reload
23:12 mlankhorst: not even fbcon directly
23:12 mlankhorst: the vt switch to fbcon
23:14 mlankhorst: hooray, it works
23:18 skeggsb: i don't suppose you can test on a non-evo board too?
23:18 skeggsb: so <=nv4x
23:20 mlankhorst: I'll give it a shot
23:25 tagr: skeggsb: generally there seems to be progress, but not sure how much I can say at this point
23:26 tagr: a rough plan has been made to address the situation of firmware distribution and people are working on making that happen
23:26 skeggsb: tagr: alright, good to know there's something happening at least. thank you for looking :)
23:26 tagr: there's a bunch of things that need to be done to internal infrastructure and RM
23:26 tagr: skeggsb: for your immediate needs you only need the PMU blob?
23:27 skeggsb: yeah, i figured you might have to change a few things in resman to split them out. i'm going to have to rework a heap of stuff to be able to properly use yours too :P
23:28 skeggsb: i think so, i was talking with Robert at one point about that, but he disappeared after mentioning that the FECS/GPCCS upload sequence has changed
23:28 skeggsb: which, as far as i currently understand, is where PMU comes in
23:31 tagr: skeggsb: yeah, I vaguely remember something about the device now loading in the firmware itself
23:32 tagr: I think there's a sort of tiny bootloader that gets uploaded which then loads the large blob because it's faster that way
23:32 tagr: or perhaps that's how it works today already?
23:32 skeggsb: you guys switched to that model at some point, yeah
23:32 tagr: gnurou: maybe you know more about this ^^
23:33 tagr: skeggsb: I'll send off an email internally and see if we can at least give you the blobs and some pointers
23:33 tagr: skeggsb: being ignorant as I am, anything in particular that you need to know in addition to the blob?
23:34 skeggsb: on gm204 it looks like: make some call to PMU (presumably for the secure handshake thingo, and to load a bootloader to FECS/GPCCS), fill in some info in dmem, hit the go button
23:34 gnurou: vinceh should know the most about PMU stuff, since he worked directly on it
23:35 skeggsb: tagr: enough of the interface to PMU to be able to upload FECS/GPCCS will be fine for the moment, though, i think it's likely i can decipher that from traces myself if necessary
23:45 mlankhorst: skeggsb: hm getting a null pointer deref in pram_fini with nv4c on module load
23:46 skeggsb: drm-fixes has a fix
23:46 mlankhorst: ok
23:46 mlankhorst: I'll rebase then, thanks :)
23:59 mlankhorst: skeggsb: looks like my nv43 just works