00:48hakzsam: imirkin, nice, I know what bugs you are trying to fix up now :)
03:52eijebong: Hi, got a little problem. Nouveau is now working (DRI3), but I don't see my HDMI port in xrandr.
03:53eijebong: http://paste.bananium.fr/?cff0dd5aecf12bd9#kq9+gCGj3QZ0ftTvcN109G+thhwFO18qF8z7FsEB+BQ= My xrandr output
04:04karolherbst: eijebong: that's normal, because xrandr only shows output connected to intel
04:05karolherbst: its stupid that there are laptop maufacturers out there, that do something like that :/
04:06karolherbst: eijebong: the "best" workaround for that I know is to start a second X server on your nvidia card and just connect the display to it
04:06karolherbst: but its messy
04:08karolherbst: eijebong: ohh wait, there is actually
04:09karolherbst: https://wiki.freedesktop.org/nouveau/Optimus/ ""Using outputs on discrete GPU"
04:09karolherbst: but seems to be DRI2 only :/
04:20eijebong: Yep, I tried, I see my DP after that :p
04:21karolherbst: I have a second laptop here with the same problem
04:21karolherbst: would be nice to be able to actually use it
04:21eijebong: Yes :/ Beh, my screen has a VGA port so... I'll use it
04:23karolherbst: I see
04:47karolherbst: mupuf: did you wrote the nvkm_volt_map function?
04:48mupuf: I don;t think so
04:48mwk: there's a new RE blog post about VP1
04:48mwk: I changed the CMS, so RSS feed address is different, in the unlikely case anyone bothered :p
04:48karolherbst: beacause I try really hard to understand this function and it doesn't make much sense
04:50karolherbst: its the source of the voltage mismatch at least for me
04:50karolherbst: it somehow calls itself recursively and sums up each returned value
04:51karolherbst: like for id 47 it returns 962500, which is the min voltage of the ID47 (9000000) + VID 52 (6250) + VID 2(0)
04:51karolherbst: from the Voltage map table
04:51karolherbst: I don't understand why the voltage are summed up there
04:52karolherbst: btw: 47 has link 34 and 52 has link 2
04:55skeggsb: karolherbst: because, in some form, that's what the nvidia binary driver does
04:55karolherbst: I see
04:55skeggsb: as i've already told you, our code is *incomplete* and probably needs some kind of merging with what the gk20a code does
04:55skeggsb: it's correct for the very simple cases, but there's more complex configurations
04:56skeggsb: the gk20a code doesn't do the summing, and it's not entirely impossible the algorithm is different, but i'd bet money on it being a similar idea
04:57skeggsb: it needs work to reverse engineer, not to be hacked around.. plus, you need an entirely different voltage setting method implemented too
04:57karolherbst: I just have the problem, that somehwere a comparison between values is failig the the entire nvkm_volt_set_id fails
04:57karolherbst: *and the nvkm_volt_set_id fails
04:57karolherbst: I see
04:57skeggsb: yes, because we've never seen the pwm voltage regulator before, so it's not supported
04:57hakzsam: mwk, link?
04:58mwk: hakzsam: unchanged, http://reblog.0x04.net/
04:58karolherbst: gk20a is tegra?
04:59skeggsb: but that "cvb" table looks suspiciously like what we find in the vbios tables
04:59karolherbst: whats the c0 value?
04:59skeggsb: "cooeficient 0"
04:59karolherbst: yeah well
05:00skeggsb: and, if you look at nvkm/subdev/bios/vmap.c... you'll see we parse 6 cooeficients from vbios tables too
05:01skeggsb: in the simplest form, only c0 is used, and added together (following the link)
05:01skeggsb: but, it's much more complex than that in reality :)
05:02karolherbst: mhh, and I thought i could have been that simple: get voltage id from cstate, look the voltage up, set it :D
05:02skeggsb: it used to be
05:02skeggsb: it's not now
05:02skeggsb: nvidia like complexity :P
05:02karolherbst: he voltage table in gk20a is pretty small though
05:03mupuf: skeggsb: I had a look again at the PWM-based voltage control
05:04mupuf: Found a pwm controller at 10eb30 that looks promising, but changing it does not crash the gpu, so it probably is not doing anything
05:04mupuf: I will continue looking into this
05:05mwk: umm what
05:05mwk: voltage controlled through gpu-based PWM?
05:05mwk: that's several kinds of crazy
05:05mupuf: mwk: yeah...
05:06mupuf: and the frequency is of course really high
05:06karolherbst: skeggsb: I think you know this already but I don't get a true there: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/volt/base.c#L52
05:07karolherbst: uv us the value from the map function
05:09skeggsb_: that's better... laggy connection to the office
05:09karolherbst: did you get my last messagE?
05:09skeggsb_: karolherbst: yes, that's not suprising because a) we don't use all the cooefficients and b) it's entirely possible that we might need a more fuzzy matching there.. not something i'm willing to do until we've ruled out correct parsing making it unnecessary
05:10karolherbst: I found something interesting
05:10karolherbst: this 6250 seems like the difference between the entries in the voltage table
05:10karolherbst: ID 35: 812500 ID 36: 818750
05:10karolherbst: and so on
05:10skeggsb_: you *could* try asking nvidia on that email list for info on the bios tables, and how to use them, and where to find the "speedo" value on discrete gpus
05:10skeggsb_: but... i wouldn't hold my breath
05:11skeggsb_: it doesn't really matter what the values are, they differ wildly on different boards
05:11karolherbst: yeah, make sense
05:11karolherbst: because the difference was also parsed
05:15karolherbst: skeggsb_: what do you say about a fallback mechanism, where a voltage is used which is close eough at the requested one? We had somebody here, who could switch to 0a pstate without problems (so he can set his voltage), but it didn't work for 0f
05:15karolherbst: so he has a ~900MHz clock on 0a, but only 405MHz on 0f
05:15karolherbst: core clock
05:15skeggsb_: *or* you/we/i/someone can fix the code to do it properly
05:16karolherbst: a fallback would also work in the future, when something changes again, at least that was my idea behind it
05:16karolherbst: it should be fixed properly anyway, yes
05:16skeggsb_: it could also lead to us *royally* fucking up and killing someone's card
05:17skeggsb_: i'd rather just be overly paranoid and fail than to risk that
05:17karolherbst: I heard otherwise already here :)
05:17karolherbst: but yeah, I would also be rather carefull than do somethig like that just because, so I am asking how something like that "could be safe"
05:17karolherbst: or is it too much guessing at this stage?
05:18skeggsb_: it's unlikely, but i'd rather be extremely paranoid
05:18karolherbst: okay, second idea
05:18skeggsb_: the chances of us fucking up even when we *think* we're doing the right thing are large :P
05:18karolherbst: nvkm_cstate_prog just fails if volt->set_id fails
05:18karolherbst: what if nouveau would set the clock nethertheless?
05:19karolherbst: like the driver never set the voltage and nouveau would increase the core clock from 405 to 862MHz (like on my card)
05:19mupuf: karolherbst: I was not advocating shipping wrong code, just saying that when REing, you should not be worried
05:19karolherbst: mupuf: ahh, k
05:19skeggsb_: yes, i've not yet killed a board
05:20skeggsb_: though, i'm suspicious about the gm204..
05:21karolherbst: another thing is: what would happen if the core was clocked to something like 1000MHz with the voltage set accordingly and then in the future because of auto reclocking it tries to set to something really low, 200MHz, but won't set the voltage?
05:21karolherbst: or are both situations just like everything could happen
05:22mupuf: karolherbst: it is safe to keep the voltage higher than needed
05:22mupuf: it is not to do the opposite
05:22karolherbst: so hight clock but low voltage is bad?
05:23mupuf: makes sense, doesn't it?
05:23mupuf: maybe I spent too much time on thus
05:23karolherbst: bad in "card damage" or as in "instable"?
05:24karolherbst: okay, so its safe for me to still reclock my card I guess :)
05:25mupuf: it's simple, when you increase the frequency, you are asking the processor to finish its computing in less time
05:25mupuf: as in, the output should be stable before the next clock cycle
05:25karolherbst: yeah, I kind of figured, but I never "needed" that kind of thinking yet :)
05:25mupuf: when the voltage is set too low, it takes longer for the output to stabilize
05:26mupuf: and it is too low when the stabilisation takes longer than the clock cycle
05:26mupuf: as simple as this
05:27mupuf: now, the problem of keeping the voltage to high is the additional power consumption
05:27mupuf: too high*
05:27mupuf: due to the static and dynamic power consu;ption (look them up)
05:27mupuf: that's it
05:28karolherbst: so the worst what could happen is, that the fans are too loud or the card just gives up because of overheating
05:32mupuf: even that
05:32mupuf: the computer should shut down when the card overheats
05:32mupuf: speaking about this, there is this easy patch that I need to write that will cut the voltage of the overheating gpus
05:33mupuf: so as even if the machine does not stop because of a stupid sw bug, the hw will take care of itself
05:33mupuf: and there is the same for having the fan set to max
05:33mupuf: but not all pwm controllers have the bits to control that
05:48mwk: good old vp1...
05:48mwk: "Mismatch on try 1374248"
05:48mwk: that's over 1h of testing
05:50karolherbst: k, this wasn't good :/
05:50karolherbst: was trying to start some games through PRIME and d3d9 tracker in wine and now the staging physx patches loaded the cuda library and blob module :O
05:53mwk: so there's an interaction when ldax* instruction is used together with mov $r to $v in the same bundle, they target the same $v register, and the condition flag in ldax* actually causes the load to happen
05:54mwk: an event with apparently 1 in a million probability even after I biased the random number generator to emit a lot of special mov instructions
05:55mwk: I wonder how many iterations I need to throw at it before it truly covers all cases
06:04mupuf: mwk: AHAHAHAH
06:05mwk: it's already taking ridiculously long to finish
06:05mupuf: it does finish?
06:05mwk: mupuf: well, when I used 1 million iterations, it did
06:05mupuf: ah, right
06:06mwk: when I bumped to 5 mil iterations, it failed on iteration 1374248
06:06mupuf: how do you manage to track down what happened when something goes wrong?
06:06mwk: when it fails, it prints *everything*
06:06mupuf: you try to trim down the issue by looking at all the generated instructions?
06:07mupuf: it prints 1.3 million instructions in your case?
06:07mwk: the instruction it executed, the before-execution processor state, the after-execution processor state, the after-simulation processor state
06:07mwk: oh, no
06:07mwk: only the last instruction
06:07mupuf: ok, doesn;t sound as crazy now :D
06:07mwk: I try really hard to make sure iterations cannot affect each other
06:08mwk: when it doesn't work (and this did happen a few times), I usually search for instructions to disable so that the failure disappears
06:09mwk: to find the instructions that modify whatever unknown state caused the failure
06:09mwk: that's where the second safety comes in: I use deterministic RNG
06:09mupuf: that would be suicidal otherwise, yes :D
06:09mwk: so, as long as I don't get random effects from the card itself, two hwtest runs are *identical*
06:10mwk: I also have per-iteration seeding in my TODO list
06:11mwk: so I can skip straight to iteration 1374248 with the exact same RNG state as if I have actually executed all preceding iterations
06:11mwk: I already have something like that implemented, but only on testcase level, not per-iteration
06:12mupuf: sounds fun
06:13mwk: also, one day I'll have to plug a better RNG
06:13mupuf: which one are you using now?
06:13mwk:uses rand48... its only advantage is that it's fully defined by POSIX and thus perfectly determnistic
06:14mwk: otherwise it's utter crap
06:14mwk: well, it does get the job done, so maybe I'm complaining too much... but I'd feel safer with a higher-grade RNG
06:18mwk: as in, every time I had a known bug in the simulator with a reasonably probability of occuring, hwtest did find it eventually
06:36mwk: oh joy, another openssl fuckup to patch
06:43karolherbst: like always
06:46karolherbst: but it would be less fun without security problems, wouldn't it?
06:48karolherbst: also I can't understand how someone really can assume any software is "secure"
06:52karolherbst: meanwhile some US politicans want to make good encryption illegal :D
06:52karolherbst: I think today or yesterday was a talk about this in the senat?
06:53mupuf: karolherbst: yeah! Back 20 years ago where using strong encryption keys was illegal
06:54mupuf: strong meaning more than 128bit symmetric keys
06:54karolherbst: yeah I know
06:54karolherbst: allthough today there is still some law
06:54mupuf: anyway, screw them. They cannot check easily how strong is a key anyway
06:54karolherbst: prop java is only allowed to support 1k keys
06:54mwk: mupuf: wasn't it something ridiculously low like 40 or 56 bits?
06:55mupuf: I guess it was first like that, yes
06:55mupuf: anyway, they are bound to fail
06:55mupuf: even if we limited ourselves to dumb crypto, stegano would help
06:59sooda: what do you mean they can't check? it's easy, if your encryption isn't reversable realtime by the friendly folks at NSA then you get fined :P
06:59karolherbst: its so funny, news today: "somewhere computer problems, but it ISN'T a hack" yeah like if there is a problem it has to be a hack usually
06:59karolherbst: sooda: +1
07:00karolherbst: I bet we underestimate the big data centre and its just a big 3D table
07:00karolherbst: every key with every possible encrypted text
07:01mupuf: sooda: hehe, unless they had a breakthrough after snowden's leaks, then they definitely can't do that
07:02karolherbst: yeah maybe you need too much storage for that
07:02karolherbst: but after the whole situation they are around 5 years ahead anyway
07:07karolherbst: mupuf: btw, is there anything I could do with the RE thing or is it simply a time problem and its done when its done?
07:08mwk: mupuf: snowden leaks were actually arranged by nsa to make you think that!
07:08mwk: it's all part of the conspiracy, you see :p
07:09mwk: well, my big 5mil test is still running... too bad I'll probably have to kill if I want to figure out bundles today
07:23mupuf: karolherbst: well, it is a bit hairy to find the pwm controller
07:23mupuf: because it is like looking for a needle in a haystack
07:23mupuf: and you can't burn the whole thing and then you a magnet to find it :D
07:24karolherbst: yeah still, I've got some time
07:25mupuf: well, not sure if I can help you then
07:31karolherbst: sadly I've never done RE myself :/ so I really don't know where to start getting the pwm controller at all :(
07:31mupuf: right, this is not the easiest to start with, I guess
07:31mupuf: once we have the reg address
07:31mupuf: you can start poking stuff and see the result
07:32karolherbst: then I might get back to test software until I can do something more usefull
07:33karolherbst: I don't think this voltage fallback will be ever safe enough for mainline, but its still bad for somebody with that problem
07:33karolherbst: especially with mostly stable 0f state
07:34karolherbst: mupuf: do you have a clue if setting boost frequencies are working i "theory"?
07:34karolherbst: because then I could also write an interface for boost clocks like I did for cstates
07:36karolherbst: imirkin: do you have some time? If you would like I could create that talos trace for you
07:38mupuf: karolherbst: you can try REing the voltage map table
07:38mupuf: the idea is to modify your bios and see how nvidia programs the hw
07:38mupuf: you will have to use reator for that
07:38mupuf: since your card won't work
07:39mupuf: because we do not know how to read back the voltage
07:39karolherbst: yeah, right, let me think about that
07:39mupuf: fun, right?
07:39karolherbst: I guess this means I just write some values through nvafakebios unload nouveau and load nvidia
07:40karolherbst: and see what it does?
07:40karolherbst: I also have a fermi card here
07:40mupuf: and then start again
07:40mupuf: oh, then you can do that :)
07:40karolherbst: 630M though
07:40mupuf: well, check the voltage map table
07:43karolherbst: with nvbios?
08:01karolherbst: imirkin: your trace is ready
08:01karolherbst: mupuf: okay
08:09karolherbst: mhh strange, I only get 64kB/s download speed, this is very bad if you want to install build tools
08:21karolherbst: mupuf: so everything is set now
08:37karolherbst: mupuf: like how should I check for differences? Should I just open some nvidia tools and look whats different there? Or to put it different: how can I verify, that I hit the right think, that for example the voltage has changed
08:42mwk: and done
08:42mupuf: you need to read back the VID back from the GPIOs
08:42mwk: turns out the bundling algorith is dead simple
08:42mupuf: but mlankhorst may have a script for that
08:42mupuf: mwk: so, this CAN happen :D
08:48karolherbst: would be nice to have a script :) will make it much easier for me
08:49karolherbst: where I have to write stuff should be all in the bios somehow I guess
08:49imirkin: karolherbst: well there's nvapeek to read things and nvapoke to write things
08:50imirkin: karolherbst: what trace btw?
08:50karolherbst: imirkin: talos
08:50karolherbst: I've created a 80MB one
08:51mupuf: karolherbst: I would really advice you to have a script to read back the vid
08:51mupuf: otherwise, you will be likely to make mistakes when reading the number
08:51karolherbst: but llvmpipe only displays a black windows for the serious stuff
08:52karolherbst: imirkin: this bug: https://bugs.freedesktop.org/show_bug.cgi?id=90513
08:54imirkin: it might use a feature that llvmpipe doesn't have
08:54imirkin: or perhaps it's using buffer storage, in which case the trace won't work
08:54mwk: and VP1 episode #25 finished
08:54imirkin: when you replay it on nouveau does it work ok except for the green walls or whatever?
08:54mwk: a lot of things should start to make sense now
08:55karolherbst: imirkin: yeah
08:55karolherbst: works on intel, too
08:55karolherbst: without the green walls
08:55imirkin: well, i can take a look
08:55karolherbst: still uploading though :/
08:55imirkin: hehe ok
08:56mwk: now I just need to figure out branch delay slots and I could actually have a shot at decompiling stuff...
08:56karolherbst: imirkin: which feature could it be?
08:56karolherbst: I use mesa master
08:56imirkin: karolherbst: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
08:57imirkin: compare llvmpipe to your gpu. enjoy :)
08:57karolherbst: well this side is a little bricked for me
08:57imirkin: you can select just those 2 gpu's and select "diff"
08:57karolherbst: hey, the css isn't https
08:57imirkin: neither is the html
08:57karolherbst: browser plugin I guess :/
08:58karolherbst: yeah, the non https version works
08:58imirkin: normally i use // instead of http://
08:58imirkin: but i wanted this to work off a local file system
08:58karolherbst: imirkin: https://secure.freedesktop.org/~imirkin/glxinfo/glxinfo.html ;)
08:58imirkin: in which case // doesn't do at all what you want
08:59imirkin: perhaps there's some clever way around that, but i stopped working heavily in that space before i learned such a thing.
08:59karolherbst: mhh, there are indeed some
09:00imirkin: could be ARB_sample_shading
09:00imirkin: i doubt they use ARB_gpu_shader5
09:00karolherbst: should I create a trace with those extensions disabled?
09:01imirkin: well, the issue should be apparent from replaying the trace
09:01imirkin: glretrace should be screaming its head off when replaying on llvmpipe... figure out why
09:02karolherbst: yeah, it does
09:02karolherbst: imirkin: https://www.dropbox.com/s/hiwgrf4i6kw5aue/talos.trace.xz?dl=0
09:05karolherbst: its GL_EXT_texture_filter_anisotropic
09:06karolherbst: mupuf: the nouveau work on the fermi card may take time until I can start, because its not the laptop I use and I have to get X working correctly before doing much more
09:06glennk: try softpipe, it should have that extension
09:06karolherbst: how can I decide which I get?
09:08karolherbst: glennk: would be nice to have it here: http://mesa3d.org/envvars.html :D
09:08karolherbst: its slow though
09:09glennk: thats a hint to go for some coffee, or food
09:10karolherbst: or fix stupid ubuntu won't start X correctly if nvidia is installed issue
09:10karolherbst: but its nearly there
09:11karolherbst: does SOFTPIPE_USE_LLVM help a bit?
09:11karolherbst: I see something from the game :)
09:12karolherbst: ohh my, softpipe is single threaded?
09:12glennk: its a reference driver, don't expect it to be fast
09:12karolherbst: yeah I know, but still
09:13karolherbst: 3 spf :)
09:18karolherbst: imirkin: softpipe seems to be fine
09:27imirkin: well, i saw it flicker on my nvc0 as well... but like once in that whole trace right?
09:27imirkin: karolherbst: no aniso shouldn't cause the screen to go black
09:28karolherbst: should I do a x11grab?
09:28imirkin: karolherbst: i mean, i only saw the walls turn green on a single frame
09:28karolherbst: there are some of them
09:28karolherbst: that might be
09:28imirkin: there was a bunch of shadow-related flickering though
09:28imirkin: and there was a weird purple thing, but i think that might be part of the game
09:28karolherbst: I can explain the green thing maybe
09:28imirkin: a wall section off to the side or something
09:28karolherbst: it may be right but wrong color
09:29karolherbst: the game has wierd "glitches" which are part of the game
09:29karolherbst: so part of walls are for a brief moment glitched and stuff
09:30imirkin: but not to a solid color right?
09:30karolherbst: I don't know for sure
09:31karolherbst: I had the green wall effect twice
09:31karolherbst: one time at the gate
09:31karolherbst: and second time at the wall on the right to it
09:31karolherbst: intel looks completly fine
09:32karolherbst: so I don't think there was any of the glitches
09:43karolherbst: imirkin: is the trace fine or do you need a different one?
09:43imirkin: karolherbst: it's fine....
09:44imirkin: karolherbst: did you turn off most of the features that you could btw?
09:44karolherbst: gpu core set to lowest
09:44karolherbst: there are a LOT of options
09:44karolherbst: like 50 alone for gpu core
09:44imirkin: but presumably dynamic lighting is on
09:45karolherbst: allthough its a deactivation switch
09:45karolherbst: which is on on lowest
09:45imirkin: coz who doesn't like double-negatives... don't not deactivate dynamic lighting
09:46karolherbst: its the only one I think though
09:46karolherbst: seriously ubuntu?
09:47karolherbst: I have not to blacklist nvidia, but nvidia-352?
09:47imirkin: why make something simple when you can make it complicated
09:47imirkin: i feel like that's the driving philosophy of everything ubuntu
09:48karolherbst: there are worse out there
09:48karolherbst: arch :p
09:48imirkin: that's the only one that comes to mind
09:48imirkin: nah... arch is fairly simple. it's made a lot of choices i don't like, but that doesn't make it complex
09:48karolherbst: every looked into the PKGBUILD files?
09:49imirkin: they're just a copy of the gentoo ebuilds
09:49karolherbst: because you have to issue all commands yourself in arch
09:49karolherbst: git is a thing you mostly do yourself there
09:49karolherbst: in gentoo you usually don't do anything about it
09:50imirkin: but that's expected for a binary distro
09:50karolherbst: how did I do that?
09:50karolherbst: I meant like more
09:51karolherbst: in gentoo you declare, that the project is using git, and all the stuff is done inside already written functions
09:51imirkin: right. coz it's built from source.
09:51karolherbst: or is arch considered binary distro?
09:51imirkin: but it's expected that a binary distro wouldn't have that
09:51imirkin: i dunno. i consider it a binary distro :)
09:51imirkin: as binary as ubuntu or redhat
09:51karolherbst: I thought you can build everything yourself if you want
09:52imirkin: i mean, they have srpm's and whatever-deb-thing too
09:52imirkin: as you can on all the other binary distros
09:52imirkin: you just get to suffer for it
09:52karolherbst: I see
09:52imirkin: as on all the other binary distros :)
09:52karolherbst: I thought its easier on arch though
09:52imirkin: perhaps. you might suffer less.
09:53imirkin: i haven't measured the quantity of suffering by distro tbh :)
09:53mwk: eh, I forgot just how much of a mess is there in hwdocs
09:53imirkin: mwk: lots of "insert docs here" bits :)
09:54mwk: that's not that bad
09:54mwk: the formatting errors are worse
09:54mwk: and the unfinished custom syntax
09:54karolherbst: but what most annoys me about arch isn't their technical stuff, but like they wiki. Its fine if you want to do really low level and stuff you usually don't want to do, but most of the time it's just too much :/
09:55karolherbst: mupuf: okay, the fermi laptop is ready to go know, I will still wait for mlankhorst I guess
09:56imirkin: i think that mlankhorst's script may have been overstated... it works on *his* gpu... that's it. afaik.
09:56imirkin: and not even there
09:56karolherbst: imirkin: let me put it that way: if I can see in which order I have to do something, this would already help me
09:57karolherbst: that I have to figure out addresses or something, fine, I can live with that
09:58imirkin: there's some highly prelim stuff in the kernel already
09:58imirkin: but no one's done proper RE on it afaik
10:06imirkin: karolherbst: ok, so the first step in analyzing your trace is to isolate the frame where things go green
10:09imirkin: looks like frame 1166
10:11karolherbst: how do I check this fast?
10:11imirkin: i'm creating a trimmed trace which will only have that one frame
10:11imirkin: plus the 1k frames to set up the damn thing... ugh
10:13imirkin: gah that didn't work
10:13imirkin: i wonder if it's non-deterministic...
10:14karolherbst: seems at the same position for me all the time
10:15imirkin: nope, deterministic. always 1166
10:16imirkin: which means it's in one of the new programs... 1827, 1829, 1839, 1822, 1834, 1832
10:21imirkin: guessing shaders 1617 or 1681...
10:23karolherbst: 1166 is also for me faulty
10:23karolherbst: the tree also looks different
10:24karolherbst: imirkin: what about 1140?
10:27karolherbst: no its 1139=
10:28karolherbst: I have to get used to the tool first
10:29karolherbst: no its 1138 for sure
10:30karolherbst: imirkin: 1138 and 1166 faulty for me
10:36imirkin: oh yeah. 1138 also looks bad.
10:37imirkin: oh well, doesn't really matter
10:37imirkin: didn't notice it when looking at the thumbnails
10:37imirkin: (qapitrace has a mode that screenshots every frame)
10:37karolherbst: they are very small though
10:38imirkin: yeah. and the 1166 one was a lot more noticeable :)
10:38karolherbst: yeah I think its also the better one to look at
10:38karolherbst: less calls
10:38karolherbst: and the tree is also faulty
10:38karolherbst: may help with assumptions
10:38imirkin: well.... one thing at a time
10:39imirkin: i don't have time to look more at it now
10:39imirkin: but i suspect it's a draw that uses program 1834
10:39imirkin: so look for glUseProgram(1834)
10:39imirkin: and the draws that follow and precede it
10:39karolherbst: is there no stepping mode? :/
10:40imirkin: infuriatingly, no
10:40imirkin: which is why i wanted the shorter trace :)
10:40imirkin: perhaps it's high time to check out vogl
10:40imirkin: or whatever the valve thing was called
10:41karolherbst: yeah, will check the calls
10:41karolherbst: it doesn't take too long though
10:43karolherbst: imirkin: one texture has somethig green in it in the call before glUseProgram(1834)
10:43karolherbst: the tree
10:43imirkin: could be an earlier program then
10:44imirkin: the guess of program 1834 was based on the fact that it used much "newer" shaders than the rest
10:44imirkin: (in terms of ids)
10:44imirkin: it could also be that those guesses were totally wrong
10:44imirkin: since they were merely based on looking at the errors i got from replaying the trimmed trace
10:44imirkin: which didn't show the green effect
10:44karolherbst: in the framebuffer the tree isn't green but the wall
10:45karolherbst: ahh I see
10:45imirkin: but it could well have been a blit shader that didn't blit the green to the screen for all i know
10:49karolherbst: imirkin: I have no clue about opengl. Should I just search the call which is turning the wall green in the buffer, or is it a glUseProgram call?
10:50imirkin: it's a glDraw* call
10:50imirkin: basically opengl is glBlah() which updates a bunch of state
10:50imirkin: and then glDraw*() which makes use of that state
10:50karolherbst: yeah, that far I got it somehow
10:50imirkin: there's glDrawArrays* and glDrawElements*
10:51imirkin: (and also glEnd() if you go far enough back in time)
10:51imirkin: those are the only functions that will draw
10:51imirkin: oh, and glDrawPixels. heh.
10:51imirkin: but nobody uses that.
10:51imirkin: everything else is about setting up state for that draw
10:51karolherbst: okay, so I just find the right call
10:51karolherbst: and then we could track back how it got green?
10:51imirkin: qapitrace has a thing to filter calls
10:52imirkin: wait. i just realized i wasn't running off of git
10:52imirkin: on git it looks much better...
10:52karolherbst: what looks better?
10:52karolherbst: mesa git or apitrace
10:52imirkin: or rather, much worse...
10:52imirkin: the screen is cut off
10:53imirkin: well specifically my local git tree
10:53imirkin: where i might have questionable patches :)
10:53karolherbst: I use mesa master
10:53karolherbst: so don't know
10:53karolherbst: you could show me how it looks
10:53karolherbst: and then I say yes, it looks the same
10:54imirkin: no it's totally messed up
10:55imirkin: compared to mesa 10.6.1
10:57imirkin: things are being clipped
10:57imirkin: and there's a weird overlay over the top
10:57imirkin: i'll look into it later.
10:58imirkin: i gtg
10:58karolherbst: the first glDraw call already has something green in the framebuffer
10:58karolherbst: k, I will toy around a bit
11:02imirkin: karolherbst: well make sure you update too. perhaps i pushed something dumb
11:02imirkin: (or someone else did)
11:02karolherbst: I should ignore the tree, it won't help
11:02karolherbst: mesa built (03:42:58 PM 07/09/2015)
11:02imirkin: heh ok
11:02imirkin: i haven't pushed antyhing today
11:02imirkin: and i assume there's some sort of git pull before the build?
11:03karolherbst: live ebuild
11:21mlankhorst: imirkin: indeed, it is just a replay of what nvidia does. :P
11:23karolherbst: mlankhorst: hi :) I heard you have some kind of script for reading out VIDs?
11:23mlankhorst: might have, was just a hack
11:24karolherbst: yeah, It already sounded like that
11:24karolherbst: I just wanted to toy a little bit with my fermi card and see if I manipulte them somehow
11:25mlankhorst: http://mblankhorst.nl/~mlankhorst/ had them there, modvolt testvolt and dumpvolt
11:25karolherbst: imirkin: its call 1710787 glDrawElementsInstancedARB
11:25mlankhorst: but its very hardcodec, need to adjust the offsets for your card
11:26mlankhorst: and the volt gpio's too
11:27karolherbst: mlankhorst: I am like very new to RE, so I've never done it
11:27karolherbst: just seeing the scripts will give me a feeling about what I have to do
11:28karolherbst: mlankhorst: can modvolt not be done through nvafakebios directly without modding the bios file?
11:28karolherbst: or what can I do with the -e parameter?
11:36karolherbst: mlankhorst: dumpvolt ran under nvidia driver?
11:39imirkin_: karolherbst: cool. i'll look into it later. it can be easy to misidentify the call in a dynamic lighting situation
11:39karolherbst: I see
11:39karolherbst: there are only a hand full gl* calls between the last glDraw call
11:39karolherbst: and the wall is drawn in this call
11:39karolherbst: the wall is green since it is drawn
11:39karolherbst: its very early
11:41karolherbst: mlankhorst: maybe it would help me to know which card you used and maybe if you have the nvbios output, so I can understand what you did there
12:10RSpliet: mwk: are those actual branch delay slots?
12:14mwk: um, yes
12:14mwk: what would a non-actual branch delay slot be?
12:20RSpliet: well, if you word it that way I guess they would be either imaginary or hypothetical branch delay slots
12:20RSpliet: but jokes aside
12:21RSpliet: I was just missing the context of *branch* delay slots from your commit message, so I certainly hope you don't mind me asking you for clarification ;-)
12:21imirkin_: RSpliet: it's instructions that execute after the branch instruction... some arch's end up only jumping on the next cycle
12:22imirkin_: (mips comes to mind from the "usual" arches, i'm sure there's tons more)
12:22mwk: sparc my love
12:24imirkin_: hah didn't realize sparc also had it
12:24imirkin_: but makes sense
12:24imirkin_: it was all the rage in the RISC days
12:24mwk: fun fact: on a normal CPU, you have to save PC on an interrupt
12:25mwk: on sparc, you have to save PC and nPC :)
12:25mwk: and you can do crazy shit like stuffing a branch instruction into a delay slot... which results in single-stepping the target
12:25imirkin_: another fun fact: normal cpu's don't have a "set cpu on fire" instruction reachable from userspace.
12:26mwk: unless it's *also* a branch instruction, in which case... eh, just don't do that
12:26mwk: now, let's see which crazy variant of branch in delay slot is implemented on VP1
12:31RSpliet: imirkin_ I know the concept, thanks :-)
12:31imirkin_: RSpliet: ok. wasn't sure what you were asking then
12:33mwk: hwtest doesn't care about "just don't do that" :)
12:38mwk: btw, there are plenty of delay slots on vµc... not just branch delay slots
12:38mwk: load delay slots, multiplication/division delay slots, load from $sr delay slots... the whole thing has almost no pipeline interlocks, it's the programmer's problem
12:39mwk: *that* is a fun ISA
12:39imirkin_: adreno has that
12:39mwk: and the division instruction has 30 or so delay slots
12:39imirkin_: makes scheduling a *lot* more important
12:40mwk: so you get to write 30 nops in a row if you have nothing else to do while waiting for the result
12:45karolherbst: mupuf: would it work to just mmiotrace while nvidia-settings is happily reclocking the card?
12:46karolherbst: would it make sense to mmiotrace while I watch the nvidia driver reclock the card in nvidia-settings?
12:46imirkin_: karolherbst: will be difficult to tell what's going on in the trace
12:46imirkin_: usually i 0xff out all the pstates except one before loading the blob
12:46imirkin_: then i know it is setting that pstate
12:46imirkin_: i.e. set the id to 0xff
12:46imirkin_: with nvafakebios
12:47imirkin_: make sure to do clean boots in between attempts too, since clocking between diff levels is different than clocking from boot level
12:47karolherbst: sadly nvidia-smi isn't usable at all
12:47imirkin_: how so
12:47karolherbst: no output
12:47imirkin_: well, just start X
12:47imirkin_: and kill it
12:47karolherbst: what about turning the card off?
12:48imirkin_: noet that mmiotrace makes things super-slow, so you have to wait until it actually has done its stuff before killing X
12:48imirkin_: with acpi? i don't think so
12:48imirkin_: i don't really know what that does
12:48imirkin_: and i prefer to avoid unknowns
12:48karolherbst: set PCIe power state
12:48imirkin_: there are enough of them as-is
12:49karolherbst: D3cold I think
12:49imirkin_: right, but what dose that _actually_ do to the card?
12:49karolherbst: pstates are reset at least between nouveau loads
12:49imirkin_: can be anything
12:49karolherbst: I see
12:49imirkin_: could be coz nouveau decidse to run the vbios
12:50imirkin_: which inits things
12:50imirkin_: while nvidia driver might not
12:51karolherbst: after reloading nouveau module
12:51karolherbst: gpc clock is the same, but memory is not
12:55karolherbst: mupuf: do you have an idea in which "area" I could peak for values? maybe I just bruteforce read them while nvidia changes frequencies. Could that work?
13:01karolherbst: imirkin_: nvidia-smi doesn't need X running
13:01imirkin_: which is why i prefer just running nvidia-smi, since it'll normally trigger the full init.
13:01karolherbst: sadly it only shows me temp. PState level and memory usage
13:02imirkin_: what it outputs doesn't matter
13:02imirkin_: what matters is whether the NVRM inits the card and thus produces a usable mmiotrace
13:02karolherbst: I though I would trigger a frequency reclock with that tool
13:02karolherbst: and see what happens after it
13:03imirkin_: you use nvafakebios to remove all of the pstates you don't want and leave only one there
13:03imirkin_: that will force the NVRM to use just that one
13:03imirkin_: you remove a pstate by setting its id to 0xff
13:04karolherbst: then I look at the trace and with luck I see how nvidia sets the voltage
13:04imirkin_: so you figure out the byte offset of the various id's and then just pass them in to nvafakebios along with the 0xff value to overwrite them with
13:05imirkin_: nvafakebios doesn't do anything destructive btw... just sticks the faked bios into pramin (aka vram)
13:05karolherbst: so if I load nvidia after it and nvidia-smi shows P1 instead of P0 I've done "something" right
13:08imirkin_: no idea what that P0/P1 thing means
13:09imirkin_: again, the output of nvidia-smi is irrelevant
13:09imirkin_: what's relevant is what's in the mmiotrace
13:09imirkin_: nvidia-smi is just a quick simple tool that'll force the nvrm to init the card
13:09imirkin_: without something heavier like X
13:12karolherbst: P0 and P1 are the pstates which this tool reports
13:16mwk: and vp1 follows the sparc kind of craziness
13:17mwk: a branch in delay slot single-stepped the insn at first target, continued with second target
13:18imirkin_: and what if *that* one is a branch? :)
13:18imirkin_: does that branch get executed 1 later?
13:18mwk: then the second target is single-stepped too, and execution continues at that thing's target...
13:19imirkin_: makes sense.
13:19mwk: sparc did the nice thing and actually exposed PC and NPC as architectural registers
13:19mwk: so that craziness is sort-of official
13:22karolherbst: is there an easy way to verify that something was changed through nvafakebios?
13:22imirkin_: karolherbst: it should tell you exactly what it changed
13:23imirkin_: i.e. it should print out like "old value: x, new value: y"
13:23RSpliet: the only thing that might cause changes not to take effect is forgetting to unload the driver before changing
13:23imirkin_: so if you're nulling out e.g. the 07/0a pstates, the old values should be 07 and 0a
13:23karolherbst: ahh, now I see it
13:24imirkin_: you ideally want to just leave a single one in there to avoid any potential for oddity
13:26karolherbst: if I understand the bios right, its just a collection tables, which have something in it, and maybe some blob code. So I have to find the offset of the pstate table and then modify values inside it?
13:26imirkin_: ya. nvbios prints the offsets.
13:27karolherbst: is BOOST table the right one?
13:28imirkin_: er wait
13:28imirkin_: did i say no? i meant yes :)
13:28imirkin_: er hmmm
13:28imirkin_: hold on
13:31imirkin_: this looks different from the nv50 bios tables i'm used to
13:31imirkin_: the exact technique might be slightly different
13:31imirkin_: it doesn't look like anything's overwritten with 0xff for invalid pstates
13:31karolherbst: there is a pstate 0 though
13:32karolherbst: with clocks set to 0
13:32imirkin_: aka invalid :)
13:32karolherbst: domain 10 though
13:32imirkin_: which again is an invalid domain
13:32imirkin_: at least if the other domain ids are to be believed
13:33imirkin_: skeggsb_ did all the fuzzing for kepler, he'd know for sure
13:34karolherbst: okay, if nvbios says "BOOST table at 0x7ffc" at which offset to I have to peek then? 0x7ffc seems kind of wrong to me, because 0x8000 is nothing anymore
13:36RSpliet: I think you're looking for the performance mode table rather than the boost tbl
13:37karolherbst: ahh pm_mode
13:37karolherbst: this looks better
13:37imirkin_: oh right of course.
13:38imirkin_: and there those ID's are easily 0xff'd out, in fact one of them already is
13:38karolherbst: imirkin_: but you are right, the invalid pstate contains garbage
13:38imirkin_: but as soon as it sees the 0xff, it skips over that mode
13:38karolherbst: imirkin_: this one? "- ID 0xff Voltage entry 0 PCIe link width 255 5.0 GT/s --"
13:38karolherbst: ahh, yeah
13:39karolherbst: now I see it
13:39karolherbst: one ff and 00 otherwise
13:39imirkin_: so if you want to force 0xf, just set 0x7ef4 and 0x7f31 to 0xff
13:39imirkin_: which currently contain 07 and 0a, respectively
13:40karolherbst: how can I read those values out of the bios? :D
13:40imirkin_: nvbios :)
13:40karolherbst: I see
13:40imirkin_: nvafakebios will just take a rom file you give it and stick it into pramin
13:40imirkin_: it doesn't care what your current bios has
13:41imirkin_: it also has functionailty to make a few byte edits to that fiel before uploading it
13:41karolherbst: okay, I already set up something to verify
13:42karolherbst: if I nvafakebios the bios
13:42karolherbst: how should I read the bios out? the debugfs bios file seems to contain the old values
13:42imirkin_: you've already read in the bios
13:42imirkin_: you sent it to me, so i know.
13:43imirkin_: that is the file you should be passing to nvafakebios.
13:43karolherbst: I mean after I passed it
13:43imirkin_: why are you trying to read it out?
13:43karolherbst: how can I see the current state of the bios I modified
13:43imirkin_: just trust it.
13:43karolherbst: mhhh k
13:43imirkin_: oh, and if you have nouveau loaded, you're in for sad times
13:44imirkin_: nvafakebios has to go when no driver is loaded
13:44imirkin_: and make sure the card is on
13:44karolherbst: why? what happens else?
13:44imirkin_: it doesn't work :)
13:44imirkin_: the whole way it works is by writing the vbios into VRAM
13:44imirkin_: if the card is off, or gets turned off, then that's not so useful.
13:44RSpliet: wouldn't nvafakebios simply fail if you try to use it on a card that's powered off?
13:45karolherbst: I mean what happens if I nvafakebios while the module is loaded
13:45imirkin_: RSpliet: not if the card gets temporarily powered on for the write, and then turned back off :)
13:45imirkin_: oh... nothing bad... probably
13:45imirkin_: at worst you overwrite some texture
13:45imirkin_: but it also has no real effect
13:46karolherbst: okay, so after I set the pstate to 0xff, should if I load nouveau after it see it as 0xff and mark it as invalid?
13:46imirkin_: not sure why you'd bother with that
13:46imirkin_: but sure, you can do that
13:46karolherbst: I am really lucky I have a LED for the power state of my gpu
13:47karolherbst: imirkin_: I want to get used to the procedure first, because I have to reboot to enable mmiotrace, so I just want to toy a bit
13:47RSpliet: that's certainly more convenient than shoving your fingers against the chip to verify based on the temperature
13:48karolherbst: which is more unconvient if this is a laptop you are using
13:48imirkin_: or the taste test to determine voltage
13:48RSpliet: "if it tastes like chicken, you're lickin' it wrong"
13:49imirkin_: how else do you check if a 4.5 or 9V battery still has juice left :p
13:50karolherbst: a bit of copper wire?
13:51imirkin_: if you put your tongue against the two leads you get a super-acidic taste if there's still power left
13:51karolherbst: yeah I know
13:51karolherbst: but the wire method is more spectacular
13:52imirkin_: well sure, there's plenty of methods. you can also use a DMM
13:52karolherbst: nah, thats like boring
13:52imirkin_: but the taste test requires no additional equipment
13:53karolherbst: I think I do something wrong, because nouveau sees all pstates
13:53imirkin_: what did nvafakebios print
13:53imirkin_: pastebin your commandline *and* output
13:55RSpliet: he didn't stick his tongue in his PSU, did he?
13:56karolherbst: my system was never such unstable
14:28karolherbst: slowly I get the feeling, that whenever I hit a kernel bug or something I system goes totally in unresponsive state
14:28karolherbst: so like completly
14:30tobijk: karolherbst: depends on which subsystems get *killed* ;-)
14:31karolherbst: I bet drm
14:31karolherbst: becuase I was toying around with nouveau
14:31karolherbst: checking pstate
14:32karolherbst: sadly my pstate storage was full already
14:32karolherbst: but here: https://gist.github.com/karolherbst/8f7e207532a3b3e71307
14:32karolherbst: no clue
14:33tobijk: nvidia_frontend_init_module+0x81/0xb1 [nvidia]
14:33tobijk: you have the nvidia driver running?
14:34karolherbst: its unloaded
14:34hakzsam: imirkin, nv50 piglit runs in your mailbox :)
14:34karolherbst: but this is an older one
14:34karolherbst: my system just crashed after calling nvafakebios
14:34karolherbst: but this may somethig older
14:34karolherbst: emptied pstore and will try again
14:35karolherbst: pstore is pretty handy though :)
14:35tobijk: never worked with it tbh
14:36tobijk: but sounds handy, yeah
14:36karolherbst: is /sys/fs/pstore mounted for you?
14:37tobijk: oh it is
14:37karolherbst: there you go
14:38karolherbst: it stores dmesg on crash inside uEFI storage, so its really limited
14:38karolherbst: but I think there are several backends for pstore
14:39karolherbst: okay, trying again
14:39tobijk: good luck with that :D
14:39tobijk: i'm waiting for the timeout...
14:40RSpliet: skeggsb_: mind rolling a new libdrm on Koji?
14:42karolherbst: don't know, I bet its mmiotrace related
14:42karolherbst: and after I remove it, it will work again
14:42tobijk: mmiotrace is picky :D
14:42karolherbst: it isn't either enabled, just built into the kernel
14:43karolherbst: loading nvidia module is already fun
14:43karolherbst: ohh, seems to work now
14:43tobijk: i traced the nvdia driver a while back for my old card, took me like 10 attempts to get one successful run :/
14:50karolherbst: no, it doesn't :O
14:50karolherbst: it uses PROM
14:50karolherbst: PRAMIN isn't enabled
14:52imirkin_: right. so that's why
14:52imirkin_: as to why it ends up not seeing the stuff that you wrote with nvafakebios... dunno
14:52imirkin_: perhaps you're turning it off?
14:54karolherbst: mhh, "nouveau E[ VBIOS][0000:01:00.0] PRAMIN invalid"
14:55imirkin_: which is surprising.
14:55karolherbst: does PRAMIN require anything?
14:56karolherbst: so my card is weirder than expected actually
14:57hakzsam: imirkin_, do you need to double-check some other tests on nv84 ? because I'm going to sleep very soon :)
14:58imirkin_: hakzsam: just the ones i sent
14:58imirkin_: hakzsam: it was very odd to see them fail
14:58karolherbst: imirkin_: so is there a way for me to fake the bios now?
14:58mupuf: impressive backlog!
14:59mupuf: karolherbst: hey, still need help?
14:59imirkin_: karolherbst: dunno, i've never had any issues. but i've also never tried using a mobile gpu.
14:59karolherbst: mupuf: I can't use PRAMIN
14:59karolherbst: nouveau only uses PROM currently
14:59karolherbst: so nvafakebios kind of doesn't work
15:01karolherbst: mupuf: or do you other meanse to fake the bios?
15:02mupuf: that;s not a valid excuse
15:02mupuf: on fermi+, the vbios is always read from PROM
15:02mupuf: but nvidia still checks PRAMIN
15:02karolherbst: I see
15:02karolherbst: I just wanted to verify with nouveau a bit
15:02karolherbst: but if that's okay this way
15:04hakzsam: imirkin_, so now we have a lot of work to fix all of those tests :)
15:04tobijk: is g84 in any way special? :O
15:05hakzsam: no, but some tests failed during the piglit run for no reasons
15:05tobijk: and others in the nv8x series do pass those tests?
15:06hakzsam: I only checked on nv84
15:06hakzsam: I don't have all tesla chipsets :)
15:07tobijk: well but maybe others have...
15:07imirkin_: hakzsam: there's something funny about sampler setup on the G80
15:07hakzsam: tobijk, yeah, mupuf :d
15:07imirkin_: maybe i'll ask mupuf to throw one into reator
15:07tobijk: in fact i can check g86
15:07imirkin_: it's _really_ hard to care since i suspect that running these tests is the only use that G80's get with nouveau
15:09karolherbst: and again
15:10karolherbst: executing nvafakebios sometimes completly hangs my laptop :/
15:11mupuf: really? that is interesting!
15:11mupuf: never had the problem before!
15:11mupuf: any kernel logs?
15:11karolherbst: I try to get some
15:12karolherbst: but I fear that my disc doesn't sync after it
15:12mupuf: we must be writing to an address we should not write to!
15:12hakzsam: imirkin_, what test?
15:12imirkin_: hakzsam: all the tex-miplevel-selection tests
15:13karolherbst: huh nice, journald corruptions, this is just nice
15:13hakzsam: imirkin_, ah yes
15:15hakzsam: imirkin_, probably a regression since they didn't fail in the nv50 run on your page
15:15karolherbst: so, whiped out entire journald stuff
15:15imirkin_: hakzsam: no, they didn't exist back then :)
15:16hakzsam: imirkin_, mmh
15:16imirkin_: it seems like it doesn't respect the maxlevel
15:16karolherbst: and again
15:18hakzsam: imirkin_, well, I'm tired, going to sleep. I'll have a look tomorrow, have fun! :)
15:19karolherbst: kernel is also totally gone
15:19karolherbst: even my fn keys for keyboard lit which are handled 100% inside the kernel don't do anything
15:21karolherbst: and nothing in the logs
15:22karolherbst: any ideas?
15:23imirkin_: karolherbst: power off
15:23imirkin_: leave off for a few minutes, disconnect battery
15:25karolherbst: I think I will let it power off over the night, its getting late and I don't think I will do much RE today anymore
15:25karolherbst: could try a mmiotrace though
15:25imirkin_: disconnect battery is the big one
15:25imirkin_: otherwise poweroff can be less effective
15:30karolherbst: imirkin_: should I pass anything to nvidia-smi or just call it once and its fine
15:31imirkin_: just clal it once, that should be enough for nvrm to wake up and do its thing
15:36karolherbst: now its getting ridiculus
15:37karolherbst: I bet its mmiotrace faults so zou shouldn|t worry
15:37karolherbst: nice, now my layout is set wrong
16:07Karlton: imirkin_: I installed llvm and now the texture is LATC aswell, but the retrace looks fine
16:08Karlton: i.e. in software rendering there is no green stuff or anything obvious wrong, but now the texture is LATC and looks like it did in nouveau
16:17Karlton: the left was done with llvmpipe
16:56imirkin_: hakzsam: fyi, posted your results at http://people.freedesktop.org/~imirkin/nv50-comparison/problems.html
19:00Karlton: oh, is "137487: message: major shader compiler issue 1: 0:9(12): warning: extension `GL_ATI_shader_texture_lod' unsupported in fragment shader
19:00Karlton: err, is that concerning?
20:29imirkin: Karlton: i have a patch for that
20:29imirkin: Karlton: what game is this?
20:30Karlton: imirkin: I did a retrace of flightgear and now I am getting that everytime
20:30imirkin: Karlton: https://bugs.freedesktop.org/show_bug.cgi?id=91169
20:30imirkin: there's a patch in the first comment that works around some issues in riddick
20:53Karlton: is that already in master mesa?
20:55Karlton: argh!, nvm I doubled pasted the patch -.-
21:10Karlton: imirkin: that silenced it :)