01:09mwk: imirkin_: not really
01:09mwk: but it can do some crazy format conversion thing
01:10mwk: that can result in expansion of a line by some small PoT factor
01:10mwk: crazy == piss-poor and I dsubt it's actually good for anything
01:41hakzsam: mwk, okay, I'll merge the PR
01:41hakzsam: imirkin_, mmh? I don't think
01:50hakzsam: imirkin_, weird, why gcc doesn't warn about this because clang does...
03:03karolherbst: mwk: okay, I think something is wrong with the nva code: the vbios gets written into [0x700000, 0x700000+vbios_size), but if I poke anything into 0x700000 the value stays 0xffffffff
03:03karolherbst: any idea what that could be?
03:11mwk: karolherbst: what is 1700?
03:11mwk: if it's set up properly, then apparently VRAM is not initialized
03:11mwk: well, something's wrong with VRAM
03:11mwk: not POSTed?
03:12karolherbst: ohh wait, I should do that before, right
03:12mwk: karolherbst: your goal is to get nvidia.ko to read an alternative vbios, right?
03:12mwk: then do the following
03:13karolherbst: posting helps actually
03:13mwk: first, figure out the size of your VRAM
03:13karolherbst: 00700000: 00000055
03:13mwk: then, stuff (size of vram - 1MB) >> 16 to 1700
03:13karolherbst: and 1700 gets bfff
03:14mwk: and stuff (size of vram - 128kiB) >> 8 | 0x9 to 619f04
03:14mwk: and then try nvafakebios
03:15mwk: so bfffe09 to 619f04... hm, sounds stange, let me see
03:15mwk: karolherbst: 1700 should get bff0, 619f04 bffe09
03:15karolherbst: two or three fs?
03:15mwk: that's 3GB-1MB
03:16karolherbst: nvafakebios turns 1700 into bffe
03:17karolherbst: but maybe that's okay
03:18karolherbst: my computer is still running
03:18karolherbst: okay, now I try that after only posting the gpu
03:19karolherbst: the card has to be posted
03:20karolherbst: mupuf: the card has to be posted, otherwise it may crash the computer
03:20karolherbst: mwk: okay, any way to POST the gpu through userspace?
03:30mwk: karolherbst: no, you have to load a driver
03:30mwk: I'd *really* love to have a tool for that in envytools, but... that's quite some work
03:30karolherbst: okay, can at least be checked if the gpu is posted?
03:30karolherbst: because then we could just quit if a posted card is required
03:30mwk: userspace nouveau may work
03:30karolherbst: better than a crashing machine
03:30mwk: I tend to check if PFB is enabled in PMC.ENABLE in hwtest
03:31mwk: I'm not sure how reliable it is though
03:31karolherbst: would be nice to have a function like nva_is_posted
03:31mwk: iirc there's something in PDISPLAY that's supposed to be a post status
03:31mwk: or at least that nouveau use as such
03:46mwk: ugh ffs
03:46mwk: [560697.842509] nvidia 0000:04:00.0: Invalid ROM contents
03:46mwk: the sysfs doesn't allow me to read the PCI ROM if it happens to have invalid sig
03:47mwk: why can't I just map the damn memory range and read it...
03:48karolherbst: can't it be done through pciaccess?
03:49mwk: pciaccess uses sysfs to access memory
03:50karolherbst: ohh right
03:50mwk: ah, fuck
03:50karolherbst: maybe kernel a kernel module then?
03:50mwk: I crashed the machine
03:56karolherbst: wierd, nvidia still doesn't read the new vbios :/
03:57mwk: try stuffing bff0 back to 1700 after nvafakebios?
03:57karolherbst: it is set to bff0
04:02karolherbst: mwk: 0x700000 is empty..
04:03karolherbst: or is this normal?
04:03mwk: try 7e0000
04:05karolherbst: but when I poke with nvapoke the value gets set
04:08karolherbst: when nvafakebios executes this "nva_wr32(cnum, 0x1700, old_bar0_pramin);" the content is gone
04:09karolherbst: okay, then I statically set 1700 to bff0 and never change it
04:10karolherbst: ohh now 0x700000 got changed by nvidia
04:13karolherbst: mhh yeah, the uploaded vbios gets a bit changed
04:14karolherbst: ohh wait, no, that was me being stupid
04:14Yoshimo: karol, what are you trying to accomplish in the end?
04:15karolherbst: faking the vbios so that nvidia sees a different vbios than what on the card
04:46karolherbst: mwk: okay, there is still something wrong. current situation: after posting 1700 is bff0, 619f04 is 0x1. Then I poke 619f04 bffe09 and nvafakebios pokes bffe into 0x1700, uploads the vbios, sets 1700 back to bff0
04:47karolherbst: still the new vbios doesn't get picked up
04:47karolherbst: but I get "NVRM: RmInitAdapter failed! (0x24:0x65:1140)" and "NVRM: rm_init_adapter failed for device bearing minor number 0" in dmesg
04:49karolherbst: okay, reading out the vbios again is a bit messed up
04:50karolherbst: mwk: first 0x10000 bytes are okay later bytes are not
05:05mwk: karolherbst: it appears nvafakebios uploads only 0x10000 bytes of bios
05:05mwk: this should be bumped to 0x20000 for G80+ cards
05:09karolherbst: it is working
05:09karolherbst: mwk: thanks a lot for your help
05:09karolherbst: mupuf: I managed to fake my vbios :)
05:11mwk: karolherbst: please push the size fix to envytools
05:11mwk: if card_type >= 0x50
05:11karolherbst: already working on it
05:11mwk: it'd also be good to auto-fix the upload address in 619f04 if empty
05:12karolherbst: is there a clamp C function?
05:12karolherbst: ohh max
05:12karolherbst: ehhh min I meant
05:12mwk: we might have a macro in utils.h
05:12mwk: but not sure
05:14mupuf: karolherbst: I have seen that! Well done!
05:15Tom^: you guys are doing some astonishing work the past couple months , jeez. just dont burn yourself out. =D
05:16karolherbst: mwk: https://github.com/karolherbst/envytools/commit/40d107e95fa59eb946b74cdeeb22a754db798ffd
05:16karolherbst: the argument is wrong :D
05:18mwk: yeah, it is
05:18karolherbst: fixed: https://github.com/karolherbst/envytools/commit/6615b0afb801689e7d191ee871e21307887e1c0f
05:18mwk: ship it
05:21karolherbst: k, now 619f04 has to be set and we need to check if the card is posted
05:21karolherbst: mupuf: do you know a way to check if a gpu was posted?
05:43karolherbst: mupuf: is there anything you already collected for the voltage stuff? Because I want to figure the voltage stuff out then on my gpu
05:46mupuf: karolherbst: oh, cool!
05:47mupuf: have a look at the code of the GK20A
05:47mupuf: and try to map that to the values in the table
05:48karolherbst: good idea
05:48karolherbst: the code in nouveau or android?
05:56karolherbst: by the way, the dirt benchmark somewhat worries me
06:27joi: karolherbst: https://lists.freedesktop.org/archives/nouveau/2016-February/023996.html looks relevant
06:58karolherbst: joi: ohhh that looks interessting
06:58karolherbst: 0x0 after powered on, 0x2 with nvidia loaded
06:59karolherbst: gnurou: please document the 0x2240c mmio address as far as possible :)
07:02karolherbst: sadly that it only works for gf100+ gpus :/
07:04karolherbst: mupuf: when I figure out the voltage thing, would it be fine to limit the gpus to the non-boost clock until we figure out the power budget thing?
07:18karolherbst: mupuf: this tegra stuff is just a thing you shouldn't be able to read :/ There are bogus "speedo" values read out from the hardware from somewhere and then a mv value is calculated from that, somehow :/
07:30karolherbst: okay, when we have temp = 0, the stuff gets a lot easier: mv = c0 + (c1*speed) / scale
07:30karolherbst: where scale is 100
08:09karolherbst: mupuf: I can effect the voltage :)
08:09karolherbst: I directly disabled the part which reacts to the temperature
08:10karolherbst: now the voltage is the same for 1°C and 95°C :)
08:27karolherbst: mupuf: okay, my findings: every pstate has a minimum voltage (pstate volt entry ids)
08:27karolherbst: the driver won't ever set a voltage lower than those
08:28karolherbst: and I even get the same voltage as nouveau would set
08:28karolherbst: 0.8mv => 0x20 pwm
08:29karolherbst: this is with temperature effect removed
08:41karolherbst: nice nice
08:41karolherbst: I can get the blob to set the voltage nouveau would set :)
08:42karolherbst: mupuf: the offset nouveau is missing seems to be completly something like base + temp * _something_
08:42karolherbst: or more like volt_min + temp* _something_
08:47karolherbst: and the linked voltage entries also effect this too
08:48karolherbst: so basically we parse the table right already, we just don't respect what we don't know yet
09:02RSpliet: karolherbst: good stuff
09:31karolherbst: ohh wait, I think it is more complicated than this (or simplier)
09:34karolherbst: these rows are typed
09:35karolherbst: first byte: 0x0 non-temp voltage, 0x1 temp voltage
09:39karolherbst: if the row has the first byte set to 0x1, the voltage is affected by the temperature
09:39karolherbst: otherwise the row seems static
09:45imirkin: mwk: yeah ok, that's what i figured. gallium has a big of a wart in its api regarding mapping MS surfaces, was hoping i could get away with doing something very dumb, but probably i'll have to do something less dumb.
09:53karolherbst: okay, when c0 is 0, the min voltage is used and when c2 is 0 the max voltage is used. c0 is 524288 and c2 is -29
10:14karolherbst: okay, if mode is 1, then depending on the temperature the voltage gets increased by a value inside [volt_min,volt_max] depending on the other parameters inside that voltage map entry
10:15karolherbst: so if volt_min==volt_max the voltage gets increased by that value, otherwise it gets calculated
10:20karolherbst: c0 seems to be some kind of linear offset, because it somehow moves the actual voltage linearly: https://gist.github.com/karolherbst/07a84189825f0b02d083
10:30karolherbst: and c2 tells us how big the voltage change is
10:30karolherbst: makes sense somewhat
10:31karolherbst: so this is a function of type Ta + b clamped by min/max
10:33imirkin: so... does that mean you have to keep changing voltage as temp changes?
10:34karolherbst: but for now I just try to figure out the voltage map table
10:34karolherbst: and those entries are typed :/
10:34karolherbst: so if byte is 0x0 it means something else than if byte is 0x1
10:34karolherbst: the first one
10:34imirkin: excellent :)
10:35karolherbst: yeah and currently I figure out those lines: "-- ID = 53, mode: 1 link: 2, voltage_min = 6250, voltage_max = 62500 [µV] c0 786432 c1 0 c2 32 c3 0 c4 0 c5 0--"
10:35karolherbst: mode 0x1 means: offset calculated depending on temperature
10:35karolherbst: cstate points to a row with mode 0x0, which links to a row with mode 0x1
10:35karolherbst: so the first row gives a voltage not depending on the temperature and then we have to calculate the value for the second row and just sum it up
10:36imirkin: watch out for confirmation bias
10:36karolherbst: I know
10:36karolherbst: but I could clamp the change with the voltagE_min, voltage_max entries
10:36karolherbst: if I lower voltage_max, the voltage doesn't increase as much
10:36karolherbst: and so on
10:37karolherbst: and this is pretty obvious: https://gist.github.com/karolherbst/07a84189825f0b02d083
10:37karolherbst: I mean what c0 and c2 does
10:37karolherbst: but it would be nice if somebode could check it at some point later
10:39karolherbst: imirkin: also the sign in c2 is right, because when I make it a positive value, the order is reversed
10:39karolherbst: so a high temp gets a high voltage and low temp a low one
10:39karolherbst: so yeah, it has to be something like T * c2 + c0
10:40karolherbst: just some factors missing
10:40karolherbst: or it might be something like that
10:43imirkin: does this solve the issue that Tom^ was having? or is that a separate matter?
10:45karolherbst: it solves kepler volting
10:45Tom^: it sort of does when its done, as it is now the volts is set to min and my card freezes when i go to high on the clocks or cstates with that. so ive just changed it around to set it to max all the time instead :p
10:45karolherbst: well this is my goal at least
10:45karolherbst: so when I figure out the mode 0x1 entries, it is partly solved
10:46karolherbst: then I need to figure out the mode 0x0 entries and I am done with my gpu
10:47karolherbst: then I just need to clean up my other kepler reclocking fixes and then kepler reclocking is pretty much done
10:47karolherbst: except power budgeting
10:59karolherbst: ohh right, I can just disable the c2 part :)
10:59karolherbst: that makes it, easier
11:13karolherbst: oh man, I hope those constants will be the same for all cards ... but somewhat I really doubt that
11:30karolherbst: I hoped to get a more "clean" value
11:31RSpliet: is it a linear factor?
11:31karolherbst: T*c2*unk + c0/14.3601
11:32karolherbst: but I need to verify the constant first
11:32karolherbst: only checked that for the +2/+3 border
11:34karolherbst: mhh, doesn't work really for +3/+4 :/
12:11netoman: hello! I have a question regarding hardware support...
12:11netoman: I just wanted to know which is the latest hardware supported that does not require firmware
12:12imirkin: "does not require firmware"? that's pretty generic
12:12imirkin: i think the GeForce FX series is the last hw that doesn't require any firmware of any kind for anything
12:13imirkin: (released in 2004 or so?)
12:13effractur: well all cards load firmware from the vbios?
12:13imirkin: effractur: that's wholly untrue
12:14imirkin: first of all, many NV4's don't have any usable vbios scripts at all (Riva TNT's), secondly i hardly consider the vbios scripts and tables to be "firmware"
12:14imirkin: but if you do consider them to be firmware, then all NV5's and up (TNT2+), and some NV4's (TNT) require firmware
12:15karolherbst: imirkin: is any part of the firmware ran by the gpu without interpreted by the host before?
12:15karolherbst: I mean the vbios part
12:15imirkin: karolherbst: not to my knowledge.
12:15karolherbst: k, because then I wouldn't call it firmware
12:15karolherbst: because it is no program code
12:16karolherbst: it's just stuff the driver reads to configure the gpu the right way
12:16imirkin: karolherbst: actually i guess the x86 code that executes as part of the boot does
12:16karolherbst: ohh there is x86 code in the vbios?
12:16imirkin: it (a) sets up logic to handle all the VGA/VESA stuff, and (b) i think installs a very basic pmu
12:16imirkin: in the vbios? no
12:16Tom^: i think you guys went a bit technical, i would say he is wondering which is the newest that doesnt require signed firmware :p
12:17Tom^: but then again we both are just assuming.
12:17netoman: imirkin: if you actually know what exactly the "vbios scripts and tables" do, then I have no problem with that, really.
12:17imirkin: in the program supplied in the oprom, yes
12:17karolherbst: ahhh okay
12:17karolherbst: netoman: well there is the nvbios tool in envytools which with you can read the known part of the vbios
12:17imirkin: netoman: each card is different, but it's an easy to read script which does magical things
12:18karolherbst: but in the end the stuff nouveau doesn't know are not executed or read at all
12:18imirkin: basically a sequence of "write value X to mmio register Y" types of things. a few more sophisticated instructions.
12:18karolherbst: netoman: think of the vbios as a config file for the gpu, that is read by the driver
12:18imirkin: netoman: if you are, like Tom^ is suggesting, asking about signed firmware, that started with GM20x, aka GTX 950+
12:18imirkin: and is in (almost) no way related to vbios
12:19urjaman: when would be the first firmware (not vbios or option rom) for something that's not provided by nouveau? NV50's video accel?
12:21urjaman: but thats hardly needed for like using the card, so i dont know if that counts...
12:21imirkin: urjaman: G84
12:21mupuf: karolherbst: hmm, it definitely was not that easy on my maxwell :s
12:21imirkin: technically NV41-G80 have VP1, which is also a video decoding engine, but nouveau has no support for it
12:21netoman: imirkin: but you know what "writing value X to mmio register Y" does? Or it's just secret sauce?
12:22imirkin: netoman: well, it configures a bunch of board-specific stuff. like memory timings, etc. but we don't exactly know what all the values mean.
12:23netoman: imirkin: no, I'm not asking about signed firmware, but it's good to know anyway. I know have the impression that my NV50 (NVS 3100M) is supported by nouveau without the need for any closed firmware (signed or not).
12:23netoman: s/I know have/I now have/
12:23imirkin: netoman: if you use video accel, that will require closed firmware
12:24imirkin: (not sure what gpu that is, but it's definitely not an NV50 -- it's probably in the NV50 family, but not the original)
12:25Tom^: its a buisness card based on the GT218 core, e.g G210m / 310m
12:25netoman: imirkin: yes, the NV50 family, I though that was clear. I really get lost in naming conventions.
12:25Tom^: if im understadning google right.
12:25urjaman: well the option rom is closed source code, and you have run that even before linux... unless you're one of the coreboot people ...
12:26netoman: Where's that firmware located. I thought it was in /lib/firmware/nvidia/
12:26imirkin: netoman: the video accel firmware would be in /lib/firmware/nouveau
12:26imirkin: netoman: https://nouveau.freedesktop.org/wiki/VideoAcceleration/
12:26urjaman: yeah i read that same text from google and Tom^ :P
12:26urjaman: GT218 / NVA8 ...
12:27urjaman: it is listed in the codenames page but unhelpful to searching as NVS (300, 2100M, 3100M)
12:27imirkin: if it's a GT218, that should be VP4 engine, which means you get accel for decoding of mpeg2, vc1, mpeg4p2, mpeg4p10 (h264)
12:28netoman: urjaman: not yet, I'm working on it. I'm aiming for libreboot really...
12:29imirkin: netoman: but it's completely optional... just need it for video decoding accel
12:29imirkin: no firmware = no accel
12:30imirkin: the context switching firmware (needed for 2d/3d accel) is provided by nouveau
12:30urjaman: libreboot people wouldnt accept the vbios scripts, or the option rom... they dont even accept microcode updates, so...
12:31imirkin: well, that's fine - nouveau can run the scripts itself
12:31urjaman: yeah but if the scripts dont exist at all, nouveau cannot POST a card i assume?
12:31imirkin: the scripts are *on* the card... why wouldn't they be there?
12:32imirkin: like if someone physically removes the chip from the card? that'd be unfortunate.
12:32urjaman: it's a mobile thing ...
12:32imirkin: hmmm... yeah, this was around the time when they were switching stuff over the ACPI. questionable.
12:32imirkin: anyways, you could extract the vbios and pass it in via kernel option
12:32urjaman: I assumed they'd just embed it in the main bios ROM like other embedded stuff...
12:32imirkin: yeah, sometimes they do that and provide ACPI methods for reading it
12:33netoman: urjaman: yes I know, thats why I'm researching all these things, because I'm a blank slate on these topic.
12:34netoman: imirkin: OK, I don't have /lib/firmware/nouveau/
12:34urjaman: imirkin: anyways the point was... thats why there are practically no libreboot desktops is they could have any gpu attached and thusly need to run option roms or other binary stuff from the card => no longer libre...
12:35netoman: I was getting a 403 on https://nouveau.freedesktop.org/wiki/, but now seems fixed.
12:35imirkin: netoman: they're reconfiguring a bunch of those servers today
12:37Yoshimo: since when do the freedesktop subdomains offer https?
12:38imirkin: since recently
12:39urjaman: since november 1 2014 :P, or maybe not that long ago, but thats' when the cert was issued
12:39urjaman: i went to look at the details because my thought was "i bet its letsencrypt" and it wasnt
12:40Yoshimo: then the HTTPS-Everywhere rewrite was fucked up
12:40netoman: imirkin: when you say that nouveau provides firmware in /lib/firmware/nouveau, that's a repackaged/redistributed nvidia firmware or is it developed by nouveau devs (maybe open source)?
12:41imirkin: netoman: well, nouveau can't actually provide the firmware. it's more like "for nouveau".
12:41netoman: I'm so sorry for my total ignorance, I haven't found this stuff in the wiki.
12:41imirkin: netoman: as you can probably see on the VideoAcceleration wiki page, there's a script to scrape some firmware from the blob drivers
12:42imirkin: netoman: the firmware that is developed by nouveau is baked into the kernel, and is used for context switching, and pmu stuff
12:42imirkin: and a few other small items
12:42netoman: imirkin: and what's the use for that? If it's already on the card... Why download it from the card just to reaload it through nouveau?
12:42imirkin: it's in the nvidia driver, not on the gpu itself
12:42netoman: I'm totally missing something U_U
12:43netoman: oohhhhh (facepalm)
12:43imirkin: look, there are lots of generic processors inside a gpu
12:43imirkin: the various processors do various different things
12:43urjaman: now i confused everybody -.-
12:43imirkin: nouveau has developed firmware for some of those functions, but not others
12:43imirkin: the "not others" are mostly video decoding acceleration
12:44imirkin: mostly because those engines are a huge pain to RE, and even if we magically obtained the full specs to them *today*, it'd still take like a year to develop the proper firmware to decode the video
12:44imirkin: and it's just not worth it
12:45netoman: imirkin: of course, I understand that. I'm totally aware the pain that it is for you nouveau devs this RE work.
12:46Yoshimo: imirkin: i think that is something to do when the rest is done
12:47imirkin: Yoshimo: you're making the assumption that volunteer contributors attempt to achieve your goals. in fact they attempt to achieve their goals. those goals might be "figure out how video decoding engine works", with not a care that reclocking is unsupported, or some GL feature is unimplemented, or whatever.
12:47netoman: So the "firmware backed into the kernel" is just plain C code (drm driver stuff) or more like blobs converted to C arrays?
12:48imirkin: netoman: well, we don't have a compiler, so it's assembly code. and we don't want to require the assembler as part of a kernel build, so the built stuff is also checked into the kernel.
12:48Yoshimo: i don't assume anything, i am gratefull for all the work people like karol are doing
12:48imirkin: netoman: but the source is there
12:48Yoshimo: i don't mourn if nvidia keeps firmware to itself and use the binary one until they change their mind
12:49imirkin: netoman: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/gr/fuc
12:49imirkin: (fuc = falcon microcode)
12:49imirkin: the .h files contain the built bytecode, the .fuc files contain the assembly
12:49netoman: imirkin: OK, but the important part is that is assembly that you wrote (and assembled), right? Technically is a blob, but not a closed one. Right or wrong?
12:50imirkin: this is for (mostly) GF100+ stuff, the nv40 and nv50 ctxsw logic is generated in C code.
12:50netoman: Ah, ok. "the source is there"
12:50imirkin: netoman: the source is there, but requires special tools to build, which would be annoying to require of kernel users
12:51netoman: imirkin: yes I understand.
12:51netoman: OK, I've found the Introductory Course on Nouveau wiki...
12:51karolherbst: mupuf: yeah I got to the fun part now ...
12:51imirkin: unfortunately it's about 100 years out of date =/
12:53netoman: imirkin: some of it must hold be true today :D For a n00b that's more than fine
12:53imirkin: netoman: you might also be interested in http://envytools.rtfd.org
12:55netoman: imirkin: interesting! It also talks about the Falcon you mentioned above.
12:55mupuf: karolherbst: which means? :)
12:55mupuf: Reviewing your patchset right now
12:56karolherbst: well figuring out the exact formular for the temperature voltage offset
12:57karolherbst: at least I know what the fields do on my gpu, and this is at least something
12:58netoman: imirkin: can you recommend some resource on RE? A book, a website, an old crufty presentation, anything?
12:58imirkin: netoman: reverse engineering? you just poke at stuff until you think you understand what's going on
12:59imirkin: i don't think there's any formal training
13:00netoman: yeah, at least on search engines nothing pops up.
13:00mupuf: karolherbst: definitely! That is a great finding!
13:00netoman: imirkin: so... how did you get started?
13:00karolherbst: mupuf: but the 0x1 could also be just a flag, which might make sense when I look into other vbios
13:01karolherbst: anyway, there need to be big changes in nouveau for that :/
13:01karolherbst: I kind of hoped to get it ready for 4.6, but that's just too big for this :D
13:01mupuf: karolherbst: yep, but you know, you can pick the worst case scenario for now
13:01imirkin: netoman: i wanted to make video decoding accel work on my gpu
13:01mupuf: pick the highest voltage
13:01karolherbst: mupuf: yeah, we could simply use our voltage_max value
13:02karolherbst: and this is also what nvidia respects
13:02mupuf: I would say that the temperature-polling code should adjust the voltage
13:02imirkin: netoman: i got some help on how to operate the various tools, then just stared at stuff until it made sense
13:02karolherbst: mupuf: mhhh I don't know
13:02mupuf: karolherbst: it really did not work like that for me
13:02karolherbst: mupuf: we know the range when to change the voltage again
13:03karolherbst: well basically it works like that for me
13:03karolherbst: cstate points to a voltage row entry
13:03karolherbst: when I replace all constants to 0 and have only min/max set
13:03karolherbst: nvidia uses the min value
13:03karolherbst: and I set link to ff
13:03karolherbst: for this to work, you also have to adjust the pstate voltage entry
13:04netoman: imirkin: OK, good. I guess you also read something on how GPUs work at an architectural level. Right?
13:04karolherbst: otherwise nvidia just uses the pstate entry as the min value
13:04karolherbst: so the code is something like that: max(cstate.volt.min, cstate.pstate.volt.min)
13:04mupuf: funny, it really did not behave like that on my maxwell
13:04imirkin: netoman: ssssort of. i just asked lots of dumb questions in ehre.
13:05karolherbst: mupuf: I will check that :p
13:05imirkin: netoman: and tried to make sense of the hwdocs in envytools, to little avail
13:05imirkin: they barely make sense to me even now
13:05netoman: imirkin: OK. So mining nouveau's IRC logs should bring something interesting...
13:06imirkin: netoman: what's your goal?
13:07netoman: imirking: my goal is to know how my GPU works and how Linux/nouveau operates it.
13:07imirkin: that's a tall order
13:07imirkin: pick something smaller
13:08imirkin: zero in on one small thing, and build up from there
13:08netoman: imirkin: yes, that's of course the path, divide and conker... I'm not insane yet.
13:09imirkin: it helps to be trying to modify something to do some thing X, because that helps focus you on things that matter vs ones that don't
13:11netoman: netoman: you're right. The first step is getting the big picture, so I'm starting with the Introductory Course and staring at nouveau/mesa/drm code.
13:11imirkin: if you say so. imo the big picture is too big :)
13:11netoman: netoman: because I really don't know yet what to modify nor how...
13:12netoman: imirkin: Hahah! OK. I'll take your advice then.
13:13karolherbst: mupuf: ohh for your information, there is also a special voltage entry for boost clocks ;)
13:13karolherbst: to make things easier you know
13:14mupuf: Ah ah
13:14netoman: imirkin: thanks for the help! Sorry for the distraction.
13:15mupuf: yeah, definitely :D Because making a distinction between boost and non boost frequencies make a ton of sense!
13:15mupuf: ... NOT!
13:17karolherbst: mupuf: but you can easily tell nvidia to not use boost clocks
13:17karolherbst: just set prefered mode to max perf without any load
13:17karolherbst: then you get the base clock set
13:17karolherbst: which is the highest non-boost clock
13:18karolherbst: k... no figuring out the c0 parameter
13:18karolherbst: 0?-0xea__ => +0 pwm
13:18karolherbst: 0xeb__ - 0x282__ => +1 pwm
13:18karolherbst: 0x283__ - ? => +2 pwm
13:19karolherbst: +1 pwm means 6250 µV
13:19karolherbst: any ideas?
13:20karolherbst: __ means two digits missing because I don't need that accuracy right now
13:25mupuf: sounds really wrong
13:25mupuf: so, what do you mean by c0 parameter?
13:25mupuf: do you mean header+0xc0?
13:26mupuf: karolherbst: ^^
13:28karolherbst: mupuf: volt_temp_offset = T*p2*c1 + p0*c0
13:28karolherbst: c0 is 32bit start+10 in the row
13:29karolherbst: and p2 is 32bit start+18
13:29karolherbst: and now I try to figure out the c0 part, because I set p2 to 0
13:29karolherbst: now I get a static offset to the voltage which isn't affected by the temperature
13:30mupuf: :o, the perf entry is that huge?
13:30mupuf: I did not check the perf entries
13:30karolherbst: there is a 32bit value at start+30
13:30mupuf: I was only fidling with the voltage mapping table
13:30karolherbst: mhh voltage map table
13:30karolherbst: yeah I also mean that
13:30mupuf: why the heck is it that big? :o
13:31karolherbst: one row: 0x8e32: 01 02 00 00 00 00 24 f4 00 00 00 b6 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
13:31karolherbst: parses to -- ID = 53, mode: 1 link: 2, voltage_min = 0, voltage_max = 62500 [µV] c0 374272 c1 0 c2 0 c3 0 c4 0 c5 0--
13:31karolherbst: currently I have fun with c0 and c2
13:32karolherbst: "-- ID = 35, mode: 0 link: 35, voltage_min = 812500, voltage_max = 937500 [µV] c0 11508457 c1 -525 c2 -6611 c3 0 c4 0 c5 0--" this gives me a pwm value of 0x2d (this is the voltage map entry associated with my cstate)
13:32karolherbst: the link means 0x35 => 53
13:32karolherbst: the c0 of 374272 gives me an offset of +3 on top of 0x2d
13:32karolherbst: 0xea00 gives me +0, 0xeb00 gives me +1
13:32karolherbst: and so on
13:33karolherbst: you see how much fun that whole thing is :D
13:33karolherbst: usually c2 is something like -27
13:33karolherbst: which tells you how much the temperature actually affects the voltage
13:34karolherbst: but this I figure out after I managed to figure out the c0 thing
13:34mupuf: well, funny that maxwell is so different then
13:34karolherbst: shouldn't be actually
13:34karolherbst: and if it is....
13:34karolherbst: I will just check your gpu after I am done with mine
13:34karolherbst: but this could be messy over ssh :/
13:34mupuf: oh, did you try vbetracetool?
13:34mupuf: for POSTing gpus
13:35karolherbst: well I can simply optirun something
13:35karolherbst: and then my gpu is posted
13:35karolherbst: I just had to tell bumblebee to not turn off my gpu :D
13:35karolherbst: it would be just nice to detect if the gpu is alrady posted or not
13:35mupuf: oh, you are right, they are longer than I remembered
13:35karolherbst: with fermi they got longer I think
13:36karolherbst: okay, I think I can now tell which are the borders for an offset change
13:36karolherbst: and I think I might forget about rounding
13:36karolherbst: that's why the borders are a bit odd
13:37karolherbst: it is pretty easy though now
13:38karolherbst: I think there is a factor of 16.79 to it
13:38karolherbst: c0 * 16.79 => µV offset
13:38karolherbst: or maybe 16.80
13:41mupuf: acceptable rouding error :p
13:41karolherbst: c0 / 16.80
13:41karolherbst: so volt_temp_offset = T*c2*unk2 + c0/16.80
13:42karolherbst: no idea why 16.80 though
13:45karolherbst: you know what would be funny? If there is a modifier to the linked voltage....
13:52karolherbst: okay, when that is right, then c0= 15068000 should get me 0.897V
13:53karolherbst: mhh but I get 0.9375 which is the max of that cstate
13:54karolherbst: mupuf: ohh here, I got the max_voltage now :)
13:55karolherbst: mupuf: okay, so basically the volt_min and volt_max entries doesn't change behaviour
13:55karolherbst: they just limit the result of the calculation with the parameters of the entries
13:56mupuf: yeah, I told you that already a while ago :s
13:56karolherbst: ohh okay, good
13:56karolherbst: then this is verified :p
13:56mupuf: have you read the code for the gk20a?
13:56karolherbst: yeah, and it doesn't fit
13:56mupuf: for sure sure?
13:56karolherbst: it's somehow similiar, but too different
13:56karolherbst: they get some bogus speedo value from the chip
13:57karolherbst: and do crazy stuff with that
13:57karolherbst: I can't get these values so I can'T really try it out. But I think the ideas might be the same though
13:58karolherbst: or maybe it is the same, but I don't see it
13:58karolherbst: anyhow, there is also no entry linking in gk20a
14:03karolherbst: c0/10 == µV in the directly linked entries from the cstate
14:04mupuf: oh oh oh, that is a good finding!
14:04karolherbst: now it is getting much better
14:04karolherbst: if start is 0x0: voltage is c0 / 10
14:04karolherbst: if start is 0x1: voltage is c0/16.80
14:05karolherbst: start is the first byte in the row
14:05mupuf: yeah, got it
14:06karolherbst: -- ID = 35, mode: 1 link: ff, voltage_min = 812500, voltage_max = 937500 [µV] c0 14595000 c1 0 c2 0 c3 0 c4 0 c5 0-- gives me 875000µV
14:06karolherbst: 14595000 / 16.80= 868750.0
14:06karolherbst: close enough
14:07karolherbst: "-- ID = 35, mode: 0 link: ff, voltage_min = 812500, voltage_max = 937500 [µV] c0 8687500 c1 0 c2 0 c3 0 c4 0 c5 0--" vices me 868750 µV
14:07karolherbst: 8687500 / 10 = 868750
14:11karolherbst: mode 2 selects voltage_min?
14:11karolherbst: and mode 3 selects voltage_max
14:12karolherbst: and mode 4 doesn't load the driver at all
14:12karolherbst: first byte done
14:13karolherbst: also tried 0x10
14:14karolherbst: but the driver just bails
14:14karolherbst: so yeah
14:15karolherbst: I saw mode 3 on your maxwell card ;)
14:25karolherbst: okay, I was wrong about mode2/3 :/ sad
16:15Impyy: is there any way I can use my nv110 card with the nouveau driver?
16:15Impyy: I get the following error: unknown chipset (118010a2)
16:17karlmag: Impyy: which particular card?
16:17karlmag: not that I think it makes much difference.
16:17Impyy: karlmag, 840m
16:18karlmag: so either nv117 or nv118 then. Maxwell v1 anyway
16:19karlmag: If I have understood this correctly, one is still waiting for signed firmware from nvidia.
16:19karlmag: for the maxwell cards. Both v1 and v2
16:21Impyy: man that's a bummer, it's a 2 year old chip even
16:23karlmag: It is a bummer, but that's proprietary hardware for you... :-/
16:23Impyy: yeah I guess so
16:23Impyy: well thanks anyway :)
16:23karlmag: and yes I am waiting for those firmwares myself.
16:36karlmag: What is the latest news (if any) of the firmware situation btw?
17:24imirkin: Impyy: GM10x does not require signed firmware, only GM20x
17:25imirkin: Impyy: your GM108 is not supported out of the box, have a look at https://bugs.freedesktop.org/show_bug.cgi?id=89558
17:26imirkin: karlmag: GM20x requires signed firmware. while gnurou from nvidia has supplied code to load such hypothetical firmware, he has not made it actually available.
17:27karlmag: imirkin: ok.. thanks for the heads up
17:31imirkin: the suggestion has been made that this firmware will be released "real soon", however i personally wouldn't at all be surprised if it just never happened at all
17:32karlmag: "real soon" starts to get old rather quickly it seems... :-/
17:35karlmag: gnurou: is/will there be any update on this status any time soon you think?
17:40gnurou: karlmag: later today hopefully , after I run some tests :)
17:40skeggsb:had better get cracking on tidying up + posting the texture header patches so we have a 3d driver..
17:41karlmag: gnurou: that's the firmware loader, right? How about the actual firmwares? Any word on those too?
17:41karlmag: Yeah, I know I am playing the pushy (l)user now, but sometimes someone have to take that role too.. ;-)
17:42karlmag: gnurou: but progress is good :-)
17:42gnurou: karlmag: no, that's the actual firmware this time - I just need to test it and if it loads, we'll release it
17:43gnurou: Note the "if", I don't see why it would not work but we got so many let downs with this that I don't want to get expectations up too much
17:44karlmag: Guess I can start thinking about breaking out my 960 then :-)
17:44karlmag: yeah, I see your point there. I really do.
17:45karlmag: I guess do it right, rather than fast, but you know how it is. People tend to become a bit impatient over time.
17:47karlmag: welp.. I won't hold my breath (for too long at the time), but I probably should try some sleep before I need to get up again. :-P
19:41gnurou: well of course the damn thing doesn't boot :/
19:43gnurou:withdraws what he said earlier
21:34V0idst4r: I need help. I'm trying to use nouveau with my GeForce 6150SE nForce 430 but at random points my computer freezes with a garbled picture.
21:35V0idst4r: Checking Xorg.0.log I see no errors that occur.
23:00gnurou: gm204 production is booting T_T
23:02airlied: gnurou: \o/
23:08gnurou: I don't think any excuse would make my case better for the time it took, so I'll just keep silent on the subject
23:09gnurou: let it just be known that the issues were not technical
23:09airlied: or however you spell it
23:10gnurou: kind of, if irrationality counts as PEBKAC
23:11gnurou: anyway, I should vent in private :)
23:30gnurou: airlied: when will you stop accepting pull requests for 4.6? we just need to discuss a few details and then the kernel code should be good to go in
23:32airlied: gnurou: usually about rc6, so two weeks or so
23:32airlied: though skeggsb usually pushed the limits
23:32gnurou: should be good, thanks
23:33gnurou: skeggsb already reviewed most of the code, now it's just small details about the firmware format