00:27 pmoreau: imirkin: :-( Did it got killed performance- or rendering-wise?
00:27 hakzsam: rendering I assume
00:27 hakzsam: imirkin, those are not fixes then ;)
01:23 RSpliet: imirkin: http://cgit.freedesktop.org/mesa/mesa/commit/?id=a3722b81f534598f25d9d155a6d30bc59a6f4e59 <- the fallthrough looks a bit odd, as for s32 it will do both the .s32 and the .u32 multiplication
01:24 RSpliet: (if i->subop is NV50_IR_SUBOP_MUL_HIGH)
01:25 RSpliet: hmm no, scrap that
01:25 RSpliet: it just looks funny :-P
04:50 funfunctor: imirkin: can you test this for me please? https://github.com/victoredwardocallaghan/mesa-GLwork/commit/8c9497ca9e35827f52040120f49f13a2755b4874
05:07 Dezponia: Hi people. I just picked up an Nvdia GTX TITAN Black card and noticed its not on the http://nouveau.freedesktop.org/wiki/CodeNames/#nve0familykepler page (I'm guessing its working anyway but checked :). If there are still some issues with it needing to be ironed out I'd be happy to help out once I get the card
05:12 glennk: GK110B, think the page lists that already?
05:13 Dezponia: glennk: Yepp, thats why I was pretty sure it worked already but it wasent listed to just asked for good messure :)
05:14 Dezponia: glennk: Reclocking should work on it as well then I guess since its shaping up for the 780Ti?
05:31 pmoreau: Dezponia: I doubt there has been much (if any) testing done on a Titan Black
05:32 Dezponia: pmoreau: Well consider me voluntering :)
05:32 pmoreau: Dezponia: :-) You're welcome to do so!
05:36 Dezponia: pmoreau: Now lets just hope everything works out with shipping and it gets here in one peice...
05:38 pmoreau: Should be fine I hope
05:41 Dezponia: I hope as well :P
06:24 imirkin: pmoreau: RSpliet: fyi i fixed the nv50 thing with http://cgit.freedesktop.org/mesa/mesa/commit/?id=204f803ce0e47720d072603fec8a2acde6993fed
06:27 pmoreau: That's nice!
07:18 RSpliet: imirkin: ah, good catch... is that because nv50 doesn't do conditional mov imm at all>
07:19 RSpliet: (or should the emit logic be extended rather?)
07:19 imirkin: RSpliet: i didn't check, but my assumption is that imm + conditional = no go
07:20 imirkin: and normally the target helpers would have worked that out, but i special-cased 0 and allowed it everywhere
07:21 RSpliet: ahh I see... and this was an easier fix than checking whether the op has a condition (and replaceZero() only then)?
07:22 imirkin: well, no real reason not to always replaceZero
07:22 imirkin: except in places where the emitter *needs* the immediate
07:22 imirkin: like pfetch
07:22 RSpliet: I was about to say... makes sense
07:23 imirkin: actually that flagsDef check seems bogus too...
07:23 imirkin: er, address
07:23 imirkin: that could cause problems...
07:24 RSpliet: ugh, I don't know all the details of NV50 IR... is there a 4-byte form for mov <target>, $r63, or is the short form restricted to only the first 32 regs?
07:24 imirkin: grrr, except that the way we do "mov $a1 $r0" is with "shl $a1, $r0, 0x0"
07:24 imirkin: RSpliet: short form is restricted to first 64 regs
07:24 imirkin: this is why we prefer $r63 over $r127
07:24 RSpliet: I see :-)
07:25 imirkin: but if we alloc more than 63 regs, we use $r127 for the replacement
07:25 RSpliet: are there situations btw where you can do with only 32 regs per thread?
07:25 imirkin: the fewer regs the more threads
07:25 RSpliet: (and can hardware use that to increase the number of active warps further?)
07:25 imirkin: but that's based on the number of GPRs you say you use
07:25 imirkin: not based on the ones you actually use
07:26 imirkin: everything above the number of GPRs you ask for is zero'd out
07:26 imirkin: dunno what happens if you try to write to them
07:26 RSpliet: what do you mean with "zero'd out"?
07:26 imirkin: $r63 is zero
07:26 imirkin: $r62 is also zero
07:26 imirkin: $r1 is also zero
07:27 imirkin: depending on how many regs you claim you use when setting up the program
07:28 RSpliet: ah okay, so it zeroes out the values when a regnum exceeds the gpr , so no need to try and force $31 to be 0 or something :-)
07:29 imirkin: right
07:29 imirkin: on fermi+, the high reg is actually special
07:29 imirkin: nvdisasm prints it as RZ
07:29 imirkin: pretty sure you can't write a value to it even if you tried
07:30 imirkin: i mean, you can, but it stays 0
07:30 imirkin: on tesla, it's just a reg like any other
07:34 funfunctor: imirkin: thx for the review on that patch
07:35 funfunctor: I'm trying to work out how to implement it without using the pipe clear functions
07:52 karolherbst: mupuf: maybe it would help to adjust the volt/clock in the right order? the blob seems to adjust the volt after reclocking when it is downclocking, I don't think nouveau changes the order depending in which direction the clock is changing?
07:52 mupuf: of course we do :D
07:52 karolherbst: really?
07:52 mupuf: yes
07:53 karolherbst: I really don't think so thoguh
07:53 mupuf: check it :p
07:53 mupuf: you'll see
07:54 karolherbst: mhhhhhh okay, I saw it now :D
07:55 karolherbst: anyway, I am cleaning up the data a bit I fetched yesterday, but it looks nice already: http://plotshare.com/sessions/510349027/Plot1.png
07:56 karolherbst: there are just some entries where the fetched the data between volting and reclcking
07:56 mupuf: ah, much more readable ... but still :D
07:56 mupuf: 2d plot please :D
07:56 karolherbst: reload :p
07:57 mupuf: ah ah, better but still not what I meant :D
07:57 karolherbst: I know
07:57 mupuf: volt / freq and then multiple lines for temperature :p
07:58 karolherbst: ohh okay
07:58 mupuf: and if you want to improve the current one, you should swap VID and °C
07:59 karolherbst: reload :p
07:59 mupuf: muuuuuuuuccccchhhhh better
07:59 karolherbst: yeah
07:59 karolherbst: and I also find the bad data this way :D
07:59 karolherbst: but I think it is okay
08:00 mupuf: and if we get lines per temperature, it will be really easy to see what is going on
08:00 karolherbst: VID cap is 26
08:00 karolherbst: this is a nice thing
08:00 karolherbst: because that actually means the lowest clock raises as the temperature goes up
08:00 karolherbst: :D
08:01 karolherbst: I changed the colors
08:01 karolherbst: much better
08:02 karolherbst: mupuf: you mean diagnonal lines?
08:03 karolherbst: mupuf: if I find multiple data with clock-temp but different VIDs, what should I do about them?
08:03 karolherbst: some VIDs are obviously wrong, but some I don't know which one is the right one
08:14 mupuf: if I find multiple data with clock-temp but different VIDs, what should I do about them? --> you need to check if it was in a clock_raising or clock_falling scenario
08:17 karolherbst: yeah, currently I just remove these where the VID was used for the previous freq and if the difference is too high
08:17 karolherbst: like if a clock usually has 20-22 as the VID
08:17 karolherbst: 3 is obviously wrong
08:21 mupuf: http://fs.mupuf.org/mupuf/nvidia/graphs/temperature_power_voltage.svg <-- I would like to see something like this, different lines for different temperatures
08:21 mupuf: that will require you to actually split the results into multiple files
08:21 mupuf: but it will be readable
08:22 mupuf: we need lines
08:22 mupuf: not just dots
08:26 karolherbst: how should I split them? one file per temperature?
08:34 mupuf: yes
08:34 mupuf: karolherbst: yes
08:41 karolherbst: mupuf: and then I have to plot all those files with the plot command I guess
08:41 mupuf: yes
08:41 mupuf: and this way, you will have lines :)
08:41 karolherbst: k
08:41 karolherbst: installing gnuplot :D
08:41 mupuf: which will tell a very interesting story
08:41 karolherbst: and much wrong data
08:41 mupuf: what have you been using so far?
08:42 karolherbst: :D
08:42 karolherbst: website
08:42 mupuf: ack
08:42 karolherbst: no need to upload then :p
08:42 mupuf: http://fs.mupuf.org/mupuf/nvidia/graphs/temperature_power_voltage.plot
08:43 karolherbst: yeah, already found that
08:43 mupuf: :)
08:43 karolherbst: why didn't you calculate the cubic function insode gnuplot :p
08:43 mupuf: ?
08:44 mupuf: the cubic function is a model
08:44 mupuf: are you telling me I should have used gnuplot to do find a model for me?
08:44 mupuf: I do not think gnuplot can do that
08:44 mupuf: I used R, as recommended by imirkin
08:53 karolherbst: ohh gnuplot can do that
08:53 karolherbst: mhhh
08:53 karolherbst: though I am not sure if you can do that over the entire data set :/
08:57 karolherbst: mupuf: what should I do about those downclocks?
09:02 mupuf: karolherbst: gnuplot can make regressions? Are you sure?
09:02 mupuf: I doubt it
09:03 mupuf: karolherbst: how is it going?
09:05 karolherbst: well
09:05 karolherbst: as I said, the downclocks destroy everything :D
09:06 karolherbst: will remove them for now
09:08 mupuf: yeah, I guess they could be split into different files
09:08 mupuf: that would help
09:09 karolherbst: mupuf: https://i.imgur.com/TL2ddIG.png
09:11 karolherbst: I don't think I can get usefull downclock graphs with that
09:11 karolherbst: because I have like 2-4 unique entries per temperature
09:11 karolherbst: only :/
09:11 mupuf: funky!
09:12 karolherbst: how can I remote the line title? :D
09:12 mupuf: line title?
09:12 mupuf: what do you mean?
09:13 mupuf: remove?
09:13 karolherbst: the 1°C thingies
09:13 karolherbst: if I remove the title ".." thing, there are some default values
09:13 mupuf: just use "with title ''"
09:13 mupuf: with title ''
09:14 mupuf: but why do you want to get rid of them? :o
09:14 mupuf: next week, I will get a gtx 960, a colleague of mine will lend it to me :)
09:14 mupuf: gonna be nice for testing!
09:15 mupuf: and that will be one more sample point!
09:15 Tom^: but isnt that maxwell?
09:15 mupuf: it is
09:15 mupuf: maxwell v2
09:15 mupuf: which means no rendering support
09:15 mupuf: but heck if I care in this case :p
09:15 Tom^: heh
09:16 karolherbst: mupuf: 1-100: https://i.imgur.com/rpWCtHh.png
09:17 mupuf: why is the starting clock different depending on the temperature?
09:17 karolherbst: mupuf: temperature is already displayed by the color, and with 100 lines, these titles will go over the graph
09:17 karolherbst: mupuf: min voltage
09:17 karolherbst: VID 26 seems to be the lowest voltage the blob does
09:17 karolherbst: and if the blob reduces the voltage for each clock due to temperature
09:18 karolherbst: the lower clocks can't be used anymore
09:18 karolherbst: at least that is what I thing it does
09:18 mupuf: funky++
09:19 mupuf: I guess we would gain in clarity by just seeing every 10°C
09:19 karolherbst: no prop
09:19 mupuf: but this looks quite good!
09:20 karolherbst: I am so happy that gnuplot does for loops :D
09:20 mupuf: :p
09:20 karolherbst: https://i.imgur.com/7J6t9YS.png
09:21 karolherbst: I think I have to check each file for some corrupt entries
09:21 karolherbst: I think I missed to remove some downclocks
09:22 karolherbst: yep, found some
09:23 mupuf: if you don't mind, we'll change the testing rig to work on maxwell :D
09:23 mupuf: it will be easier with the pwm output
09:24 karolherbst: meh :D
09:24 karolherbst: again
09:24 karolherbst: but I can do that on my gpu too then
09:26 mupuf: yop
09:26 mupuf: we will need to model the behaviour and check if changing some settings affect the voltage
09:27 mupuf: I would say that what we need is to force the clock to the base and alter the voltage mapping entry associated with it
09:27 karolherbst: I am wondering if there is something odd
09:27 karolherbst: because I clearly see lines above ones with higher temperature
09:27 karolherbst: much higher
09:27 mupuf: lovely :D
09:27 karolherbst: like this one: https://i.imgur.com/axijbkV.png
09:28 karolherbst: 900-1000 MHz
09:28 karolherbst: there you see it
09:28 karolherbst: ohhhh wait
09:28 karolherbst: higher VID means lower voltage :D
09:28 mupuf: how about the following, take one frequency as a base and look at voltage vs temperature
09:28 karolherbst: so each clock one file?
09:29 mupuf: just one file is enough
09:29 karolherbst: ohhh okay
09:29 karolherbst: then I choose the highest one :p
09:30 karolherbst: 1097looks better actually
09:31 karolherbst: that's useless :/
09:31 karolherbst: look at the data: https://gist.github.com/karolherbst/a2c320e611041b69f0bc
09:31 karolherbst: always 9->5 VID
09:31 karolherbst: 9 seems to be from the previous clock though
09:32 karolherbst: maybe not :/
09:32 mupuf: ah ah, looks even more funky
09:33 karolherbst: please reload ;)
09:33 karolherbst: I added a line before and after the 1097 clock
09:33 karolherbst: I think the main problem is, is that we hit a case where we fetch data while nvidia is reclocking
09:33 karolherbst: and so we don't get optimal data
09:35 karolherbst: but compare https://i.imgur.com/axijbkV.png with https://i.imgur.com/Adf1mur.png
09:35 karolherbst: this is actually quite nice
09:35 karolherbst: the difference between those
09:36 karolherbst: yeah, this makes sense
09:36 karolherbst: because the voltage ranges get smaller at higher clocks
09:36 karolherbst: that's why we don't see that much of a difference at the highest clocks
09:37 mupuf: agreed
09:38 karolherbst: mhhh
09:38 karolherbst: but mhhh
09:38 karolherbst: no, the smaller voltage ranges aren't reached at all
09:38 karolherbst: because their max voltage is already too high :/
09:38 karolherbst: strange
09:38 karolherbst: I should look more closely
09:39 karolherbst: that*s the highest entry: -- ID = 45, link: 2, voltage_min = 1037500, voltage_max = 1200000 [µV] --
09:39 karolherbst: VID 3 is 1175000uv
09:40 karolherbst: VID 9 is 1100000uv
09:41 karolherbst: mupuf: I will translate the VID into real voltage
09:41 karolherbst: sould be easier to read then
09:41 mupuf: :)
09:42 karolherbst: just have to figure out how I do that :D
09:43 mupuf: hey, instead of adding a way to read the voltage from a different file, shouldn't pstate return the selected voltage?
09:43 mupuf: well, we would need to improve the testing rig to actually fetch the vbios and parse it :D
09:44 karolherbst: ? what do you mean by different file. It makes totally sense to read it through hwmon
09:44 karolherbst: we can do both though
09:44 mupuf: we can definitely link to nvbios' c files and read the data structures
09:44 mupuf: hwmon should expose it, yes
09:45 mupuf: but pstate could also expose it ... even though it will likely change with temperature :s
09:45 karolherbst: mhhh
09:45 karolherbst: nouveau first need to support the min-max voltages
09:45 karolherbst: currently it just uses the min voltage
09:48 imirkin_: aboll: i have no idea how to operate the debian bugtracker... could you ask the user for some help reproducing? i.e. what do i need to do? back when i fixed the original bug, it would insta-crash when loading any course. dunno if that's what he's seeing as well or not.
09:48 karolherbst: yay, much better now
09:48 karolherbst: mupuf: https://i.imgur.com/80Ta0tA.png
09:49 mupuf: that is quite a voltage difference in the end!
09:49 karolherbst: yeah
09:49 karolherbst: but you shouldn't forget our inaccuracy
09:50 karolherbst: mabe I do coloured points with alpha values
09:50 mupuf: hehe
09:50 karolherbst: and the seldomly hit values are then away or something
09:50 karolherbst: ohhhhh
09:50 karolherbst: gnuplot does that automatically?
09:51 karolherbst: mhhh
09:51 karolherbst: no I think it is just different symbol for each file
10:05 karolherbst: yeah lol
10:05 karolherbst: I was wondering why the alpha thing doesn't work
10:05 karolherbst: but I used white as the color
10:22 mupuf: hehe
10:23 mupuf: enough work for the day! Let's go back home!
10:24 karolherbst: ohhh
10:24 karolherbst: wait a second :D
10:25 karolherbst: mupuf: https://i.imgur.com/PXeyK8v.png
10:25 karolherbst: isn't that nice
10:27 karolherbst: though at the higher clocks it is quite useless
10:27 karolherbst: but up to 980MHz
11:29 imirkin_: mwk: any clue what "addpo" is?
11:30 imirkin_: in the context is imad/iscadd
12:07 karolherbst: mupuf: my produces much nicer graphs :D
12:07 karolherbst: but no my computer crashed at 56°C
12:09 karolherbst: https://i.imgur.com/kVcKTpR.png
12:12 mupuf: karolherbst: I love that@!
12:13 karolherbst: yeah
12:13 karolherbst: will do the 57-97 thing now
12:13 karolherbst: actually 96 is max
12:13 karolherbst: nvidia throttles to min with 97
12:13 mupuf: it is strange that the voltage scales linearly with the voltage though
12:13 karolherbst: mupuf: another good thing with my gpu: blob stays at max clock with 96 and min clock too
12:14 mupuf: err, with the clock
12:14 karolherbst: so there is no change with that too
12:14 mupuf: yeepee
12:14 karolherbst: mupuf: well the blob also uses the highest cstate here
12:14 karolherbst: :D
12:14 karolherbst: which isn't normal
12:14 Yoshimo: 56° , that is way too low to crash, isn't it?
12:14 karolherbst: mupuf: 160MHz above "base clock"
12:15 karolherbst: mupuf: should I mark my base clock and boost clock? maybe that tells us something
12:30 karolherbst: mupuf: https://gist.github.com/karolherbst/5d5aaad09bd2d6b83a91
12:36 karolherbst: mupuf: wow, lines are also looking nicely!
12:36 karolherbst: even with the downclocks
12:37 karolherbst: mupuf: https://i.imgur.com/kZg7Yad.png
12:51 mupuf: karolherbst: ah! Much more readable!
12:52 mupuf: so, there are 4 temperatures
12:52 karolherbst: mupuf: what I like is, that the function seems to be linear somehow
12:52 mupuf: yes
12:52 karolherbst: 4?
12:52 karolherbst: why 4?
12:52 karolherbst: ohhh
12:52 karolherbst: now I get it
12:52 karolherbst: but this is just up to 60°C
12:52 karolherbst: still collecting data
12:53 mupuf: ack! But it looks super good!
12:53 mupuf: so, at the highest clock, they all converge towards the same points
12:54 mupuf: which is a very good thing :)
12:54 karolherbst: more data up to 81°C: https://i.imgur.com/ThiKaaj.png
12:54 mupuf: i don't like this view, I can't read it :s
12:54 karolherbst: :D
12:55 karolherbst: just amount of hits with some temperature displayed in the dots
12:55 karolherbst: red dots: high temp
12:55 karolherbst: blue dots: low temp
12:55 karolherbst: but yes, this doesn't help finding the function
12:55 mupuf: anyway, it likely means that there are conditions like: if temp in [X,Y], add Z uV
12:55 imirkin_: pmoreau: i accidentally did https://trello.com/c/DX357llE/71-fold-immediates-into-const-load-offsets
12:55 mupuf: or actually, substract
12:56 imirkin_: pmoreau: or rather... only a part of it
12:56 imirkin_: but i'm about to do the other part :)
12:56 imirkin_: pmoreau: http://hastebin.com/oxagoqerox.coffee so far -- not bad. need to figure out why so many programs get hurt in gpr usage
12:56 mupuf: imirkin_: are you using shaderdb to keep track of these things?
12:57 imirkin_: mupuf: yes
12:57 mupuf: very nice :)
12:57 karolherbst: mupuf: so you want to have the final line graph at the end?
12:57 mupuf: yes, when you are done with this :)
12:57 mupuf: anyway, my turn to start doing something
12:57 karolherbst: :p
12:58 karolherbst: mupuf: I think I will remove the downclocks in the end
12:58 karolherbst: those lines are a bit annoying though
12:59 mupuf: yes, they are annoying, but I would say you need to have all of them and then have them grouped by which point they end up at in the end
12:59 mupuf: what do you think?
13:00 karolherbst: mupuf: the voltage while downclocking seems to be basically the samw
13:00 mupuf: very good
13:01 karolherbst: maybe there is a little difference, but nothing critical
13:01 karolherbst: the blob downclocks with too big steps anyway
13:01 karolherbst: and just falls under the lowest voltage for my card with the second jump
13:02 karolherbst: mupuf: ahhh I remember something
13:02 karolherbst: mupuf: my lowest voltage is pstate related!
13:02 karolherbst: 38 PWM for 07
13:02 karolherbst: 40 for 0a/0f
13:02 karolherbst: could be related to the pstate voltage entries
13:03 karolherbst: pstate 07: -- ID = 10, link: b, voltage_min = 793750, voltage_max = 881250 [µV] --
13:03 karolherbst: 0a/0f: -- ID = 4, link: 5, voltage_min = 800000, voltage_max = 893750 [µV] --
13:04 pmoreau: imirkin_: You're stealing my job! :p
13:04 imirkin_: actually the joke is that i did the more complex thing
13:04 imirkin_: and totally forgot about the simpler one
13:04 pmoreau: Ah ah ah! :-D
13:04 imirkin_: i.e. i handle inlining foo+immediate
13:05 imirkin_: but not just plain foo :)
13:05 pmoreau: Well, it's not like I have a lot of time to work on it, so you can do it all if you want.
13:06 karolherbst: imirkin_: idea: maybe trackint memory intensive instructions like load/store would be a good idea?
13:07 imirkin_: karolherbst: meh
13:07 imirkin_: i don't understand enough about how this stuff works
13:07 karolherbst: k
13:08 karolherbst: but is this with the nvc0 IR or TGSI?
13:08 karolherbst: ohh nvc0 of course :D
13:09 imirkin_: nv50 ir
13:09 karolherbst: k
13:36 karolherbst: mupuf: :O how nice that looks now
13:36 mupuf: show me :D
13:36 karolherbst: this is just :O
13:36 karolherbst: I removed the downclocks, and now I got this: https://i.imgur.com/n2siO8i.png
13:39 mupuf: well well wll
13:39 karolherbst: and there are clearly nearly parallel lines you clearly see
13:39 mupuf: yeah, it is surprising that it not always is
13:39 mupuf: you know what? I think you data acquisition is flawed :p
13:39 karolherbst: :D
13:39 karolherbst: why?
13:40 mupuf: because it otherwise looks way too weir
13:40 mupuf: d
13:40 karolherbst: I bet the daemon has a bad timing sometimes
13:41 mupuf: yep, something like that OR there is something else at play here
13:41 karolherbst: mhhh
13:41 mupuf: like hysteresis cycles between the modes
13:41 mupuf: would be nice to try cleaning it up :)
13:41 karolherbst: :D
13:42 mupuf: can you add x where data points are?
13:42 karolherbst: how do I do that with gnuplot?
13:43 karolherbst: repaired one data row :/
13:43 karolherbst: I hope this will make a big difference in the end after I found most of the errors
13:45 karolherbst: mupuf: look at that: 862, 1810, 1724, 2004, 1931, 1080, 540, 66, 61 //// 862, 1810, 1724, 2004, 1579, 1080, 540, 66, 61
13:45 karolherbst: here I hit a downclock :D
13:46 karolherbst: one engine already clocked down :/
13:46 karolherbst: how lucky
13:47 mupuf: lol
13:48 karolherbst: mupuf: https://i.imgur.com/xHGZVdX.png
13:48 karolherbst: and I only changed 2 rows
13:48 karolherbst: the difference is big :O
13:48 karolherbst: well "big"
13:49 karolherbst: but it seems like those errors were always between reclocks
13:49 mupuf: it's getting there :D
13:49 mupuf: ah right, if we get intermediate points, that is going to screw up the results
13:50 karolherbst: but finding them is easy, when I look for the pwm value
13:56 karolherbst: mupuf: https://i.imgur.com/RDwrty8.png
13:57 karolherbst: I think now it should be cleanr enough?
13:58 karolherbst: ohh right with voltage, now pwm value: https://i.imgur.com/tpldPYm.png
13:58 karolherbst: mupuf: any other line left which annoys you? :D
13:59 karolherbst: I think nearly all of them are caused because the daemon skiped a clock, but the voltage for the clocks were different
14:04 karolherbst: mupuf: actually this also looks kind of nice: https://i.imgur.com/Ja9THBp.png
14:05 mupuf: karolherbst: so nice :D
14:05 mupuf: sooooo!!! time for a model?
14:05 karolherbst: the colors are just wrong in the 3d one
14:05 karolherbst: :D
14:05 karolherbst: yeah, why not
14:06 mupuf: wait, no
14:06 mupuf: actually, yes, let's model that
14:06 karolherbst: I can give you the data if you want
14:06 karolherbst: just 97K
14:07 mupuf: ah ah
14:07 mupuf: why not
14:07 mupuf: yeah, please do
14:07 karolherbst: mupuf: there you go: https://gist.github.com/karolherbst/9e27680de71c5c133974
14:07 karolherbst: you can split them with: for i in {1..96}; do cat parsed.csv | grep "^.* $i, " > parsed_$i.csv ; done
14:16 mupuf: karolherbst: thanks
14:16 mupuf: here we go
14:33 mupuf: sorry, I'm back
14:33 mupuf: so, it seems pretty trivial
14:34 mupuf: [0, 10] --> -0, [11, 30] --> -1, [31, 51] --> -2, [51, [ --> -3
14:35 karolherbst: you think so?
14:35 mupuf: or maybe it is: [0, 10] --> min + 3, [11, 30] --> min + 2, [31, 51] --> min + 1, [51, [ --> min
14:35 karolherbst: but there are 5 values per clock
14:36 karolherbst: just not for the highest one
14:36 mupuf: 5 values per clock?
14:36 karolherbst: yeah, wait a sec
14:39 mupuf: the oddities we see are rounding errors
14:39 mupuf: always an off by one
14:39 karolherbst: https://i.imgur.com/mF5eUcy.png
14:40 karolherbst: there are alos some clocks with only 3 values :/
14:40 mupuf: which I doubt is due to this computation, more due to the one we need to come up with
14:40 karolherbst: but that could be because of lack of data
14:41 mupuf: yeah, other rounding errors I would say
14:41 karolherbst: mhhh
14:41 mupuf: so, how about we try to see if any bits of the table affect this?
14:42 mupuf: I will plug the gm107 and see
14:42 karolherbst: meh, then I would have to fix nvafakebios here :D
14:42 karolherbst: but the lower bound should be effected by the pstate voltage ranges
14:42 mupuf: in nouveau, for manual reclocking, we will always need to assume the worst case: 0°C
14:46 karolherbst: mupuf: but do you think it is actually needed to have a higher voltage with lower temperature?
14:48 mupuf: why would the blob do that if not because it is necessary?
14:48 mupuf: I think it should be seen as lowering the voltage when the temperature increases because of .... electron mobility increases with temperature?
14:49 mupuf: :D
14:49 karolherbst: mhhh would make sense somehow
14:50 karolherbst: but I think it is more important to get to the actualy voltage with our voltage map table :/ this can be pain or not
14:50 karolherbst: maybe this way we find what the "base" value is
14:56 karolherbst: mupuf: I think I will add the low/max voltage from the vbios tomorror to the graph
14:56 karolherbst: maybe I do it for a few values
14:56 imirkin_: skeggsb: would it be reasonable for the kernel to block instead of returning nv50cal_space?
14:57 imirkin_: skeggsb: and return an error if a hang is detected
14:57 imirkin_: skeggsb: or alternatively we need some sort of EAGAIN/select() mechanism
14:57 imirkin_: skeggsb: which seems like... overkill
15:08 mupuf: karolherbst: going to try to figure out this base value right now
15:10 koz_: How do I respond to this shit? https://github.com/supertuxkart/stk-code/issues/2386#issuecomment-162089203
15:11 imirkin_: koz_: just say "ok", don't play the game, and i'll be sure to avoid looking into bugs their app hits
15:12 imirkin_: which suits me just fine coz someone recently reported one i haven't been able to reproduce :)
15:12 koz_: Lol.
15:12 mupuf: ah ah
15:12 koz_: imirkin_: A good approach, I like it.
15:12 koz_: Considering that I'm pretty sure this is a shitty devs bug.
15:12 mupuf: yeah, shifting the blame straight away, not a good sign
15:13 koz_: mupuf: Not the first time I've seen this either.
15:13 koz_: Hell, not the first time *this week* I've seen it either!
15:13 imirkin_: i certainly wouldn't exclude this being a bug in nouveau, of course
15:14 koz_: imirkin_: Anything's possible, but their attitude isn't helpful.
15:14 imirkin_: i can write something silly in there if you want
15:15 koz_: imirkin_: Honestly? If you want.
15:15 karlmag:breaks out the popcorn...
15:15 koz_: I'm pretty much sure that these are the kind of morally-bankrupt devs I'm trying to avoid anyhow.
15:16 koz_: (if anyone cares, the issue I saw this in previously was Warsow 2.0: https://www.warsow.gg/forum/thread/t/230771)
15:16 imirkin_: koz_: warsow uses multithreading with destroys nouveau... joi found a setting to disable it
15:17 koz_: imirkin_: Why does it destroy nouveau out of interest?
15:17 imirkin_: because supporting concurrent GL contexts from diff threads isn't something i've had time to support
15:17 koz_: Ah.
15:17 imirkin_: no applications have been using it, so it hasn't been an issue
15:17 imirkin_: they're one of the first ones
15:17 koz_: Fair enough - priorities.
15:18 karlmag:thinks he should put together a game rig..
15:19 karlmag: as if I have that much time to play, but...
15:19 koz_: karlmag: My EVGA 680 runs wonderfully with the new clocking patches.
15:19 koz_: s/clocking/reclocking
15:19 mupuf: imirkin_: I think I already asked you this question, but wasn't libdrm_nouveau2 supposed to fix this?
15:19 karlmag: koz_: nice
15:20 imirkin_: mupuf: what is "this"?
15:21 mupuf: pushing commands out from multiple threads
15:21 imirkin_: mupuf: it's a mesa issue
15:22 mupuf: ack
15:23 imirkin_: koz_: that warsow thread seems pretty reasonable
15:57 koz_: imirkin_: Well, I still saw 'blame the driver' behaviour.
15:58 imirkin_: seems pretty reasonable given the trace
15:58 koz_: imirkin_: Yeah, I'll put that one down to a complete lack of knowledge on my part then.
15:59 imirkin_: koz_: also i dunno who that guy is... if he's some random dude then whatever
15:59 imirkin_: koz_: if he's a key contributor, then it's a little more unfortunate
16:00 koz_: imirkin_: I'm not sure either - I could investigate this if you're interested.
16:01 imirkin_: not sufficiently
16:01 koz_: Also, love that response! :)
16:01 imirkin_: esp since he (a) provided the proper workaround and (b) it's totally nouveau's fault
16:02 koz_: (in reference to stk, not warsow)
16:02 imirkin_: seemed to fit
16:02 koz_: Agreed. I'd have written something similar, with perhaps additional expletives.
16:05 imirkin_: i try to be polite... bbl
16:08 koz_: Also, who is the best person to speak to here about Fermi issues?
16:18 imirkin: depends on the issues
16:37 mwk: imirkin: addpo is "add plus one"
16:37 mwk: addpo(a, b) == a + b + 1
16:52 koz_: imirkin: Lockups on a 550Ti.
18:08 mupuf: too many inter-dependent variables for my brain to comprehend at 4am
18:08 mupuf: will try again tomorrow!
18:19 imirkin: mwk: oh neat.
18:56 imirkin: koz_: well that sure seems unfortunate for a 3d game project... "at this time none of our core developers are OpenGL experts"
18:56 imirkin: koz_: lockups... do you have dmesg of such a lockup?
19:16 ystreet00: imirkin: its not true that multi-threaded GL is uncommon. It's just that everybody disables it (where possible) with mesa because it sucks.
19:18 imirkin: ystreet00: is that really true? the issue is purely in nouveau, not mesa (although mesa does have a couple of issues too)
19:18 imirkin: ystreet00: warsow is the first game i've encountered that did it
19:19 ystreet00: yea, games can usually get away with singlethreading stuff
19:19 ystreet00: I know Qt for a fact disables their threaded rendere when encoutering mesa
19:19 imirkin: thus perpetuating the notion that multithreaded gl is rare :)
19:20 ystreet00: some workflows don't take kindly to single-threaded GL though, especially when combining GL libraries
19:21 ystreet00: e.g. Gtk + GStreamer with their GL support hits GL from multiple threads
20:09 measlybb: hi imirkin: did you find solution for this problem where 221basic blocks were fed instead of 222?
20:13 imirkin: measlybb: yes, i did
20:14 imirkin: measlybb: http://cgit.freedesktop.org/mesa/mesa/commit/?id=adcc547bfbef362067bb3b4e3aee75b287bc6189
20:15 measlybb: imirkin: that is just marvelous, thanks, time to sleep
20:15 imirkin: good night joss.