04:26tagr_: mlankhorst: no, unfortunately not
04:27tagr_: mlankhorst: up to and including Tegra K1 there isn't really any dedicated hardware that you can talk to from the CPU, you need to upload firmware to the AVP first because it is the only one with access to dedicated decoding hardware
04:28tagr_: Tegra X1 has dedicated blocks, most of which I think are very close to the GPU counterparts
04:34karolherbst: Tom^: are you there?
07:16karolherbst: anybody here using gallium nine with steam under wine? I can't start it anymore :/ it works without nine though
07:17sarnex: karolherbst: yeah its borked there are patches on the ML to fix it
07:17sarnex: it's from the targets/* cleanup
07:18karolherbst: sarnex: which ones?
07:18karolherbst: sarnex: this? http://lists.freedesktop.org/archives/mesa-dev/2015-November/101176.html
07:18karolherbst: and the next one
07:19sarnex: 1: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101137.html
07:19sarnex: 2: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101169.html
07:19sarnex: gentoo user patching doesnt seem to work though so if you use gentoo you have to manually do it
07:19karolherbst: sarnex: nah it works for me for every package
07:19sarnex: yeah i mean they apply but for me and another user compile fails
07:20sarnex: but compile fails*
07:20karolherbst: sarnex: /etc/portage/bashrc: https://gist.github.com/karolherbst/7a49418b2c8a1d9ee44a
07:20karolherbst: that is what you mean
07:20sarnex: yeah i have the same thing but post_src_prepare
07:20karolherbst: use pre
07:20karolherbst: post runs after autoconf and stuff
07:20sarnex: would that effect something like this?
07:21karolherbst: so you might run autoconf and then patch the stuff
07:21sarnex: post is useful for my mesa build
07:21karolherbst: in pre you would patch first, then run autoconf
07:21sarnex: right with post it does patch after autoreconf, but does that matter?
07:21karolherbst: if the patches changes automake files?
07:21sarnex: the compile error is cant find header
07:22sarnex: doesnt look like they do
07:22karolherbst: will try it out
07:22sarnex: ok let me know :)
07:22karolherbst: but my ebuild does a pretty minimalistic mesa build
07:22sarnex: oh i just use wine-a-holics so i can get ixit/mesa-3d changes as well
07:23karolherbst: it buils only i965 + gallium nouveau + llvmpipe
07:23karolherbst: that I have also patched in
07:23karolherbst: sarnex: https://github.com/karolherbst/F.U.N.-overlay/blob/master/media-libs/mesa/mesa-9999-r1.ebuild
07:24karolherbst: I added some VIDEO_CARDS entries basically
07:24sarnex: ah ok
07:24karolherbst: like nouveau_vieux
07:24sarnex: i have 3 gpus on different drivers so i might as well stick with the same ebuild
07:24karolherbst: so that I don't build it
07:24sarnex: r600 radeonsi nouveau
07:24karolherbst: so -classic anyway?
07:24sarnex: yeah i have -classic
07:24karolherbst: yeah in that case, my ebuild won't change anything
07:25karolherbst: I just changed that, because I need classic for i965
07:25sarnex: ah, yeah i have amd cpu so now integrated gfx
07:25sarnex: well no i965 i mean
07:26karolherbst: hehe mes failed
07:27sarnex: cant find header?
07:27karolherbst: ahh crap
07:27karolherbst: I know the issue
07:27sarnex: ah ok
07:27karolherbst: the first patch adds new files
07:27Tom^: karolherbst: now i am.
07:27karolherbst: and because portage does automagic with the patches
07:27karolherbst: it applies fine with -p0
07:27karolherbst: which means
07:27karolherbst: they are in b/
07:27sarnex: karolherbst: oh can you explain how to fix it
07:28sarnex: i prolly have same issue
07:28Tom^: i work 08
07:28karolherbst: remove b/ from the patch
07:28Tom^: 07:00 - 16:00 gmt+1
07:28karolherbst: first one is enough
07:28sarnex: ok thanks
07:28karolherbst: Tom^: +1? ohh already
07:28karolherbst: ohh no
07:28karolherbst: we have +1 already :D
07:28Tom^: its 16:28 here right now :p
07:28karolherbst: I know
07:29karolherbst: sarnex: stupid epatch auto magic :D
07:29karolherbst: Tom^: mhhh
07:30karolherbst: Tom^: would you like to mess with your vbios under windows and some bios mod tools?
07:30karolherbst: I think kepler bios tweaker 1.27 is the best one currently?
07:30karolherbst: no idea
07:30karolherbst: it doesn't start with mono, so I can't really try stuff out
07:30karolherbst: what I am interested in: base clock and max turbo clock
07:30karolherbst: I think
07:30karolherbst: not quite sure
07:31karolherbst: thing is: I want to find where in the vbios we can find the gpus base clock
07:31Tom^: ah ok
07:31karolherbst: currently nouveau will just clock the gpu to the max possible
07:31karolherbst: which may be way over the max boost clock
07:31karolherbst: and this may cause that the gpu goes about the power budget
07:32Tom^: as long as it doesnt exceed my powerbill budget im fine
07:32karolherbst: no, but your PSU might get unhappy :p
07:32Tom^: anyhow kepler bios tweaker doesnt seem to work, just empty description fields :o
07:33karolherbst: I think you have to open a vbios file
07:33Tom^: or do i have to load up the vbios i extracted from nvagetbios ?
07:33karolherbst: yeah I think so
07:34karolherbst: sarnex: thing is, now I get undefined references :/
07:34sarnex: damn it gentoo
07:35karolherbst: well there are also good linux games :D
07:36sarnex: karolherbst: it compiled for you? or died at linking
07:36karolherbst: died linking
07:37Tom^: karolherbst: http://i.imgur.com/S08NmqE.png
07:38karolherbst: the tool indeed looks a bit usefull
07:39karolherbst: so the "real" max boost clock might be calculated inside the blob
07:39Tom^: also the Voltage Table is scrollable if you didnt notice, so if you need more info il scrot it again
07:39karolherbst: it was around 1200MHz for you, right=
07:39karolherbst: voltage tbale is fine
07:39karolherbst: that is enough understood currently I would say
07:40karolherbst: you see this common boost clock box?
07:40karolherbst: and base clock?
07:40karolherbst: these are the both things we have to understand where it comes from
07:40karolherbst: so mhh
07:41karolherbst: maybe set the TDP and 3D base clock to 900 and 920
07:41karolherbst: and boost to1000
07:41karolherbst: save teh vbios and upload it :)
07:41karolherbst: those kids could really help nouveau sometimes :D
07:43Tom^: hm nvflash for uploading it?
07:43sarnex: karolherbst: mine compiled and installed fine
07:43karolherbst: to the internet
07:43Tom^: "NVFlash needs to be used in DOS mode, when you boot your system. Thus use a MS-DOS bootdisk and just copy this tool on it." oh lord
07:43karolherbst: Tom^: I just want to diff the vbios files
07:43Tom^: oh you mean upload it to the cloud
07:45karolherbst: Tom^: do you want to reopen the new vbios file and check if the changes are still there?
07:45karolherbst: just in case
07:45Tom^: they are
07:45Tom^: i set TDP to 900 and 3D to 920
07:46karolherbst: nvbios has the same output
07:46karolherbst: so new stuff :D
07:46karolherbst: found changes in the hexdumps
07:47karolherbst: three changes in total
07:47karolherbst: Tom^: is the checksum 21 now?
07:47karolherbst: I meant 12 :D
07:48Tom^: checksum where?
07:49karolherbst: in the tool
07:49Tom^: Oooh yes.
07:50Tom^: 12 - 
07:50Tom^: i must be blind, i checked the tool twice before i asked. xD
07:50karolherbst: I bet if you reopen the modded vbios file
07:50karolherbst: both TDP and 3d are 920
07:50Tom^: yep i tried that before sending the vbios
07:51karolherbst: so it is the same
07:51karolherbst: what about boost clock?
07:52Tom^: still the same in Common
07:52Tom^: didnt change it so yea 1045.5
07:52karolherbst: ohh okay
07:52karolherbst: thing is somehting else changed, but no clue what it might be
07:52Tom^: confirmed blind, i see now i missed your second line of setting boost to 1000
07:55karolherbst: Tom^: np, could you change it and reupload the vbios again
07:56Tom^: boost set and confirmed to 1337
07:56Tom^: checksum C9
07:57karolherbst: ahh I see a new change
07:57karolherbst: uhh nice
07:57karolherbst: 082b => 0a72
07:57karolherbst: it is even right
07:58karolherbst: what about those pull down menus?
07:58karolherbst: with the Entry # stuff
07:58karolherbst: can this be changed?
07:58Tom^: Entry ? yes
07:59Tom^: Entry #0,1,2 and disabled
07:59karolherbst: mhh okay
07:59Tom^: it seems Entry 1 is TDP , entry 2 is 3d and entry 0 is boost.
07:59Tom^: if i change TDB Base entry to 0 it gets set to 1337
08:00karolherbst: there is a level of indirection in the vbios as it seems
08:00karolherbst: somewhere is a table like: boost is in entry a
08:00karolherbst: base is in entry b
08:00karolherbst: and so on
08:00karolherbst: maybe set all to entry 0
08:00karolherbst: save and upload :)
08:01Tom^: now they are all set to entry 0 which also seems to mean its all 1337
08:01karolherbst: yeah, they point to the same entry
08:02karolherbst: ohh nice
08:02karolherbst: found it
08:03karolherbst: maybe set tdp to disabled and boost to 2
08:05karolherbst: boost limit seems to be greyed out
08:05karolherbst: but I see a fourth field in the vbios
08:07karolherbst: okay one last thing
08:07karolherbst: want to mess up the memory clock?
08:08karolherbst: maybe this doesn't change anything we already now
08:08karolherbst: but would be good to be sure
08:09Tom^: https://www.dropbox.com/s/hjdesovjycyjldu/vbiosmemmod.rom?dl=0 stock clocks and entrys, mem set to 1337
08:10karolherbst: two changes, well
08:10karolherbst: okay, but makes sense
08:11karolherbst: mupuf: I think I found out what "UNK38 table at 0x6fc6, version 10" is :)
08:11karolherbst: mupuf: https://gist.github.com/karolherbst/6bc58523c8b299daff94
08:11imirkin: karolherbst: this isn't some official utility... presumably what it does isn't necessarily right
08:11karolherbst: I know
08:11karolherbst: but the values make totoally sense for now
08:12karolherbst: will have to check on other vbios and may also throw some faked vbios into the blob
08:12karolherbst: but at least it may give us a good lead
08:13karolherbst: imirkin: but I somehow hope that if the tool wouldn't do anything what user expect, the tool wouldn't be somehow known and used
08:13karolherbst: Tom^: okay, the memory changes are alredy in known areas
08:14karolherbst: but the other stuff may be really helpful :)
08:14Tom^: hooray \o/
08:14karolherbst: memory changed two entries: 0xd and 0xf pstate
08:21RSpliet: karolherbst: that paste is missing a lot of context to be understandable to third parties ;-)
08:22karolherbst: I don't think it is that hard.
08:22karolherbst: it is just addresses in the vbios
08:22Tom^: RSpliet: you just have to reverse engineer his discoveries.
08:22karolherbst: entry nr of the boost clock is found at 0006fd7 in Tom^s vbios
08:22Tom^: from his reverse engineering. its reverse engineriception.
08:22karolherbst: table starts at 0x6fc6
08:22karolherbst: so 0x11 in this table tells you which entry holds the boost clock
08:23RSpliet: mind printing the raw table values as well?
08:23karolherbst: if it is 2, look at entry #2: 0006ff0
08:24karolherbst: RSpliet: https://gist.github.com/karolherbst/6bc58523c8b299daff94
08:24karolherbst: ohh wait
08:24RSpliet: what's the 6fcX line like? version, header length, entry length etc?
08:25karolherbst: updated: https://gist.github.com/karolherbst/6bc58523c8b299daff94
08:26karolherbst: 0x6fc6 +0x0 is the version
08:26karolherbst: 0x1 is hlen
08:26karolherbst: 0x2 is rlen
08:26karolherbst: 0x3 is entrysum
08:27karolherbst: according to nvbios source
08:27RSpliet: yep (hard to decode halfword aligned, but meh :-P)
08:29imirkin: karolherbst: can i interest you in 'hexdump -C' ?
08:29karolherbst: meh :D
08:31karolherbst: okay, I think I might have messed up the "right" addresses
08:33RSpliet: hmmhmm, so the pitch between two entries appears to be 7 bytes
08:33karolherbst: RSpliet: I made a mitake
08:33karolherbst: I have to go through it again, I have to adjust those addresses
08:34RSpliet: that doesn't change the fact that the pitch appears to be 7 bytes between entries in that table... :-D
08:34RSpliet: (05 + 02?)
08:34RSpliet: (05 + 02 * 01?)
08:34karolherbst: nah, I found the tdp entry now
08:34RSpliet: (02 + 05 * 01) something like that :-P
08:34karolherbst: so I have three now
08:35karolherbst: but I think you are still right :D
08:36RSpliet: with c top-level entries (so the table might be longer than pictured here)
08:38karolherbst: RSpliet: https://gist.github.com/karolherbst/6bc58523c8b299daff94
08:38RSpliet: yeah... almost :-)
08:39RSpliet: header is 0x17, so talking in entries and subentries: entry 0 at 6fdd, entry0.0 at 6fe2, entry 1 at 6fe4 entry 1.0 at 6fe9...
08:40karolherbst: ohh subentries
08:40RSpliet: yeah, but 6fc6+0x4 indicates there's only one subentry per entry :-P
08:41RSpliet: of length 2 (6fc6+0x3)
08:41RSpliet: sorry, I've seen so many VBIOS tables that I'm spoiling all the fun for you now O:-)
08:45mlankhorst: tagr_: would be fun to get a X1 then. :P
08:45karolherbst: current result: https://gist.github.com/karolherbst/f9e70f14f003731ed3e1 :)
08:46karolherbst: there is more to it
08:46karolherbst: because it doesn't make sense for my card :(
08:47RSpliet: whoo, more fun!
08:48karolherbst: this is from my gpu: https://gist.github.com/karolherbst/be97bc9fd0021060ba92
08:49RSpliet: yeah, version != header length
08:50RSpliet: and you didn't take into account subentries
08:50RSpliet: fix your code first, then complain :-P
08:50karolherbst: Tom^: do you want to mess up my vbios? :D
08:53Tom^: karolherbst: sure
08:55karolherbst: Tom^: http://filebin.net/pexw0j9bj8/vbios.rom
08:56karolherbst: it would be enoughf or me to just get a screenshot of the common section
08:56hakzsam: imirkin, yeah, I think we can get rid of that assert too
08:56karolherbst: RSpliet: so hlen means header lenght, mhhh
08:56karolherbst: yeah I might want to respect that :D
08:56Tom^: karolherbst: your checksum turned red :p
08:56karolherbst: I know
08:56karolherbst: doesn't matter
08:57karolherbst: maybe not for my gpu
08:57karolherbst: who knows
08:58Tom^: 14 entrys :o
08:58karolherbst: I saw the 0x7 already and was suspicous
08:58karolherbst: only 705MHz base clock
08:58karolherbst: slow ass gpu
08:58karolherbst: (I was driving the card at 997MHz on the blob without issues)
09:00RSpliet: karolherbst... yes ;-)
09:01RSpliet: if you can improve nvbios to make it more verbose and make it easy to parse the data, that'd be a good first step in RE'ing the bits in the table
09:02karolherbst: first I try to parse the stuff I already know
09:03RSpliet: sure! but automating it by writing it up in nvbios helps get an overview of the data in there, see patterns, expose regularity
09:04karolherbst: I think I got the part already I am interested in :)
09:04karolherbst: the entry nr is in the same spot as it seems for both cards
09:05karolherbst: I just have too take the header length into account
09:06karolherbst: RSpliet: does nvbios leave out 0ed of ffed entries?
09:06karolherbst: or "disabled" once?
09:06RSpliet: if you make it so...
09:07Tom^: also karolherbst https://www.techpowerup.com/vgabios/
09:07Tom^: bunch of vbioses :p
09:07RSpliet: that's quite a large unsorted collection
09:08karolherbst: RSpliet: I can enable those hexdump prints with -v right?
09:08karolherbst: these envy_bios_dump_hex calls
09:08RSpliet: karolherbst: sure
09:08RSpliet: the code is not very complex, you can make it so otherwise
09:08karolherbst: I wonder
09:08karolherbst: because I only get two entries printed
09:09RSpliet: karolherbst: perhaps it incorrectly interprets the 2 as entries rather than "size of subentry"
09:09karolherbst: ohh maybe
09:09RSpliet: dive into the code, it's simple and ugly and easy to fix :-)
09:10RSpliet: Tom^: that collection is rather hard to nvbios * | grep "something" through :-P
09:10Tom^: heh fair enough
09:10RSpliet: but useful to find rare configurations with :-)
09:10karolherbst: RSpliet: one byte: 02 for Tom, 07 for me
09:11karolherbst: I bet this is the "max entry" thing
09:11RSpliet: which byte are you referring to?
09:12RSpliet: wasn't that the referral to which entry in the table it should pick for TDP or boost or 3D or something?
09:13karolherbst: uhh right
09:13RSpliet: please fix nvbios, push your patch to your repo as far as you can, I'll review tonight for merge in upstream envytools if you don't have that access right yourself
09:13karolherbst: I have access
09:13RSpliet: don't worry about it being complete or not, just make it valid and nice :-)
09:13karolherbst: trying :D
09:14RSpliet: 0x0 ver, 0x1 hlen, 0x2 elen, 0x3 selen, 0x4 secount, 0x5 ecount
09:14RSpliet: where h is header, e is entry, se is subentry
09:15RSpliet: if you want different letters or they don't correspond with nvbios, well... fix it :-P
09:15karolherbst: 0x20 entry count :D
09:15karolherbst: seems a bit much though
09:15RSpliet: they often allocate big tables and not use half of it
09:15RSpliet: that's useful for hacking ;-)
09:16RSpliet: so the stride between entries is elen + selen * secount
09:18Tom^: seems kepler bios tweaker is coded in .net so you can .net reflect it and view most of its source code :p
09:19RSpliet: yeah, but it's not as if these tables are difficult or anything :-P
09:21karolherbst: the clocks are at the end of the entry :/
09:21RSpliet: clock is in the subentry
09:21karolherbst: I noticed
09:21karolherbst: Tom^s : https://gist.github.com/karolherbst/be97bc9fd0021060ba92
09:21karolherbst: now it also looks nice
09:21karolherbst: very good
09:22karolherbst: my vbios: https://gist.github.com/karolherbst/6bc58523c8b299daff94
09:22RSpliet: hehe, loads of data
09:23karolherbst: but the clocks are there
09:23RSpliet: my guess: the first byte indicates the perflvl
09:23karolherbst: makes sense
09:24karolherbst: RSpliet: 07 0a 08 95 06 0e 01
09:24karolherbst: this is what the blob clocks down to
09:24karolherbst: at 0x7 perf level
09:24RSpliet: can you map any of the numbers (+0x2 or +0x4) to a voltage?
09:25RSpliet: +0x4 seems to be a 16-bit number of some sort
09:26RSpliet: ehh, +0x3 :-P
09:26karolherbst: 10, 12-47 are used in the cstates
09:27karolherbst: +0x2 being voltage might make sense
09:27karolherbst: +0x4 not
09:27RSpliet: the irregular pattern in 0x1 and 0x3 indicates that +0x1 and +0x3 might both be 16-bit integers
09:27RSpliet: depicting a range of some sort
09:28karolherbst: I've also added my cstep table
09:29karolherbst: RSpliet: I don't know if we need this kind of information though, we can deal with that later
09:29karolherbst: Tom^s entries are basically 0 except the clock
09:30RSpliet: printing the perflvl and clock nicely could be helpful, you can sort out the rest in future patches :-P
09:30karolherbst: I just print the clocks from the entries pointed to by the header
09:30karolherbst: this should be enough
09:30karolherbst: then we have the "base" and the "boost" clocks
09:30karolherbst: this is enough for now
09:34karolherbst: nice, now it works for both cards :)
09:36karolherbst: RSpliet: this isn't really clean, but does the trick: https://github.com/karolherbst/envytools/commit/0422e9fa9fabfc009ebea849c78fa19f8c1b4f9c
09:36karolherbst: will clean that up later after I am sure it works everywhere
09:38karolherbst: RSpliet: for mupufs gk106 it prints the same clocks as on the tech specs from the store webpage :)
09:39karolherbst: I think this works this say
09:39karolherbst: Tom^: thanks again for your help :)
09:39Tom^: at your service my liege.
09:41karolherbst: RSpliet: seems like nvd7 cards also have this table with version 0x0
09:41karolherbst: but other than that, it seems to be only used in kepler
09:42karolherbst: imirkin: your gk108 kepler card
09:42karolherbst: I meant gk208
09:42imirkin_: karolherbst: what do you need exactly?
09:43karolherbst: official spec clocks
09:43karolherbst: like what was written on the store page :p
09:43karolherbst: or whereever
09:43imirkin_: it's a dell box
09:43karolherbst: do you now the idle clock with blob?
09:43imirkin_: came with the card... i don't even know if i knew it would have it
09:43karolherbst: with full perf preffered
09:44imirkin_: sorry, no. can't check right now.
09:45karolherbst: mwk: your GM107 card, 1058.5 base and 1137 boost?
09:45karolherbst: mlankhorst: and your GM107 should have the same
09:46karolherbst: RSpliet: anyway, it seems like those values make sense for each vbios with that table version 0x10
09:52Tom^: karolherbst: gk106 http://www.anandtech.com/show/6276/nvidia-geforce-gtx-660-review-gk106-rounds-out-the-kepler-family
09:53Tom^: https://en.wikipedia.org/wiki/GeForce_700_series#Products gk208
09:53karolherbst: Tom^: yeah, but it doesn't help
09:53karolherbst: because cards can be differntly clocked
10:00imirkin_: karolherbst: if it helps, lspci thinks that it's a GeForce GT 720
10:00karolherbst: wiki says 797 mhz
10:01imirkin_: dell part number 9YJWT
10:01imirkin_: it's a desktop, no mobile
10:01karolherbst: 740M would be the only thing close
10:01karolherbst: ohh okay
10:02karolherbst: ohh okay, got it
10:03karolherbst: but only on shitty websites :/
10:03karolherbst: but it seems to be a 720 indeed
10:03imirkin_: there's also "M211N" associated with it, no idea what that is
10:04karolherbst: what dell computer is it?
10:04karolherbst: maybe that helps more
10:04imirkin_: XPS 8700
10:04imirkin_: but there's a million options
10:05imirkin_: hm, searching for that m211n, the first result is http://www.geforce.com/hardware/desktop-gpus/geforce-gt-720 :)
10:06karolherbst: yeah, but the clock is 797 there
10:06karolherbst: don't think dell tinkered with it that much
10:06karolherbst: but who knows
10:07karolherbst: those websites are getting more useless by the day :/
10:36mupuf: karolherbst: what do you call BASE CLOCK?
10:37karolherbst: no idea for the right name yet
10:38karolherbst: but basically this are fixed clocks
10:38RSpliet: you might want to check the VBIOS repo for cases where there's more than one subentry per entry
10:38karolherbst: RSpliet: right
10:38karolherbst: mupuf: at least I found the clcoks there usually used for marketing ;)
10:38karolherbst: so the base clock and boost clocks
10:41karolherbst: mupuf: I think the tdp_clock there is the clok which lies inside the power budget
10:41karolherbst: in some forums it was told, when the "max" tdp percentage value is increased like from 110 to 120, the boosted clock also increased
10:42mupuf: karolherbst: very nice
10:42mupuf: but you know, you can just change the vbios and check what the blob does
10:43mupuf: that works quite well for clocks
10:43karolherbst: I can't :p
10:43mupuf: why no?
10:43karolherbst: it doesn't work on my gpu
10:43karolherbst: and I don't want to do X over ssh
10:44karolherbst: mupuf: maybe my gpu enforces a valid checksum?
10:44mupuf: they all do
10:44mupuf: but nvafakebios does the right thing here
10:44karolherbst: ohh okay
10:44mupuf: anyway, why would you need x over ssh?
10:44mupuf: nvidia-smi tells you everything
10:45karolherbst: messing with nvidia-settings
10:45karolherbst: ohh it does?
10:45karolherbst: have to check
10:45Tom^: also nvidia-settings --query :p
10:45karolherbst: mupuf: then I would have to see the boost clock and base clock there
10:45mupuf: you just can't document stuff you don't try
10:45mupuf: even if it looks super good
10:46mupuf: yep, it is super simple to do
10:47mupuf: rmmod nvidia; nvafakebios -e XX:YY vbios.rom; nvidia-smi --right_request
10:47mupuf: don't forget to rmmod though
10:48karolherbst: nvafakebios only does PRAMIN right?
10:48karolherbst: okay, I found the base clock in nvidia-settings --query all at least
10:49karolherbst: but not the boost clock
10:49karolherbst: only max clock
10:49karolherbst: and nvidia-smi tells me nothing
10:53karolherbst: mupuf: any other idea for a better name
10:53Tom^: karolherbst: https://github.com/NVIDIA/nvidia-settings/blob/master/src/parse.c#L149 here are some valid --query attributes
10:53karolherbst: yeah I know
10:54karolherbst: but for me there is nothing like boost=797 or something
10:54mupuf: karolherbst: hmm
10:54karolherbst: mupuf: if it helps, this is the content on my gpu: https://gist.github.com/karolherbst/6bc58523c8b299daff94
10:55mupuf: max clock is the maximum clock reachable by a perf lvl, right?
10:55karolherbst: mupuf: in nvidia-settings?
10:55mupuf: no idea
10:56mupuf: my finnish is quite bad, but it seems the shopping center I am in is closing... So I will talk to you later! Don;t worry a bout the naming yet
10:56karolherbst: ohh well, this table doesn't state "max clock" in that sense as far as I know
10:56mupuf: just try to change values and see what it actually changes
10:56mupuf: use pmu_fake_counters to fake activity
10:56mupuf: that should help :p
10:57karolherbst: mhh not really though
10:57mupuf: and you can test the normal and boost clock for each perf lvl
10:57karolherbst: it goes above the boost clock for me
10:57karolherbst: there is more to it
10:57karolherbst: maybe if the power budget is big enough, it just goes to max
10:57mupuf: well, that sounds like something good to RE :D
10:58mupuf: anyway, really have to go! You should use the tool I developed to dump the behaviour of the blob
10:58mupuf: change values, run a repeatable case, compare the values
10:58mupuf: make a theory and try again
10:58mupuf: see you!
11:08karolherbst: with 90°C it falls to the boost clock
11:09karolherbst: with 0°C the blob clocks a little bit above
11:09imirkin_: and with -297 degC? :)
11:09imirkin_: (or is it -273? i always forget)
11:09karolherbst: it clocks down with 80°C already
11:10karlmag: imirkin_: probably the slowest graphics animation you've ever seen :-P
11:10RSpliet: imirkin_ would Ti 4200 act differently than GeForce 256?
11:10imirkin_: RSpliet: hm?
11:11imirkin_: RSpliet: NV10 vs NV20 - sure
11:11RSpliet: I'd expect Kelvin to be cooler than Celsius :-P
11:11karlmag: Negativ Kelvin?
11:11imirkin_: ah. a joke.
11:11RSpliet: sorry, yes, I do that occasionally
11:13karolherbst: why does nvidia hate me so much
11:13RSpliet: don't take it personally
11:13RSpliet: they hate everybody equally
11:13karolherbst: I added a 6 into my grep statement
11:13imirkin_: RSpliet: yeah me too. just wasn't thinking clearly
11:14karolherbst: the boost clock is the clock nvidia uses when the temperautre is pretty high, but some other condition isn't met
11:14karolherbst: like maybe power consumption?
11:17imirkin_: RSpliet: how's fermi coming along?
11:21Tom^: karolherbst: do we really need boost now? cant that be left out and get power management running on base clocks?
11:21karolherbst: Tom^: well
11:21karolherbst: Tom^: base clock here: 705, boost clock: 797
11:21karolherbst: Tom^: nouveau uses 862
11:26karolherbst: RSpliet: I can manipulate the idle clock with that table
11:27karolherbst: but sadly not the boost one I think
11:33Tom^: sorry if im talking about stuff you already know, but to me it sounds like gpu boost is decided from a table with with stepups from base clock up to way beyond what its capable of, then the driver measures the GPU temp and makes sure its below a certain value, its also making sure the card is running under a certain "boost power consumption".
11:35Tom^: so doesnt that mean you can disregard boost entirerly for now and only clock up the card to base clock, and implent this later on?. or are that already sort of done and you are now looking at boost? :p
11:41karlmag: hmm.. looks like I pulled a couple G84 (8600 GT) and G86 (probably 8400 GS) today..
11:42karolherbst: mhh strange, but okay
11:42karolherbst: I think this boost value in the vbios is just an avarage number to be read out
11:42karolherbst: but is to no use otherwise
11:42karolherbst: maybe I am wrong
11:42karolherbst: who knows
11:44karlmag: karolherbst: when it comes to black magic.. possibly noone :-P
11:49karolherbst: any suggestion what I should change? https://gist.github.com/karolherbst/bce328f77c04bc8728e5
11:51karolherbst: ohh maybe I should add the unknown stuff
11:54karolherbst: RSpliet: I have an idea: maybe the pstate in this row tells the driver which pstate to use
11:54karolherbst: so if the header points to an entry with a 0xa pstate as the "base", it may idle at this when max perf prefered
12:01karolherbst: mhh maybe not
12:54karolherbst: Tom^: if you want we can try out other vbios where this table has a different version and see what the tool does then
12:54karolherbst: tomorow then
12:55imirkin_: karolherbst: tool doesn't run in wine?
12:59karolherbst: imirkin_: nope
13:00karolherbst: mono messes up
13:00karolherbst: and I don't get it to run in native .net as well
13:00karolherbst: imirkin_: https://gist.githubusercontent.com/karolherbst/d192c0040caeafada1d7/raw/95e1329534f475768b50efb50756032200a44b5d/gistfile1.txt
13:00karolherbst: I think the issue is quite trivial, but well
13:02karolherbst: this table can also be empty
13:02karolherbst: good to know
13:02Yoshimo: try #winehq on Freenode for help karol
13:03karolherbst: Yoshimo: it is a mono issue
13:03karolherbst: not wine
13:03karolherbst: I am like 100% sure they will tell me that :p
13:04Yoshimo: if you say native .net doesn't do it, why isn't that a wine issue?
13:04karolherbst: because my prefix is messed up
13:04karolherbst: have to clean it up
13:10RSpliet: imirkin_ slowly but steadily
13:10RSpliet: you've got my branch right?
13:10imirkin_: but i have no real way to tell how far you are based on that
13:11RSpliet: neither have I
13:11RSpliet: with two hours a week, I don't try to waste too much time on planning
13:11imirkin_: put another.... what works?
13:12RSpliet: well, practically nothing
13:12RSpliet: theoretically timing generation has two todo's, MR has two, script has an unknown amount of todo's
13:12imirkin_: gotcha :)
13:12imirkin_: iow almost done :p
13:13RSpliet: if you can arrange a tardis for me, I'll have it done last week
13:13imirkin_: just have to catch it
13:13imirkin_: all a matter of being in the right place at the right time :p
13:13RSpliet:holds up a butterfly net^h^h^h^h^h^h^h^h^h^h^h^h^hlacrosse-stick
13:14imirkin_: RSpliet: may i interest you in ^W?
13:14RSpliet: only if it's unicode
13:16karolherbst: Yoshimo: it seems like I need .net 3.5 for this
13:16RSpliet: get a Windows VM, give the VM your secondary GPU? :-P
13:17imirkin_: you can use the microsoft ie tester vm's
13:17RSpliet: or can it read bios files?
13:21karolherbst: yeah I will create a windows vm for a <100kb application
13:21imirkin_: but you would for a 1GB application?
13:22imirkin_: so why mention the size?
13:22karolherbst: I could just reboot to windows
14:31mlankhorst: karolherbst: no idea, haven't plugged it in in a while
15:06karolherbst: it is working :O
15:07karolherbst: finally :D
15:07jkucia: imirkin_: I think I isolated the issue. It's quite interesting bug. It seems that textureSize() and textureQueryLevels() returns info about a texture used in previous draw call...
15:08imirkin_: i like it!
15:08jkucia: I've got a small program which demonstrates the issue.
15:08imirkin_: jkucia: if you have an apitrace, that'd be most ideal
15:08imirkin_: although a small program is ok too
15:09jkucia: when you build it with -DBROKEN it shows the bug, otherwise works as expected
15:09imirkin_: i actually have to go right now, so i can't look at it QUITE this second, but could you file a bug with this, and make a mention of what gpu(s) this is broken on?
15:09imirkin_: jkucia: and please confirm that it's not broken on, say, llvmpipe
15:09imirkin_: or any other mesa-based driver
15:09imirkin_: [or conversely confirm that it's _also_ broken there]
15:10jkucia: ok, I'll file a bug
15:10imirkin_: thing is that tesla, fermi, and kepler are all pretty different in terms of texture setup
15:10imirkin_: hopefully it's equally broken on all fo them :)
15:11jkucia: ok, I'll provide all details in a bug report
15:11imirkin_: excellent, thanks!
15:40karolherbst: I found a really strange nvbios bug :O
15:40karolherbst: "BASE CLOCK table at 0x93c5, version 0"
15:41karolherbst: but byte 0x93c5 is 0x10
15:41karolherbst: and if I set the offset manualy in the parsing function, it works as expected
15:47karolherbst: can anybody tell me, where the offset is set?
15:47karolherbst: but this looks just plain odd
15:47karolherbst: and wrong
15:51karolherbst: I would give it to you, when I would now where the offset comes from
15:51RSpliet:sighs... I should've gone to bed an hour ago... but no way I was going to sleep without the tiniest bit of progress
15:52RSpliet: ... babysteps :-P
15:52karolherbst: but I can show you something else
15:52karolherbst: this line: https://github.com/karolherbst/envytools/blob/nvbios_unk38/nvbios/power.c#L692
15:52karolherbst: when I remove the if
15:52karolherbst: and set there bc->offset = 0x93c5
15:52karolherbst: it works
15:52karolherbst: which is just plain weird
15:52karolherbst: because the offset is right here either way: https://github.com/karolherbst/envytools/blob/nvbios_unk38/nvbios/power.c#L738
15:54karolherbst: maybe because it is a nvd7 card?
15:54karolherbst: I don't know
15:54imirkin: RSpliet: + for (i < 0; i < 9; i++) ?
15:55imirkin: probably not *exactly* what you wanted
15:56karolherbst: where is this?
15:56imirkin: in RSpliet's branch
15:56karolherbst: it was for him :D
15:56karolherbst: imirkin: you have the same color as RSpliet
15:56imirkin: that's why his name was in front of it...
15:57karolherbst: I will go too bed, maybe the mystery solves itself tomorow
16:02imirkin: jkucia: can you quantify "correct" vs "incorrect"?
16:02imirkin: jkucia: on gf108 with mesa 11.0.5, i get width: 512.000000 height 256.000000 miplevels 4.000000 for both
16:02imirkin: jkucia: but it's black with -DBROKEN and red without
16:02imirkin: er weird, now it's purple with -DBROKEN
16:03RSpliet: imirkin, it is actually
16:03imirkin: RSpliet: i think it's more common to use i = 0 rather than i < 0
16:03RSpliet: oh, that isn't
16:03imirkin: (is the loud thud i heard you hitting your head against the desk?)
16:05RSpliet: feedback like above saves me two hours of making such a noise
16:06karlmag: "desk for small problems, brick wall for the bigger ones" :-P
16:07jkucia: imirkin: I get width: 2.000000 height 2.000000 miplevels 2.000000
16:08imirkin: jkucia: what gpu?
16:08jkucia: GTX 760 (NVE4)
16:09imirkin: hm ok
16:09imirkin: what mesa?
16:09imirkin: that's an awful lot like my mesa version :)
16:10imirkin: the real question is why did DRI_PRIME stop working for me...
16:12imirkin: libGL: screen 0 does not appear to be DRI3 capable
16:12imirkin: how do i constantly keep breaking it
16:18imirkin: anyone else have a kepler can can confirm jkucia's findings?
16:48jkucia: imirkin: I've filed a bug report. It's bug 93110. Time to sleep for me.
16:49imirkin: jkucia: thanks!
16:50imirkin: i'll try to get some more detailed info to figure out what's going on... probably something dumb as usual :(
16:51skeggsb: imirkin: doesn't happen on gk107..
16:52imirkin: uhhhhhh that's a little more frightening
16:52imirkin: i was assuming some sort of tic mismanagement (it's different on kepler) or perhaps a cache flush not quite working
16:53skeggsb: i don't *think* i did anything wrong...
16:54imirkin: that's what i get too.
16:54imirkin: on GF108
16:54imirkin: GK106 has a lot more ... TPC's? whatever they are, it's got more of 'em
16:54imirkin: so perhaps it's some nasty parallelism and we have to serialize? that'd be most sad.
16:54skeggsb: i can try on gk106 easily enough
16:55skeggsb: lemme just swap boards...
16:58skeggsb: nope, that works too
16:59imirkin: hmmmmmm i wonder what's going wrong for jkucia then
17:00skeggsb: hrm, maybe got fixed accidentally by some other change? he's on 11.0.5
17:00imirkin: could be
17:00skeggsb: my gk106 is on 11.1.0-devel (git-0bf686f)
17:01skeggsb: gk107 on Mesa 11.2.0-devel (git-7f203a7)
17:01skeggsb: that commit id likely doesn't exist upstream, i've got other stuff on top
17:02imirkin: maybe. texture stuff doesn't move *too* often
17:02imirkin: i did have some fixes, but iirc they were around texture buffer's getting their bo's changed from underneath them
17:03imirkin: (i.e. backing bo changes, but tic doesn't get updated)
20:10imirkin: crap, just found a huge bug in the nv50 emitter -- the instructions used to spill flags to registers were encoded wrong!
20:11imirkin: bugs, bugs everywhere
20:11imirkin: and not a drop of docs
20:12imirkin: but at least it was consistently broken -- the spill stored the wrong flag value, and the unspill restored it to the wrong place
21:43tagr: mlankhorst: I'll ask around if we have a seeding program like we did for Jetson TK1
21:43tagr: units are always in short supply, so it might take a little while before we get some allocated