00:14mlankhorst: yay msi's not the source of bugs any more :P
00:19mlankhorst: 0xffffffff usually means there's no card at all..
00:19mlankhorst: and it fell off the bus somehow
01:40FunkyBob: so, I was trying to follow the instructions for how to extract the firmware so I can get acceleration on my GTX750
01:41FunkyBob: but the details on the page linked to seem to refer to a bunch of tools I can't find a source for
06:46mlankhorst: FunkyBob: envytools.git probably?
09:14hakzsam: where should we submit patches for piglit? on dri-devel?
09:30mupuf: imirkin: hey, you still have your nvc1 plugged in?
09:30mupuf: I would love to have a dump of your nvio and therm reg space
09:31mupuf: nvapeek e000 1000 > nvc1_nvio
09:32mupuf: nvapeek 20000 1000 > nvc1_therm
09:33imirkin: mupuf: nvio - http://hastebin.com/ekejawekev.sm
09:34imirkin: mupuf: therm - http://hastebin.com/eloqiwibak.md
09:35imirkin: i'm actually less convinced now that fan control works...
09:35mupuf: try manual fan management
09:35imirkin: it's hard to tell :)
09:36imirkin: yeah i thought of that :p
09:36mupuf: and see if increasing the speed slowly produces a smooth increase in noise
09:36imirkin: no change in noise
09:36imirkin: there's various noise coming from my comp
09:36imirkin: which may drown out the video card noise
09:36imirkin: however that noise may *be* the video card noise
09:36imirkin: so... yeah. need to figure it out.
09:37imirkin: it's a teeny little fan
09:37imirkin: when i first plugged it in it made 0 noise
09:37mupuf: and those tend to make a ton of noise
09:37imirkin: (and i visually verified that it was spinning)
09:37imirkin: and then... something happened
09:37imirkin: and my computer started making a lot more noise
09:37imirkin: now that i think about it, it _could_ have been a kernel upgrade
09:37mupuf: well, easy to check
09:38mupuf: stop the fan with your hand
09:38imirkin: that tends to break the fan
09:38mupuf: not if you press in the middle
09:38imirkin: coz it gets misalined
09:38imirkin: yeah, if you hit the middle *precisely*
09:39imirkin: what's the alternate way of slowing it down... i can try it and see if that noise goes away
09:39mupuf: no need to put too much pressure
09:39mupuf: touching it will slow it down a lot
09:39imirkin: let's be clear - i'm not doing that :p
09:39mupuf: you can alway try to change the values in e118
09:39imirkin: right... what should i write?
09:39imirkin: it has 144 in there right now
09:39mupuf: nvapoke e118 800000xxx
09:39imirkin: and xxx = ?
09:39mupuf: with xxx being a value between 0 and 21c
09:40mupuf: 21c should stop your fan
09:40mupuf: 0 should be max speed
09:40imirkin: no change in noise for any of those
09:41imirkin: i'm fairly sure it's another fan making all the noise
09:41mupuf: that is interesting
09:41mupuf: those fan can be NOISY
09:41mupuf: the other one must make one hell of a noise
09:42mupuf: do you have a mmiotrace of your nvc1?
09:42mupuf: if so, can you check what are the values of e114/8
09:42imirkin: don't think i ever did that
09:42mupuf: to make sure nouveau is doing the right thing on your card
09:42imirkin: anyways... this is a quiet fan
09:42imirkin: i know which little noisy ones you're talking about
09:42imirkin: this is a different one
09:57mupuf: imirkin: you may just have a fan like the one I have
09:57mupuf: basically, fixed speed
09:58mlankhorst: ah connected to a constant power supply instead of a pwm?
09:59imirkin: mupuf: i thought you got your fan speed to change
09:59mupuf: mine, yes
09:59imirkin: mupuf: also fwiw i don't have an RPM counter (in case that wasn't obvious)
09:59mupuf: well, I have more than one nvc1
11:01pmoreau: Does anyone want to have a look at the EVO patches for rnndb or can I push directly to envytools?
11:03imirkin: where did the info come from?
11:03imirkin: was it from that nvidia pull req?
11:06pmoreau: The released docs from mid-January
11:06imirkin: i remember that pull req
11:06imirkin: i'd rather mwk check it for sanity of rnndb-ification
11:07imirkin: do you have a link to your commit somewhere?
11:07pmoreau: I was hoping for that when I did the pull request, but... It didn't get any comments.
11:08pmoreau: I need to push the last ones
11:08imirkin: yeah.... welcome to the real world
11:09imirkin: you need to annoy people so that it becomes easier for them to just do the thing you want rather than listen to your annoyingness :)
11:09imirkin: (but not so much that they /ignore you)
11:09imirkin: it's a delicate balance
11:09pmoreau: Right, but as I hadn't finished all patches, I was not so much of a problem
11:10imirkin: i remember you used a lot of groups and whatnot
11:10imirkin: i dunno if that was wise... but maybe. dunno
11:11pmoreau: I only created groups to avoid information duplication
11:13imirkin: yeah that makes sense
11:13imirkin: why was there such duplication in the first place though?
11:13imirkin: could it have been avoided in other ways?
11:14pmoreau: It's just that between the different channels, between PIOR, SOR and DAC, you get the same regs, bitfields, values
11:14imirkin: yeah those are fine to have as groups
11:18pmoreau: I pushed the patches here: https://phabricator.pmoreau.org/diffusion/ENVY/history/merge_evo/
11:18pmoreau: I splitted them in one patch per channel
11:19imirkin: mwk: do you think you'll have time to take a look?
12:53mwk: imirkin: let's see
13:00pmoreau: Groups' name are not that consistent and probably need to be changed, but I couldn't figure out anything better.
13:01mwk: ok, first major thing...
13:01mwk: we have "TILED" and "LINEAR", they have "BLOCKLINEAR" and "PITCH"
13:01mwk: so... what shall be done about it?
13:02pmoreau: Is PITCH equivalent to TILED?
13:02mwk: TILED = BLOCKLINEAR
13:03mwk: oh, btw
13:03mwk: nah, never mind
13:04pmoreau: I went with using the NVidia names rather than the ones that were already present in the nv_evo file.
13:05mwk: yes, but
13:05mwk: eventually we'll need to make it uniform
13:05mwk: this may mean converting the whole rnndb to BLOCKLINEAR and PITCH
13:05pmoreau: I have to admit I barely searched for already defines group, except for wh15 ones and some others.
13:05imirkin: we use the names tiled/linear everywhere... i'd rather keep it as-is for now
13:06imirkin: this whole renaming of stuff really messes things up btw... now i can't just use these files as-is for mesa
13:06imirkin: without changing all the code there too
13:06pmoreau: I wanted to convert envytools to NV50 and GT200 rather than G80 and G200; would that be ok?
13:07mwk: pmoreau: no. consistency.
13:07mwk: I'm not sold on G200 vs GT200, there are conflicting informations from nvidia
13:07mwk: but G80 is called G80 everywhere
13:08pmoreau: That was the ones I saw in the EVO doc
13:08mwk: yeah, strange...
13:09mwk: they usually use G80
13:09imirkin: mwk: from what i've gleaned, i think they called it NV50 internally, and switched to G84
13:09pmoreau: I will revert to g80 and g200 in my patches then, for consistency
13:10imirkin: the G200 vs GT200 thing is definitely confusing
13:10mwk: eg. the whole nv driver used G80
13:10imirkin: the chip says G200, but i think they even called it GT200
13:10mwk: I can't figure out if the T should be there or not
13:10imirkin: (and pci.ids has it as GT200, not that that's an authoritative source)
13:10mwk: it's certainly less rename work than G80
13:34mwk: pmoreau: ok, I think I'm done
13:35mwk: I might've missed a thing or two, it's a huge thing
13:36pmoreau: Indeed, it took some time to add it. :)
13:39mwk: there's also a load of inconsistencies with rnndb conventions
13:39mwk: all addresses should be _ADDRESS for instance
13:40mwk: for some reason they're called _ORIGIN here
13:40mwk: but oh well
13:40mwk: or was it _ADDR, I forget
13:40mwk: anyhow, good job
13:40pmoreau: Arg, I should have pushed it back where you could comment on; the version you commented wasn't completely up-to-date :( My bad
13:41mwk: don't worry, we'll be doing round two anyway
13:41pmoreau: Eh eh!
13:42pmoreau: Thank you for the comments anyway, I'm sure they pretty much all apply on the newest verion! ;)
13:44pmoreau: Should I push new patches and correction patch to the same pull request - does GitHub manage it nicely? Or should I create a new pull request?
13:45mwk: I have no idea
13:47pmoreau: Well, I'll push new patches to the separate branch on my repo and see how the pull request deals with it.
13:49pmoreau: There is no CPST_* COMP_* values for DAC protocol on GF119+ in the EVO doc.
13:51mwk: good enough for me
13:52pmoreau: For the inline="yes" thingy, I added that because it was in another parts of rnndb. O:-) And also because it is needed if the group / bitset / enum uses a variant
13:53pmoreau: I'll go back to modify it and answer the comments directly on GitHub, it will be easier.
13:55mwk: it's not, actually
13:55mwk: you just have to attach varset="chipset" to let it know what varset to use
13:59pmoreau: Oh, ok
14:00pmoreau: But if it's only for part of them?
14:11Yoshimo: i wanted to send an mmio dump but the file is too big, are they even usefull?
14:12mwk: pmoreau: still.
14:12mwk: Yoshimo: depends on the card
14:12mwk: if it's something new and/or rare, it's quite useful
14:12mwk: otherwise, not so much
14:12Yoshimo: MSI Geforce 980 Gaming 4G, rather new
14:13pmoreau: mwk: Will try that then :)
14:17Yoshimo: mwk: would that help? 85MB is something where my Thunderbird says "too big"
14:18imirkin: Yoshimo: you can xz -9
14:18imirkin: that usually gets it down to a couple MB
14:19Yoshimo: it was 180 before archiving it
14:19imirkin: xz -9 should be able to at least 10x compress it...
14:21Yoshimo: maybe i hit the wrong level
16:05pmoreau: mwk: I pushed the missing commits + some fixes to your remarks. I just realised I forgot to remove the GET and PUT, I'll do that later.
18:18jrayhawk: Creme de la crime against an ALIG and you're still sticking with a jeep?
18:18jrayhawk: whoops, wrong room