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