02:59 KingEdgy: http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.3-Nouveau-Churn >.> so does this mean much for my GTX 960?
03:01 RSpliet: imirkin: ... did you already run out for a 950? :-P
03:25 huehner: KingEdgy: i think not it will not yet change much, mostly need to wait for nvidia to publish firmware files for maxwell's
03:25 KingEdgy: ok :[
04:39 karolherbst: mhh, maybe before I finish my PCI stuff, I should try to finish the gddr5 thingy, this seems more important at least for higher end gpus
04:46 karolherbst: ....
04:46 karolherbst: I think the blob does a static table lookup
04:47 karolherbst: how big is the change that I found the hex values of the first five PLL clocks multiple times inside the nvidia binary, if the blob doesn't do a static table lookup?
05:25 RSpliet: karolherbst: well, if they are followed by other PLL clock values in close vicinity then small, but don't underestimate how much common sequences you can stick in XX MB of code
05:26 karolherbst: yeah I know
05:26 karolherbst: just tried all of them
05:26 karolherbst: and axcept the last one, all are like 2 or 3 times there
05:26 RSpliet: are they close together somewhere?
05:26 RSpliet: (as in, a table-like structure; can you identify clock speeds close by in Hz, kHz or MHz)
05:27 karolherbst: depends on what you mean by close
05:27 karolherbst: but mhh, they aren't that closed, that it would be inside a table
05:28 RSpliet: how close? could be a lot more info in that table... regular intervals?
05:28 karolherbst: don't see any pattern
05:29 RSpliet: okay, then they could also be initialisation code for various GPUs or sth...
05:29 karolherbst: yeah
05:30 RSpliet: note though that we try to refrain from decompiling the blob as much as possible for various reasons, including legal ones
05:30 karolherbst: I hexdumped it
05:30 karolherbst: or is it already "bad"?
05:30 RSpliet: it's shady
05:30 karolherbst: I see
05:30 RSpliet: because you're looking at copyrighted material
05:30 karolherbst: ohh okay
05:31 karolherbst: so I can't use any information I got from the binaries
05:31 RSpliet: it would make nouveau's position difficult in various countries yes
05:32 karolherbst: but then couldn't mmiotraces also be troublesome?
05:32 RSpliet: no, because the input and output of a program is not copyrighted
05:32 karolherbst: okay
05:32 karolherbst: makes sense
05:33 RSpliet: (although, don't underestimate how random laws can be in certain countries... and I'm not just talking non-western countries)
05:33 karolherbst: yeah
05:33 RSpliet: I'm not a lawyer, just a messenger :-)
05:33 karolherbst: I know that usually RE is forbidden by license
05:33 karolherbst: but this isn'T legal in every country
05:34 RSpliet: hmm, but in most western countries licenses never override the law (at least in NL they don't)
05:34 karolherbst: yeah, but companies still put it in
05:34 karolherbst: also this EULA stuff, where parts are invalid in the EU if you couldn't know it before buying it
05:34 RSpliet: and judges will disregard that at first instance :-)
05:35 RSpliet: yes, I love the bit where the MS EULA says that if you do not accept the EULA, you can return the product for a full refund
05:35 karolherbst: :D
05:35 RSpliet: ... a statement that you reject as well, right? :-D
05:35 karolherbst: I accept the EULA, but not everything can be enforced by MS here, so I don't care :D
05:35 karolherbst: accepting something invalid is always a nice thing somehow
05:36 karolherbst: but
05:36 karolherbst: can be troublesome
05:36 RSpliet: diverging...
05:36 karolherbst: anyway, mhh this gddr5 thing is troublesome nethertheless
05:37 RSpliet: netherthelands? :-D erm... I'm sure it's DDR3 too, if it would reach those kind of speeds
05:37 karolherbst: I already excluded some valid PLL combinations for the sake of simplcity
05:38 karolherbst: and speed
05:38 RSpliet: yes... there must be a generation algorithm. Note that we probably don't *have* to be a 1-on-1 copy of the blob here, as we do understand the meaning of those coefficients
05:38 karolherbst: yeah
05:38 karolherbst: I only know that M!=1 is bad
05:38 RSpliet: so if you can come up with a decent solution that gets all the parameters within a desirable range, we're good
05:38 karolherbst: and I saw P=2
05:38 karolherbst: but this was rare
05:39 karolherbst: so I only check M=1 P=1 values and find the best reflock+N combination
05:39 RSpliet: and that the divider of the SCLK is often between5 and 7, it's multiplier often above twenty-something...
05:39 karolherbst: yeah
05:39 karolherbst: these are my static reflocks
05:39 karolherbst: https://github.com/karolherbst/nouveau/commit/db1cfaecb957f8be6f75eca135f1311c9066bafc#diff-c55b594c4bf4b9ffe42d3a48aca8f90aR947
05:39 RSpliet: and in general the sclk is between... 100 and 200MHz?
05:39 karolherbst: wait
05:39 karolherbst: I have a table
05:39 RSpliet: 140 and 240
05:39 karolherbst: https://gist.github.com/karolherbst/a5dd956189a533ff3e6d#file-blob-values-for-pll-csv
05:40 karolherbst: I saw 144642 once
05:40 karolherbst: and 234900 too
05:40 RSpliet: yes, got it
05:40 karolherbst: and most of the values in between
05:40 karolherbst: maybe I made 1 or 2 up because of pattern
05:40 karolherbst: the reg value has a pretty obvious pattern
05:40 karolherbst: first row
05:41 RSpliet: it kind of diminishes the fN factor though...
05:42 karolherbst: N is the first number?
05:42 karolherbst: I don't know the order, so
05:42 RSpliet: see line 67 of your script
05:42 karolherbst: ohh right
05:43 karolherbst: this I got from the nouveau source
05:43 karolherbst: I just translated it into bash
05:44 karolherbst: sometimes the blob is using "wrong" clocks
05:44 karolherbst: this is bothering most
05:44 mstypa: mupuf: i got a 10de:0ca0 NVIDIA Corporation GT215 [GeForce GT 330]. the fan does not turn on. even manual mode for pwm1 does not turn it on. faq told me to msg you.
05:44 RSpliet: fN is an important factor for the sclk calculation
05:45 karolherbst: yeah and for my clock its pretty good
05:45 karolherbst: 4008MHz "spec"
05:45 RSpliet: right, but the blob *changes* it when reclocking
05:45 karolherbst: 2004750 * 2 calculated by nouveau
05:46 karolherbst: but for other clocks the difference is more like 30MHz in the end
05:46 karolherbst: and also it decreases after upclocking by 20MHz or something
05:46 karolherbst: sometimes
05:47 RSpliet: which means that your sclk calculation could be up to 13,5MHz off from the actual running clock in the blob... and since we're talking about a multiplication of 10, this could give you quite a botched view of just how accurate the blobs clocks are
05:47 karolherbst: its still under 1%
05:48 karolherbst: but nouveau was clocking before to 4050MHz, sooo
05:48 RSpliet: you seem to be missing the point, where you hardcoded the value for 0x132030 in your script
05:48 RSpliet: and then assume that the blob is wrong rather than your calculation
05:48 RSpliet: or do you overwrite all those values manually for each decode?
05:48 karolherbst: mhhh it depends on the 0x132004 reg
05:49 karolherbst: sometimes it starts with 0x11... something
05:49 karolherbst: and then 0x132030 changes
05:49 karolherbst: otherwise its 0x4
05:49 karolherbst: but I have now the nice tool of mupuf
05:49 karolherbst: I could recheck with it
05:49 RSpliet: ok
05:51 karolherbst: mhhh
05:51 karolherbst: it only prints the MHz values
05:51 karolherbst: not khz ones
05:54 karolherbst: okay, seems like I did something wrong indeed
05:54 karolherbst: but I am not that worried, because the blob is also sometimes far away from the requested one
05:55 RSpliet: is it really?
05:55 karolherbst: and by far I mean like 10MHz
05:55 RSpliet: did you verify that with nvatiming ?
05:56 RSpliet: on GT21x I think I've always seen it being accurate up to 3MHz
05:56 RSpliet: and these kepler PLLs allow for greater accuracy given it has more factors to wiggle
05:56 karolherbst: usually it is pretty close
05:57 karolherbst: requested 4088, got 4082, only 6MHz off
05:58 karolherbst: found one with 8MHz difference
05:58 karolherbst: but I think this has more todo with that one PLL restriction
05:58 karolherbst: you just can't calculate every clock if you enforce them
05:59 karolherbst: yeah, its usually between 8 and 2 MHz
06:02 karolherbst: but do you know what is fiunny?
06:03 karolherbst: ohh no, its okay
06:06 kfractal: kalrolherbst: your coments re 0x132004 and 0x132020 were with regard to which chip? just curious...
06:07 kfractal: eep: *0x132030*
06:07 karolherbst: nve6
06:07 karolherbst: 770M
06:09 karolherbst: RSpliet: the thing why I keep it simple is, that I don't want to have a loop which calculates specific PLL values for every possible combination just to find the closest one
06:09 karolherbst: I am pretty sure the values aren't in the vbios, because that would mean to have a lot of values there just for this
06:11 karolherbst: maybe the did put every possible value between 2400 and 10000 into the vbios, who knows
06:13 karolherbst: so what I need is a smart algorithm, which checks not too much values for the PLL
06:17 RSpliet: karolherbst: there's too many unknowns to do that in a linear fasion, finding the right PLL settings has always had a bit of brute-sorcery around it
06:18 karolherbst: :/
06:19 RSpliet: but if you know you want an sclk between 140 and 240 MHz (which seems to be what nvidia is doing), you can always start by calculating a multiplier that gets you in that range with a P of 1 or 2 (calculate a multiplier * 2, if even, P = 1, if odd P = 2)
06:19 karolherbst: but if you keep M=1 and P either 1 or 2?
06:19 RSpliet: wait, the other way around :-D
06:19 RSpliet: then you can focus on getting an sclk as close as you can
06:19 karolherbst: currently I do this: https://github.com/karolherbst/nouveau/commit/db1cfaecb957f8be6f75eca135f1311c9066bafc#diff-c55b594c4bf4b9ffe42d3a48aca8f90aR972
06:19 karolherbst: but I have fixed refclocks
06:20 karolherbst: but getting the refclocks is the smaller problem
06:21 RSpliet: getting refclk is a PLL calculation with stricter PLL limits
06:21 RSpliet: (P 5 - 7, N 37 - 43, M... something)
06:21 RSpliet: and fN for post-processing
06:22 karolherbst: didn't check fN for the refclocks, but I don't think there ever was one
06:23 karolherbst: M=1
06:23 karolherbst: fN=0
06:23 RSpliet: you *can* use fN to get a more accurate result
06:23 karolherbst: P5-7 and N 0x25 - 0x2b
06:23 karolherbst: mhh
06:23 karolherbst: don't know how that effects stability, but the refclock doesn't effect it that much
06:23 karolherbst: the other PLL is more important
06:24 karolherbst: It also kind of worked with a 405 MHz refclock for me
06:24 karolherbst: and N=5 in the second
06:24 RSpliet: well, getting the right output clock will definitely improve stability
06:24 karolherbst: sure? my gpu drives fine with 25% overclock in RAM
06:25 RSpliet: and not every card is created equal
06:25 karolherbst: I don't think the clock itself is important, but rather what the PLL get
06:25 RSpliet: gnurou: I reckon you never ran into this problem... none of the clocks on the Tegra as as complex as the FB one, are they?
06:28 kfractal: RSpliet: they may be similarly complex, but FB isn't really present on Tegra.
06:29 RSpliet: kfractal: well, yes I know Tegra doesn't have FB... but you never had to deal with some sort of "two stage" PLLs so to speak for other clocks have you?
06:30 RSpliet: as in, the nouveau tegra code seems to allow changing clocks like it is
06:31 kfractal: RSpliet: to clarify, i should have said "gpu code on tegra doesn't deal with the memory clocks." we just don't have code for those clocks at all as they're handled by sysmem drivers.
06:32 RSpliet: yes, understood
06:32 kfractal: RSpliet: i was poking around just now trying to see what's diff/same between gk20a and gk107 with regard to those registers. we don't hit them at all on gk20a.
06:34 karolherbst: RSpliet: do you know how gddr5 is handled on Tesla and Fermi?
06:34 RSpliet: karolherbst: hardly; but this is not memory-technology specific
06:35 RSpliet: it's just that GDDR5 happens to be the only type of memory that has it's clocks astronomically high
06:35 karolherbst: I know, I was just wondering how it is done there in nouveau
06:35 karolherbst: mhh
06:35 karolherbst: because Gddr5 uses clock *4
06:35 RSpliet: have you looked at http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/clk/gk20a.c ?
06:35 RSpliet: it's not FB specific, but this is NVIDIA code
06:36 karolherbst: RSpliet: the actual clock is 1002MHz for 4008 gddr5 MHz
06:36 RSpliet: yes
06:37 RSpliet: that's probably because that's the operation speed of the memory controller (rather than the memory)
06:37 karolherbst: yeah
06:38 karolherbst: I think the memory drives at 2004 though and is just able to do 2 things pre clock
06:39 karolherbst: yeah two 32bit transfers per clock
06:39 karolherbst: anyway
06:39 RSpliet: yep, and uses alternating lanes so the controller can fetch the result of both on every tick?
06:39 RSpliet: something like that...
06:41 karolherbst: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/clk/gk20a.c#n150
06:41 karolherbst: or is this for the core?
06:41 karolherbst: wait
06:41 karolherbst: mhh
06:42 karolherbst: ohh right
06:42 karolherbst: I know, I remember
06:42 RSpliet: that' used for the core only currently... most of the other domains are not present on Tegra
06:42 karolherbst: RSpliet: both PLL used the same bios limit values
06:43 karolherbst: because the other one either doesn't exist or currently its not known how to read it
06:43 RSpliet: both PLLs have an entry in the PLL limits table
06:43 karolherbst: mhh
06:43 karolherbst: nouveau only uses one though
06:44 karolherbst: check the gt215_pll_calc function
06:44 RSpliet: in gt215 there is only one PLL
06:44 karolherbst: yeah
06:44 karolherbst: but the funciton is used for both PLLs
06:44 karolherbst: currently
06:44 RSpliet: "both PLLs"?
06:44 karolherbst: yeah
06:44 RSpliet: GT215 only has *one* FB PLL
06:44 karolherbst: but kepler uses it too
06:44 RSpliet: not a chain of two like kepler
06:44 RSpliet: yes
06:44 karolherbst: for both PLLs
06:45 karolherbst: and only checks against the limits for the one PLL
06:45 RSpliet: right, kepler code pretends there's only a single PLL... sort of
06:45 karolherbst: maybe M=1 is somehow in the bios, but nouveau doesn't reads it
06:45 karolherbst: that's why I was asking if nouveau clocks at gddr5 for other gens
06:46 karolherbst: but fermi doesn't work? and I bet nobody ever tested it for gddr5 teslas?
06:46 RSpliet: I think it isn't, but I guess your job is to split it up into two stages, where you enforce the sclk PLL to be somewhere between 140 and 240MHz, so that the input clock restriction 0for the second PLL is met
06:46 RSpliet: GDDR5 tesla's don't have a very high clock, not nearly as high as Kepler
06:46 RSpliet: and reclocking for it is unsupported
06:46 karolherbst: the input clock restriction is the less important restriction
06:46 RSpliet: no it isn't
06:46 karolherbst: it works with 400MHz input as well
06:47 karolherbst: M=1 is the more important restriciont
06:47 karolherbst: *restriction
06:47 karolherbst: at least its for me
06:48 RSpliet: then make it more important, it's probably a very useful factor to consider (or a very useful factor to figure out why it doesn't matter if it isn't)
06:48 karolherbst: the blob only uses 140-240 MHz refclock and I thought it may be a good idea to also do this
06:48 RSpliet: it probably is
06:49 karolherbst: but it worked already before doing so for me, but I think 800MHz refclock failed as well here :/
06:49 karolherbst: never debugged it deeper though
06:49 karolherbst: anyway, the bios might contain these limits
06:50 RSpliet: I learned the very hard way that changing clocks is nothing you can take the route of least resistance with; consider everything that RE'ing and documentation throws at you very carefully and make decisions based on all of that
06:51 RSpliet: that's all I'm saying; I wasted years on trying to take the route of least resistance until I figured out it has led to... way more resistance
06:52 karolherbst: :D
06:52 karolherbst: I see
06:55 kfractal: RSpliet: clocks are evil :) do you happen to know what sort of testing regime is customary for regression testing such things? just broad strokes?
06:57 RSpliet: kfractal: I'm afraid not... I'm not even sure if there is a hard tipping point that can be detected somehow to decide between a stable clock and an unstable one
06:58 RSpliet: like, what kind of hardware techniques there are available (beyond scoping them at a ridiculously high freq and eyeballing the wave)
07:01 RSpliet: kfractal: I guess if you know the restrictions you can build unit tests around your clocking code... but well, as nouveau devs, we have no such data :-)
08:01 kfractal: RSpliet: i was thinking along the lines of baseline usability regression testing. i'm reading up on what the nouveau community has in place or at hand. i would like to understand that and then try to see how we can add to that, etc.
08:04 RSpliet: oh, well, there's no regression testing framework for nouveau; lots of devs do run irregular piglit runs for unit-testing while developing new features
08:05 RSpliet: in addition we know that Intel and Broadcom have a test-suite containing a variety of shaders they use for statistics measurement (the instructon count they add to a lot of commit msgs)
08:06 RSpliet: but no automated jenkins set-up to nightly check out mesa and test it; I'm not sure if nouveau is stable enough right now to facilitate that
08:07 karolherbst: or has enough machines for all the cards
08:07 RSpliet: well, sure, there's that, but there's only so many you need for usability tests from Fermi on...
08:07 karolherbst: or is it somehow possible to tell if a generated binary is "fine"
08:08 kfractal: yeah, determining level of testing (sanity -> feature coverage -> perf) and then resource issues is an industry unto itself. but, it's not terrible to get something started once clear goals are set for the phases, etc.
08:08 RSpliet: Tesla had a few flavours (like, 4?) and maybe some per-chip HW bugs that required chicken bits to be set in the ctxprogs or sth
08:10 RSpliet: kfractal: yes, fair enough... to be honest, having a continuous integration server with one Fermi and one Kepler in to run piglits could already be quite useful if we get to the point where we want to increase the complexity of the shader compiler
08:11 RSpliet: (and a Maxwell once they are up and running...)
08:11 kfractal: definitely helps give folks confidence.
08:11 RSpliet: although piglit does generate a bit of noise wrt. precision and rounding errors
08:13 RSpliet: if perf testing is desired we'd probably be easiest off with trying to automate pts
08:13 RSpliet: (insofar Michael hasn't done that already, apparently he's got some machines just continuously benchmarking... "stuff" now)
08:16 kfractal: RSpliet: s/folks/devs/g in my last one. i'll read up on piglit.
08:16 mstypa: fan control isnt working for me atm. can anyone tell me how to tell nouveau to disable fan control completely? i want the card to keep running the fan on its own like when the pc is booting.
08:17 mstypa: nouveau.runpm=0 does not disable the nouveau fan control
08:17 RSpliet: mstypa: sorry, I'd be happy to assist you later, at work right now
08:35 imirkin_: kfractal: piglit is about all we have
08:35 imirkin_: kfractal: i'll run a small handful of applications before pushing things that i believe could have big impact to make sure i didn't accidentally the whole thing, but that's about it
08:36 imirkin_: mstypa: try booting with nouveau.config=NvFanPWM=0 perhaps? not sure if that'd do it
08:38 imirkin_: kfractal: but really anything automated requires dedicated hardware, and we have no funds or even organization behind us
08:39 imirkin_: and xorg has turned out a (potentially ill-conceived request) to administer that sort of thing for us
08:39 imirkin_: turned down*
08:40 imirkin_: i could try turning to SPI or something like that directly, but... meh.
08:42 RSpliet: imirkin_: well, there must be a way to start off with a Tegra K1 I reckon?
08:43 imirkin_: RSpliet: yeah, but that one doesn't really work with nouveau very well. someone needs to spend some time and test whether nouveau firmware works with it or not.
08:43 imirkin_: my solution to the problem has been to leave it turned off
08:43 RSpliet: hahaha fair enough
08:44 RSpliet: I don't have one myself unfortunately...
08:44 imirkin_: perhaps gnurou can arrange to have one sent to you? dunno.
08:45 imirkin_: i really should power it on and test, at least with gbm or something
08:46 imirkin_: gnurou: btw, thanks for offering to more forcefully request answers to my various questions. tbh i don't think it's worth your time. i don't think i'm ever going to use that list again, it's just a total black hole.
08:46 imirkin_: gnurou: if you guys were to, however, change to using a bugtracker, that would be much more transparent.
08:47 imirkin_: gnurou: here's an example of a moderately well-done one: https://github.com/ValveSoftware/Dota-2-Reborn/issues -- note how they provide status of the issue, etc
08:47 RSpliet: imirkin_, gnurou: I'm sure we can help set up some infrastructure for a bugtracker if this is going to be difficult to justify budget-wise
08:48 imirkin_: RSpliet: yes... just click this linke: http://github.com :)
08:51 RSpliet: imirkin_: heh, yes, that could work if we have control over auto assignment and the likes :-)
08:51 imirkin_: i'm sure they have features to e.g. auto-email or something
08:52 RSpliet: github is a little limited compared to bugzilla and jira and the likes
08:53 imirkin_: but then we're not tracking bugs
08:53 imirkin_: but requests for information
08:54 mstypa: imirkin_: this actually seems to work. and even better i can now adjust pwm min and max levels. very nice
08:54 RSpliet: yes, anyway, I merely wanted to make the point of "the burden for trying to improve communication is not all on NVIDIA"
08:57 imirkin_: mstypa: chances are something is a little unexpected on your board/vbios which causes nouveau to make poor decisions regarding fan speed
09:10 karolherbst: imirkin_: github has a "log" of extensions for stuff like that
09:10 karolherbst: *lot
09:26 karolherbst: RSpliet, imirkin_: brute force algorithm for both plls with "found" restrictions?
09:26 karolherbst: for gddr5
09:26 RSpliet: karolherbst: that's not a question, that's a statement with a questionmark
09:26 karolherbst: yeah
09:26 karolherbst: it was meant that way
09:26 karolherbst: ohh
09:26 karolherbst: mhhh
09:27 karolherbst: then add "is the best way for gddr5 reclocking to do a"
09:28 karolherbst: ohh but I already found a minor optimisation
09:28 karolherbst: when iterating over the N, the N with the next higher refclock can't be less than the last N-1
09:29 RSpliet: I'm sure there's clever ways of narrowing down the search space, but that is up to you :-)
09:29 karolherbst: and we should stop increasing N if we are already higher then the requested clock
09:29 karolherbst: this will likely lead to max 4 checks for each refclock
09:29 karolherbst: but what about fN?
09:30 RSpliet: I would personally use fN as a "post-calculation" tuning value to get closer to the desired frequency
09:30 karolherbst: okay
09:30 karolherbst: so just get close as possible with variable N and P=1 or 2, then use fN to get even closer
09:30 RSpliet: you might find that you can't achieve the exact frequency but rather get within a few MHz, fN can then be used to get closer :-)
09:30 RSpliet: well, that's what I would try at least
09:32 karolherbst: the order of the reg is fN P N M ?
09:32 RSpliet: fN is in a different register as far as I know
09:32 karolherbst: mhh okay
09:43 karolherbst: RSpliet: for the first clock I only have to calculate this: (crystal * N) + (((u16)(fN + 4096) * sclk) >> 13) ?
09:44 karolherbst: / (M * P)
09:44 RSpliet: well, crystal and sclk are kind of a given
09:44 karolherbst: sclk is crystal for the first PLL anyway
09:44 karolherbst: M is also given = 1
09:45 karolherbst: but mhh
09:45 karolherbst: I don'T want to copy this calculation to some other place
09:45 karolherbst: its currently in keplers read_pll
09:46 karolherbst: maybe I should make it a function, with input fN, N, M, P and clock?
10:24 night199uk: hrm
10:24 night199uk: any other reference for BIT tables than nouveau/nvbios (envytools)
10:24 night199uk: otherwise anyone have more info on the BIT ’T’ table than is in the source?
10:24 night199uk: esp version 0x20?
10:32 RSpliet: night199uk: do we have any idea what it's for in the first place?
10:33 imirkin_: night199uk: you have all the docs we have :) if it's not in nvbios/nouveau, we probably don't know much about it
10:33 RSpliet: well, unless it's in nvkm/subdev/bios/*
10:34 imirkin_: that'd be the 'nouveau' bit of it
10:35 RSpliet: ah yes, sorry... less sharp than I hope to be at 18:30
10:36 imirkin_: looks like we don't parse the bit T table anywhere
10:40 RSpliet: it's a fairly small table though
10:40 RSpliet: well, it is on NVA8
10:41 RSpliet: just four 16bit integers and some header faff from what I can tell
10:41 RSpliet: 12250, 16500, 33000, 25000
10:41 RSpliet: any of those numbers sound familiar?
10:41 imirkin_: yeah, actually
10:42 imirkin_: 165000 is the max single-link TMDS speed
10:42 imirkin_: and 330mhz is dual-link
10:42 imirkin_: never heard of 250mhz though
10:42 imirkin_: however allegedly fermi had HDMI that was limited to 225mhz
10:42 imirkin_: but perhaps it varied board to board, and was actually 250mhz on some?
10:42 RSpliet: this is Tesla
10:43 imirkin_: hmmmmmm
10:43 imirkin_: did any tesla's have hdmi 1.3?
10:43 imirkin_: what's the marketing name for this board? GT 240>?
10:44 RSpliet: G210M in particular... seems to have HDMI 1.3a
10:44 RSpliet: the first one could be LVDS?
10:44 imirkin_: probably the max TMDS speed for hdmi then
10:44 imirkin_: i wonder what the 122.5mhz thing is though
10:45 imirkin_: yeah, could be lvds. i know nothing about lvds though
10:45 imirkin_: robclark: --^ does 122.5mhz sound like a frequency you've heard of re TMDS?
10:45 imirkin_: er, LVDS
10:45 RSpliet: maximum pixel clock of 112MHz, according to wiki
10:45 imirkin_: so one of them has a typo ;)
10:45 imirkin_: let's fix wikipedia!
10:46 imirkin_: Hauke: did you ever provide your vbios anywhere?
10:46 RSpliet: well, I guess the standard doesn't forbid being able to set higher clocks, does it?
10:46 RSpliet: night199uk: is that sufficient information of the T table for you? :-P
10:48 RSpliet: imirkin: I typo'd though, the fourth *is* 22500, the first is 12280
10:48 RSpliet: *cough* 12880
10:48 imirkin_: oh cool
10:49 imirkin_: on my gk208 it's just 2 bytes
10:49 RSpliet: a pointer to the real table :-)
10:49 imirkin_: maybe
10:49 imirkin_: 0xe528 == 58664
10:50 imirkin_: and that area is all 0's in the vbios
10:50 imirkin_: so i think it's a raw value
10:50 imirkin_: or i don't know how to read hexdump output
10:51 robclark: imirkin, not in particular.. but not sure pixel clks for random lvds panels are as standardized as say hdmi/cea..
10:51 night199uk: hey
10:51 night199uk: Sorry
10:51 night199uk: Was away
10:52 night199uk: are you looking at ver 1.1?
10:52 imirkin_: another random GK107 bios also has a 2-byte bit T with 0x5280 == 21120.
10:52 night199uk: or 0x20?
10:52 night199uk: my GK108 has 0x20
10:52 imirkin_: GK108 isn't a thing
10:52 night199uk: er
10:52 night199uk: whatever this is then :-)
10:52 night199uk: GF108
10:52 night199uk: GTX680
10:52 RSpliet: imirkin_: BIT table 'T' version 1 at 0x0337 length 0x0002
10:53 imirkin_: GTX680 is most likely a GK106 -- check lspci
10:53 RSpliet: point to 0x5E25
10:53 night199uk: i can’t. actually, as i don’t actually have the card
10:53 night199uk: just the vbios
10:53 night199uk: :-)
10:53 night199uk: but i see version 1 length 2
10:53 imirkin_: er right. 52e5 actually
10:53 imirkin_: in case you're not dyslexic :)
10:53 RSpliet:sighs
10:54 RSpliet: it sure looks like it
10:54 night199uk: so I see version (0x20) ,header len (0xd) as usual
10:54 RSpliet: I think 0xD is the full length of the table this time
10:54 imirkin_: ok, so starting with 52e5, i get: 71 20 0d 04 00 00 50 32 74 40 e8 80
10:54 night199uk: what i’m guessing is entry len (0x4) as from the docs i can find in nouveau entries seem to be Clock (word) / Script (word)
10:55 imirkin_: so probably that's 4 entries
10:55 RSpliet: four entries
10:55 imirkin_: 0, 0x3250, 0x4074, 0x80e8
10:55 imirkin_: right?
10:55 night199uk: 0x4074 is definitely a pixel clock (16500)
10:55 imirkin_: aka 12880, 16500, 33000
10:55 night199uk: as this is hard coded in the EFI code for table version < 0x20
10:55 RSpliet: no... 0x3250, 0x4074, 0x80e8, 0x7404
10:56 night199uk: okay - so this is what you were referring to about TMDS clocks?
10:56 imirkin_: night199uk: yeah, i guess
10:56 imirkin_: i do wonder what the first thing is
10:56 imirkin_: this is a desktop gpu
10:56 imirkin_: perhaps they still have the LVDS thing in there
10:56 imirkin_: perhasp it's indexed by dcb type? dunno
10:56 RSpliet: could the connector table be indexing in this table?
10:56 night199uk: so its most like Version, table length, num entries, (unknown word) then 4 x pixel clocks
10:56 night199uk: sec
10:57 night199uk: let me look at the entry parsing code in the vbios
10:58 night199uk: so 0xd is the header length
10:58 RSpliet: no
10:58 night199uk: the parsing code skips 0xd
10:58 RSpliet: what?
10:58 night199uk: so something starts at 0xd also
10:58 night199uk: not sure
10:58 night199uk: sec, let me check
10:59 RSpliet: could be a script
10:59 night199uk: so starting from 0xd we get 2 words
11:00 night199uk: actually wait, at 0xd is an offset to an entry
11:01 night199uk: sec, let me figure this code out first rather than guessing
11:01 night199uk: thanks for the clock info though
11:02 imirkin_: Hauke: can you double-check that your vbios has a 225mhz limit there? (or post your vbios somewhere)
11:09 night199uk: so depending on ver
11:09 Hauke: imirkin_: how do I find this out?
11:09 night199uk: starting at 0xb or 0d
11:09 night199uk: 0xd
11:10 imirkin_: Hauke: your vbios is available in /sys/class/debug/dri/0/vbios.rom
11:10 Hauke: imirkin_: I saw that an old blob allowed max 165 and a recent blob allowed 225mhz
11:10 night199uk: there is a pointer to a table
11:10 night199uk: and that table contains pairs of PixelClock/Address I think
11:10 imirkin_: Hauke: you can run it through nvbios from envytools
11:11 night199uk: does that make sense?
11:11 night199uk: so probably TMDS script entries
11:11 night199uk: why are script entries indexed by pixel clock? i saw this with the others as well, ‘d’ table I think
11:12 imirkin_: Hauke: if you run it with nvbios -v, you should see something like http://hastebin.com/emumafonul.avrasm
11:13 Hauke: imirkin_: ok will do
11:13 imirkin_: note that the reason i left those 2 lines of the hexdump is that the address of the table was 0x52e5 (it's a LE 16-bit value)
11:17 Hauke: imirkin_: sometime I see red pixels blinking in some dark area
11:17 Hauke: I do not know if this could be caused by this patch?
11:18 imirkin_: dunno... unlikely
11:18 imirkin_: could be due to not enough bandwidth
11:18 Hauke: imirkin_: here is the output: http://pastebin.com/anJGZpXT
11:18 imirkin_: they have some conformance mode where they stick red colors into "bad" pixels
11:19 Hauke: what type of bandwith?
11:19 imirkin_: ok, so table at 4e33
11:19 imirkin_: gpu fill rate/etc
11:19 Hauke: I am seeting these red pixels on my ubuntu desktop
11:20 Hauke: imirkin_: do you need any more information?
11:20 imirkin_: Hauke: take a look at ftp://download.nvidia.com/open-gpu-doc/gk104-disable-underflow-reporting/1/gk104-disable-underflow-reporting.txt for what i mean
11:20 imirkin_: i know this is about GK104, but i bet fermi had a similar type of thing
11:22 karolherbst: what's the best way to get the crystal clock`
11:23 karolherbst: ohh found it
11:23 Hauke: imirkin_: are you Ben?
11:24 imirkin_: Hauke: no. skeggsb is ben.
11:25 imirkin_: Hauke: btw, can you hexdump a few lines of your vbios around 43e0
11:26 imirkin_: er, make that 4e30
11:26 kb9vqf: karolherbst: In case you're interested I was able to test your reclocking patch on a GTX 680 -- works perfectly
11:26 imirkin_: apparently i'm also dyslexic =/
11:26 karolherbst: kb9vqf: yeah thanks
11:26 Hauke: imirkin_: https://www.hauke-m.de/files/.nouveau/vbios.rom
11:26 karolherbst: this is like the 3rd or 4th confirmation now, without anybody saying: this is bs, doesn't work at all :)
11:26 kb9vqf: ah, ok
11:27 kb9vqf: was off IRC for a few days :-)
11:27 imirkin_: Hauke: that works too :)
11:27 karolherbst: imirkin_: how much do you need?
11:27 imirkin_: karolherbst: of what?
11:27 karolherbst: bios
11:27 imirkin_: yours? none
11:28 karolherbst: ohhh
11:28 imirkin_: i also have it already :)
11:28 karolherbst: and I cannot read :D
11:28 Hauke: imirkin_: why are you intrested in my bios?
11:28 imirkin_: ok... so you have 50 32 74 40 e8 80 e4 57
11:28 imirkin_: which translates into ...
11:29 imirkin_: excellent
11:29 imirkin_: 12880, 16500, 33000, 22500
11:29 imirkin_: so let's decree that 12880 is actually 12.88MHz and is the min tmds link speed
11:29 imirkin_: and the others are the single-link/dual-link/hdmi limits
11:30 Hauke: imirkin_: yes that should match
11:31 imirkin_: skeggsb: any objections to that? --^
11:31 imirkin_: (basically bit 'T' table seems to contain the various limits)
11:31 glennk: "timings" ?
11:31 imirkin_: glennk: yes... post-facto :)
11:31 night199uk: interesting
11:31 imirkin_: glennk: like ax/bx/cx/dx are accumulator, base, counter, and data
11:31 night199uk: the only one of those i currently see used by uefi vbios is offset +7 == 0x4074 though
11:32 night199uk: == 16500
11:32 imirkin_: right. that's the single-link dvi limit
11:32 night199uk: so thats single-link tmds speed?
11:32 imirkin_: should see if it existed in those idiotic old boards that had stupid limits
11:33 imirkin_: a bunch of nv3x's limited it to like 135mhz
11:33 imirkin_: i don't have the vbios repo here... can someone check?
11:40 night199uk: odd, in this vbios, table + 0xd = 0xdd5b
11:40 night199uk: which points to nothing
11:41 night199uk: 56667
11:41 night199uk: mean anything?
11:42 karolherbst: RSpliet: ohh the blob indeed sets an fn for the refclock PLL
11:42 imirkin_: skeggsb: either you or i are not understanding the underflow thing properly
11:43 imirkin_: ohhh, it's me. i think.
11:43 imirkin_: (coz i was looking in the wrong place)
11:44 karolherbst: mhhh
11:44 imirkin_: Hauke: look at gf119_disp_root_init (in skeggsb's updated tree)
11:44 karolherbst: somehow I am not in the mood to also iterate over multiple fN values
11:44 imirkin_: Hauke: note how at the end it does the workaround
11:44 imirkin_: Hauke: add the same thing in rootg84.c (or g94.c)
11:44 Hauke: imirkin_: where do I find skeggsb tree?
11:45 imirkin_: http://cgit.freedesktop.org/~darktama/nouveau
11:45 Hauke: is this to prevent the red dots?
11:45 Hauke: pixels
11:45 imirkin_: note that it's an out-of-tree module
11:45 imirkin_: yes
11:45 imirkin_: well, it won't prevent the issue
11:45 imirkin_: assuming it's the same one
11:45 imirkin_: the issue being "display engine underflow"
11:45 imirkin_: but instead of drawing red dots, it'll draw the previous pixel's value
11:45 imirkin_: which should be more visually pleasing
11:46 imirkin_: i'm guessing it underflows coz you have a giant screen and a fermi that's clocked way too low
11:46 imirkin_: or i could just be guessing entirely wrong
11:47 imirkin_: actually, you can test this on a running system
11:47 imirkin_: are you seeing the issues now?
11:47 Hauke: yes I will do
11:47 imirkin_: if so, nvapeek 616308
11:47 Hauke: but I do not see these red pixel every time just sometimes so it would take some days to verify that something changed
11:47 imirkin_: and nvapeek 616d08
11:48 imirkin_: if bit 4 is set (aka 0x10), then you're seeing underflows
11:48 imirkin_: and if bit 8 is set, then it's being shown as red
11:48 imirkin_: (aka 0x100)
11:49 Hauke: currently I do not have red pixel and I do not know how to get them
11:49 imirkin_: can you do the nvapeek anyways?
11:49 imirkin_: it's in envytools/nva
11:49 imirkin_: if bit 8 is set, it's this issue. if not, it's a diff issue
11:50 imirkin_: ideally it'll just return '0' (which is expressed as '...')
11:52 imirkin_: night199uk: i'd ignore the 0xd. it's probably the table length.
11:53 Hauke: imirkin_: I am getting a compile error: fatal error: nva.h: No such file or directory
11:53 night199uk: imirkin: nah, it’s not
11:53 imirkin_: Hauke: very sad :( did you do the cmake thing?
11:53 night199uk: never mind though - don’t have anything that needs it now
11:53 night199uk: there is other code in the vbios that specifically reads from BIT ’T’ table offset + 0xD
11:54 imirkin_: night199uk: 0xd = 13. 10 bytes for the various values, and 3 more bytes. i think that's right.
11:54 night199uk: i.e. it looks up bit ’T’ address then adds 0xd
11:54 night199uk: which gets a pointer to another table
11:54 imirkin_: night199uk: hm ok
11:54 night199uk: i don’t find where it’s used yet though
11:54 night199uk: so never mind
11:54 imirkin_: night199uk: could be a display script
11:55 night199uk: it seems to be a table of pixel clock -> word mappings
11:55 night199uk: yeah, i suspect a script, indexed by pixel clock
11:55 imirkin_: e.g. for me
11:55 imirkin_: 0x52e0: 0 kHz -> script at 0x52e4
11:55 karolherbst: RSpliet, imirkin_ : current patch https://github.com/karolherbst/nouveau/commit/93f350d3518abd602ad61f9dd23a5d371dc42905
11:55 imirkin_: 0x52e4: 71 DONE
11:55 imirkin_: and then the T table starts at 52e5
11:56 imirkin_: and goes for 13 bytes (i.e. 0xd)
11:56 imirkin_: so i think the fact that the thing after that is a pointer to another table is coincidence
11:56 imirkin_: since all that stuff happens to be packed
11:57 Hauke: imirkin_: I made it build
11:57 night199uk: interesting
11:57 Hauke: I am getting ... for both
11:57 night199uk: but that table before - is it used by any of the other script tables?
11:57 night199uk: e.g. ‘d’, ‘U’, etc?
11:57 imirkin_: Hauke: ok, so either pre-kepler does underflow reporting differently, or you're hitting a different issue.
11:57 Hauke: I haven't seen the red pixel this time
11:58 night199uk: imirkin_: i definitely see something similar before mine
11:58 imirkin_: night199uk: well, let's see... the address is 52e5 + 0xd = 52f2
11:58 imirkin_: let's search around for that
11:58 imirkin_: heh
11:58 imirkin_: Subroutine at 0x5887:
11:58 imirkin_: 0x5887: 5b f2 52 CALL 0x52f2
11:58 night199uk: so the code does something like this
11:58 imirkin_: so like i said, it's unrelated stuff.
11:58 night199uk: UINT32 TTableAddr = VBios__GetBitTable(This, 'T', 0, 0);
11:58 night199uk: UINT16 Address = VBios__GetVBiosWord(This, TTableAddr);
11:59 night199uk: if (Index == 0)
11:59 night199uk: Address += 0xb;
11:59 night199uk: else if (Index == 1)
11:59 night199uk: Address += 0xd;
11:59 night199uk: ...
11:59 night199uk: soz for spam
11:59 imirkin_: night199uk: errr... which code?
11:59 night199uk: UINT16 Pointer = VBios__GetVBiosWord(This, Address);
11:59 night199uk: VBIOS
11:59 imirkin_: hmmmmmmmm
11:59 imirkin_: what's Index?
11:59 night199uk: dunno, call it ‘unknown’ actually
11:59 imirkin_: and what's the context of this code?
12:00 imirkin_: i.e. when does it do this?
12:00 night199uk: i thought it was an entry index into a table first
12:00 night199uk: but it seems not
12:00 night199uk: i suspect it might be version >> 0x4
12:00 night199uk: well - context i don’t have yet
12:00 night199uk: i didn’t find where this was called yet
12:00 imirkin_: well, in *my* vbios, +0xd = random subroutine that's called elsewhere
12:00 imirkin_: could be not-so-random though
12:01 night199uk: yeah
12:01 night199uk: in mine + 0xd is also junk :-)
12:01 night199uk: so, i think this must only be called in certain circumstances
12:01 imirkin_: it _is_ called from various display subroutines
12:01 imirkin_: so perhaps not accidental that it's placed right after the T table
12:01 night199uk: well, yeah - but not something useful here
12:02 night199uk: this code expects a pointer to a table at 0xd
12:02 night199uk: and that table should contain pixelclock->script pairs
12:02 night199uk: which is clearly not whats in either of our vbios
12:02 imirkin_: ftr, this is what those subroutines do for me: http://hastebin.com/raw/ovihiwenov
12:03 night199uk: interesting
12:03 night199uk: 52f2 is actually a script
12:03 imirkin_: like i said, yes.
12:03 imirkin_: and it's called from a lot of display scripts
12:03 night199uk: sorry, i missed that part slightly
12:03 night199uk: interesting
12:04 night199uk: never mind, i think this part of code must be unused in our vbios
12:04 night199uk: maybe only used if some other vbios setting is true
12:04 night199uk: if i find its used later i’ll come back to it
12:04 night199uk: thanks :-)
12:04 imirkin_: it writse into SOR[0].SEQ_INST
12:04 imirkin_: and configures LINK[0] and LINK[1]
12:04 imirkin_: not sure what those things mean though, unfortunately
12:07 karolherbst: when is like the deadline for 4.3? or is the next nouveau stuff for 4.4?
12:07 karolherbst: want to fix the gddr5 thing for the next release
12:07 imirkin_: karolherbst: i wouldn't try to worry about it.
12:07 imirkin_: that will just give you worry lines
12:08 karolherbst: mhh I think I am pretty close to be finished with the patch, there is space for improvements, but nothing big as far as I can tell
12:08 imirkin_: karolherbst: then get skeggsb to take it ;)
12:08 karolherbst: well there are two points on my list: add debug/trace messages and error handling
12:09 karolherbst: but yeah, will try to post on the patch tomorrow or the day after?
12:09 karolherbst: just want to see what you have to say about that first
12:44 RSpliet: karolherbst: points of feedback
12:44 RSpliet: the function name is not entirely appropriate; you're not calculating an M table
12:45 RSpliet: I'd personally prefer it if you would have the unit of measurement in the name "targetclk"... something like target_khz or target_mhz
12:48 RSpliet: apart from naming (you might want to reconsider "pref", as it collides with the common abbreviation for "preference" :-)), codestyle is fairly tidy
12:49 RSpliet: oh, please always use C-style /* */ comments
12:49 karolherbst: okay
12:49 RSpliet: and don't exceed the 80-character width limit
12:49 karolherbst: ohh right, this also exist
12:50 RSpliet: yep, quite useful for GPU development over serial cables or in general when KMS doesn't work :-)
12:50 karolherbst: how strong do you feel about fN in the first PLL?
12:50 karolherbst: allthough it shouldn't be that hard to get a nice value for it
12:52 RSpliet: I'd prefer if you do set it
12:52 karolherbst: is fN only for adding?
12:52 karolherbst: ohh now I see it
12:52 RSpliet: I believe it is, you can find out though...
12:52 karolherbst: there is this + 4096
12:53 karolherbst: mhhh
12:54 RSpliet: for some reason your "mhhh" always sounds like "oh do I really have to do more reverse engineering?"... I should have my IRC client replace them with "yay" :-D
12:54 karolherbst: :D
12:54 karolherbst: mhh is more like thinking
12:54 karolherbst: I don't quite get the meening of this "+ 4096"
12:55 RSpliet: what bit?
12:55 karolherbst: also this >> 13 shift is quite annyoing
12:56 karolherbst: that's the part "(((u16)(fN + 4096) * clk) >> 13))"
12:56 karolherbst: I try to have a nice fN = something formula...
12:56 imirkin_: that's just a round-up
12:56 imirkin_: that's a DIV_ROUND_UP(fN, 8192)
12:57 imirkin_: er... not round up
12:57 imirkin_: round-nearest
12:58 karolherbst: mhh if fN = 0 the clock increases by 13500 / (M*P)
13:04 imirkin_: oh, i missed the * clk
13:05 imirkin_: i still stand by my comment though :)
13:05 imirkin_: it's a round(fN / 8192) * clk / 8192
13:06 imirkin_: [er, that's not quite right either. but you get the ide.a]
13:08 karolherbst: but why do I get 13500 for the part if fN=0
13:08 karolherbst: with clock 27000
13:19 soreau: karolherbst: Because (4096×13500) ÷ (2^(13−1)) = 13500
13:21 karolherbst: yeah I know, but what does it have to do with rounding?
13:22 imirkin_: if that confuses you, ignore it
13:26 specing: I'm probably asking this for the N-th time, but how do I set my card to the lowest of the low perf level (G84M) and keep it there?
13:27 imirkin_: specing: step 1: install linux kernel 3.12 or earlier.
13:27 specing: oh come on
13:28 imirkin_: specing: step 2: boot with nouveau.perflvl=0 (or = 1, i forget)
13:28 imirkin_: alternatively wait until the support comes back around for those GPUs
13:28 specing: no way to dynamically set it on 3.18?
13:28 imirkin_: nope
13:28 imirkin_: the support was dropped in 3.13
13:29 specing: damn
13:29 specing: can I rsync the nouveau source dir over from 3.12 to 4.0.8?
13:29 specing: and expect it to work?
13:29 imirkin_: you can expect ;) but it totally won't
13:30 specing: lol
13:30 imirkin_: there's been a ton of drm updates
13:30 imirkin_: you might have more luck with replacing the entire drm tree
13:30 imirkin_: although i'm sure there have been various other changes too that make that tricky
13:30 specing: uh oh
13:30 specing: when is the support going to come back?
13:31 imirkin_: at some point between now and the end of time.
13:31 imirkin_: this is a mostly volunteer project. i.e. no timelines.
13:32 specing: probably not wise to waste time on such old stuff
13:32 imirkin_: meh. i tend to disagree
13:32 imirkin_: RSpliet's been working on it on and off
13:33 imirkin_: not sure what the situation is on his branch. you could certain try it, but expectaions of working would be... premature
13:33 specing: I'm not going to have this for long. Going to pull the card out when I get tired of reflows and finish migrating to newer gear
13:33 karolherbst: or you could try to find out why it didn't work and improve the situation ;)
13:33 specing: then use it as a server until the other parts start failing
13:33 imirkin_: specing: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master
13:34 imirkin_: you'll need to patch it to let you reclock
13:34 imirkin_: (see the "enable user reclocking for NVA0" patch for inspiration)
13:38 specing: [ 23.872435] nouveau [ CLK][0000:01:00.0] 20: core 169 MHz shader 338 MHz memory 100 MHz
13:38 specing: [ 23.872440] nouveau [ CLK][0000:01:00.0] 21: core 275 MHz shader 550 MHz memory 200 MHz
13:38 specing: [ 23.872443] nouveau [ CLK][0000:01:00.0] 22: core 475 MHz shader 950 MHz memory 400 MHz
13:38 specing: [ 23.872488] nouveau [ CLK][0000:01:00.0] --: core 275 MHz shader 550 MHz memory 199 MHz
13:38 specing: the darn thing knows!
13:38 imirkin_: don't flood.
13:38 imirkin_: of course it knows. parsing the levels is easy.
13:39 specing: can I lower its voltage from nouveau?
13:40 imirkin_: we don't expose such knobs
13:40 imirkin_: you could manually futz with the gpio
13:40 specing: why not? This is fun stuff!
13:41 specing: what good is an 8 year old gpu if you cannot programmatically throw it into fiery pits of hell?
13:42 Karlton: very ageist of you :)
13:42 RSpliet: specing: well, you can programmatically do that if you want to...
13:42 RSpliet: we just don't provide the lever
13:44 RSpliet: I know that the current memory reclocking code works for NVA0 (G200), but not NV96 (... G96). Anything earlier like your G84M is unlikely to work well too
13:50 specing: I know I had to Coolbits 1 on binary to get more control
13:53 imirkin_: specing: once we get the actual reclocking procedure down, all that stuff becomes much simpler
13:54 specing: I'd rather it stays fixed at lowest freq all the time
13:54 specing: because temperature swings make the RoHS solder fail
13:54 specing: or something like that
13:59 karolherbst: gk104_ram_calc_pll_high_clocks ? this sounds like too long for me
13:59 karolherbst: pll_hiclk :D
13:59 RSpliet:inserts himem jokes
14:00 imirkin_: karolherbst: and byeclk?
14:00 karolherbst: this will be part of the mem overclocking patches ;)
14:01 karolherbst: mhh
14:01 specing: your nickname is too long for me
14:01 specing:suggest karolherbst renames to kh
14:01 imirkin_:suggests specing starts using tab-completion
14:01 karolherbst: :D
14:03 specing: see, you could use tab completion for that gk104_ramwhateva
14:04 karolherbst: mhhhhh I use an editor, who can't do that
14:04 imirkin_: karolherbst: Alt-/
14:04 imirkin_: (assuming you use emacs)
14:04 karolherbst: nope
14:05 imirkin_: (are there other editors?)
14:05 karolherbst: a lot
14:05 imirkin_: :)
14:05 karolherbst: but usually I don't use an IDE or something near it
14:05 specing: there are useless editors, there is vim and there is emacs
14:05 specing: emacs is an operating system, not an IDE
14:06 karolherbst: :O
14:06 karolherbst: what
14:06 karolherbst: did I miss something
14:06 imirkin_: specing: they're not useless -- they're there to make you realize how good vi and emacs are :)
14:06 karolherbst: I have to admit, but I never tried to even learn vi, though I have a book about it
14:07 RSpliet: and the fact that you can fill an entire book with how vim works kind of proves the point
14:07 specing: anyway about karolherbst being too long ... I just grepped my logs and multiplied number of lines with 11 (lenght of "karolherbst")
14:07 RSpliet: (mind you, I quite like vim in it's basics :-))
14:07 karolherbst: :p
14:07 specing: the result: 152 kilobytes just for storing 14204 karolherbst's
14:07 imirkin_: i really liked elvis, shipped by default with slackware
14:07 imirkin_: but i guess 'vim' is the cool new thing =/
14:08 karolherbst: I better not tell what I use, else you wouldn't take me serious anymore :D
14:08 RSpliet: imirkin_: "new" :-D
14:08 Karlton: there is vis if you want a small version if vim
14:08 RSpliet: karolherbst: nano?
14:08 imirkin_: intellij? :)
14:08 karolherbst: https://xkcd.com/378/
14:08 RSpliet: SystemD?
14:08 karolherbst: huh systemd got an editor?
14:08 specing: journalctl, but ofc!
14:09 specing: he puts nouveau source into binary form and then edits it with journalctl
14:09 imirkin_: karolherbst: it has everything else, i don't see why not
14:09 karolherbst: mhhh
14:09 imirkin_: why *shouldn't* pid 1 have an editor built-in
14:09 RSpliet: anyway, don't feel bad... I do bigger kernel dev in Eclipse
14:09 karolherbst: :D
14:09 imirkin_: no. *do* feel bad.
14:10 RSpliet: I'm not joking, you wouldn't believe how people stare at me for having a preference which is nonstandard
14:10 karolherbst: but I have to admit, usually you have to pimp nano a bit before it gets usefull....
14:10 specing: more like a lot
14:10 specing: put it onto a floppy and send it to detroit for a total overhaul
14:11 karolherbst: why? multiline copy/paste and this other thingy is usually enough
14:11 karolherbst: :D
14:11 karolherbst: now that I think about that
14:11 karolherbst: having and "experimental" flag for multiline copy/paste does sound like bad quality
14:12 RSpliet: does Emacs have Internet Explorer integration?
14:12 karolherbst: ohh it has it by default now
14:12 karolherbst: nice
14:12 karolherbst: D:
14:12 karolherbst: of course not
14:12 karolherbst: it doesn't even get lldb integration
14:12 imirkin_: RSpliet: you can draw random things in emacs by telling them what X window id to draw in
14:12 imirkin_: e.g. mplayer has a cmdline arg for that
14:12 imirkin_: i wonder if ie6 does too ;)
14:13 karolherbst: emacs does sound too fancy for me to be honest
14:13 karolherbst: I am always worried I use complex software and don't see a way to do something really easy I usually do the hard way, so I stick with simply stuff and spare me the "tips of the day"
14:14 huehner: i have a glean test (vertProg1) consistency segfaulting X on a NVE7 (kepler,optimus) with mesa11-rc1
14:14 huehner: anything special needed when reporting (i have gdb backtrace pointing to exaHWCopyNtoN)
14:14 Karlton: well emacs has a window manager addon now, so you actually can run _anything_ in it
14:14 RSpliet: I decided early on that vim is a nice middle ground between simplicity and "power"... I guess Emacs is more of the Max Power tool
14:15 imirkin_: huehner: are you sure it's not an intel bug?
14:15 imirkin_: huehner: anyways, start with something, we can go from there
14:16 imirkin_: RSpliet: indeed. and it doesn't abbreviate!
14:16 imirkin_: each letter is as important as the previous one
14:16 imirkin_: no... more important!
14:16 imirkin_: no... as important.
14:17 huehner: imirkin_: pretty usre, as stacktrace has nouveau_dri2_copy_region2 in it
14:18 karolherbst: new gddr5 patch version: https://github.com/karolherbst/nouveau/commit/9c2f93bdec0cd054ff50ee48cf567e0e90573686
14:18 imirkin_: huehner: well, that's certainly telling. but don't worry, i'll find a way to shift the blame ;)
14:19 RSpliet: gheheh... E-max
14:22 RSpliet: karolherbst: okay, I'm sure Ben will have some more style-ish feedback for you (but tip, try and use the same variable names as the original PLL calculation code if you feel like being ahead of those), so two things...
14:23 karolherbst: should I move the function into clk/pllgt215.c ?
14:23 karolherbst: where the other one is
14:23 RSpliet: exactly, so you can re-use it from read_pll :-)
14:23 RSpliet: and two: did you run it? :-D
14:23 karolherbst: of course I did
14:23 RSpliet: excellent!
14:23 karolherbst: I don't just do stuff like that for jiggles without knowing if it works :p
14:24 RSpliet: well, it's very tempting to make last minute tweaks and changes and then thing "ahh, it's all right, no need to test"
14:24 RSpliet: only to find some corner case in which it doesn't
14:24 karolherbst: I know
14:24 RSpliet: (by experience..)
14:24 karolherbst: I used to have debug prints to somehow trace whats going on
14:25 karolherbst: still ...
14:25 karolherbst: the one fact bothers me
14:25 karolherbst: there are always these min_m, max_m thingies
14:25 karolherbst: and these are only there for the oe PLL
14:25 karolherbst: but
14:25 karolherbst: there are tesla+ gddr5 cards
14:25 karolherbst: which should have two plls as well
14:26 RSpliet: well, there
14:26 RSpliet: s only one tesla GDDR5 card
14:26 karolherbst: still
14:26 karolherbst: maybe the limits are indeed somewhere in the bios
14:26 RSpliet: and Ben has it... but thefrequency doesn't go up that far
14:26 karolherbst: and I just missed them
14:26 RSpliet: GDDR5 has evolved quite a bit in the past 7 years
14:26 huehner: imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=91756
14:26 karolherbst: 3400 MHz as far as I see
14:26 RSpliet: as far as Fermi goes... -E_NOCLUE
14:27 karolherbst: this is till high
14:27 RSpliet: if that means ramping the PLL up to 850MHz, it'll be fine
14:27 karolherbst: mhhh
14:27 karolherbst: didn't work for me
14:27 RSpliet: on Tesla, DDR3 has PLLs as far as 810MHz
14:28 karolherbst: yeah, mine drives at 810MHz as well for 0a pstate
14:29 RSpliet: link training at 830MHz
14:30 karolherbst: fermi goes up to 4008
14:30 karolherbst: but I think you get my point, maybe its in the bios and we shouldn't hardcode those limits
14:30 karolherbst: don't know
14:30 RSpliet: could be
14:30 RSpliet: there's also the point that if this is an improvement, let's ship it
14:30 RSpliet: and then improve further, later
14:31 karolherbst: yeah ok, I know
14:31 RSpliet: as long as it's not a regression :-)
14:31 karolherbst: :D
14:31 karolherbst: I see
14:31 karolherbst: don't think I produce any regression with that
14:31 RSpliet: test it at frequencies slightly above the threshold to be sure
14:31 karolherbst: still its not perfect, but hey, it kind of works now
14:32 karolherbst: mhhh
14:32 karolherbst: like what works with the blob, too?
14:32 karolherbst: I could test 5000MHz, but well
14:32 karolherbst: this doesn't mean much
14:32 karolherbst: there are 6000MHz stock 0f cards out there
14:33 RSpliet: no, in the situation where the blob only uses a single PLL
14:33 karolherbst: ohhh, so 2300 MHz
14:33 RSpliet: and the situation where the blob would just start using two PLLs
14:33 karolherbst: I know that the blob/card crashes near 2400
14:33 RSpliet: presumably those areas kind of worked with nouveau before... would they still?
14:34 imirkin_: huehner: does it crash if you pass the other 20 flags that piglit normally passes?
14:34 imirkin_: huehner: including --quick iirc
14:34 karolherbst: RSpliet: I didn't changed the fact when two PLLs get used
14:34 karolherbst: this is still the same with and without my patches
14:34 RSpliet: ok good :-)
14:34 RSpliet: so the "below" is probably fine
14:35 RSpliet: just the "slightly beyond"
14:35 imirkin_: anyways, we're probably not respecting some bounds =/
14:35 RSpliet: because that's where you risk regression
14:36 huehner: imirkin_: my first try was: ./piglit-run.py -x glx -x streaming-texture-leak -1 --dmesg tests/gpu.py during which its ran and crashed also
14:36 imirkin_: huehner: ok :0
14:37 karolherbst: RSpliet: as I said, somewhere near 2400 the blob crashed for me, maybe it was 2300 or 2450, don't know
14:37 karolherbst: I think it was a bit under the "magic" 2400 value
14:37 RSpliet: karolherbst: but what about nouveau? did it work? does it work now?
14:38 karolherbst: under 2400 only one PLL gets used
14:38 karolherbst: its a limit from the bios I think
14:38 karolherbst: I still have to figure a nice way for me faking the pstate information, cause faking bios doesn't work for me
14:39 karolherbst: that's why I was thining about adding a interface for changing memory/core clocks
14:42 RSpliet: why can't you reboot with nouveau blacklisted, fake the bios, then modprobe nouveau ?
14:43 RSpliet: it *should* work if nouveau reads the BIOS from... PRAMIN (I think)
14:43 imirkin_: RSpliet: because optimus sucks apparently
14:49 karolherbst: RSpliet: I do, I have a hybrid gpu laptop, but for some reasons it doesn't work
14:52 specing: About the underclocking
14:52 specing: can I change a constant in the source and recompile&reload the module?
14:52 specing: and make it pick lower one
14:53 specing: or is it just running at some vbios default?
14:53 karolherbst: you could enable pstate and just use the 20 one
14:53 karolherbst: because 21 seems to be the default for you
14:53 RSpliet: specing: I guess you don't care about memory reclocking, as memory doesn't need reflowing...
14:53 specing: RSpliet: bingo
14:53 RSpliet: which probably means you can just change clocks
14:53 specing: also i doubt 512mb memory produces a lot of heat
14:54 RSpliet: well, the memory might not, but on the other hand
14:54 RSpliet: if it provides more bandwidth, there will be a bigger difference in performance between "idle" and "full load"
14:54 specing: ?
14:54 specing: yes
14:54 RSpliet: hence, the temperature difference of the GPU will be bigger too :-)
14:55 RSpliet: than when you do fix the memory clock down low
14:55 specing: pstate 20 reduces memory clocks to 100 MHz from 200
14:56 specing: how much lower than 169MHz can the GPU go? Can I disable some unnecessary "functional units"?
14:56 specing: lmsensors is saying 76'C
14:56 specing: uh oh
15:03 specing: 78
15:03 specing: 79
15:03 specing: 80
15:04 specing: then fan starts and cools it down to 75
15:04 specing: this is going to die soon
15:04 imirkin_: specing: you could force the fan to run more
15:04 specing: swings are way too big
15:04 specing: I don't know how ;(
15:05 specing: except loading the cpu, but that just introduces more heat >_>
15:05 imirkin_: oh... it's probably not hooked up to nouveau is it
15:05 specing: nope
15:05 imirkin_: is it a thinkpad?
15:05 specing: laptop
15:05 specing: unfortunately not
15:05 imirkin_: iirc it's controllable via ibm_acpi or something
15:05 specing: yes it is (have one)
15:05 specing: s/one/two/
15:05 specing: this is not even a branded laptop
15:05 specing: but an OEM one
15:10 specing: well...I found mentions of FAN in compal-laptop.c
15:21 karolherbst: mhhh
15:21 karolherbst: 75 is pretty high for lowest pstate though
15:21 specing: it is not lowest
15:21 specing: actually I don't know which it is
15:21 karolherbst: 20 is the lowest
15:21 specing: also I use thermal paste I got out of a >10 year old tube
15:22 karolherbst: seriously, if it is like always above 75, the driver isn't the issue I would say
15:23 imirkin_: thermal paste is like wine... it improves with age ;)
15:23 imirkin_: bbl
15:23 specing: karolherbst: the driver is the issue if it cant drive the hardware properly :)
15:24 specing: https://bpaste.net/show/4361a332adb2
15:24 specing: which is it even using?
15:25 specing: with nvidia blob there was a nice fancy configurator, but with nouveau all I can do is paste cryptic dmesg and wait for someone to decode it
15:32 karolherbst: specing: is it cooler with the nvidia driver?
15:32 karolherbst: and if yes, how much?
15:32 specing: yes it is because I can downclock with it
15:32 karolherbst: I meant with stock clocks
15:33 specing: dont remember exact numbers because it was over a year ago
15:33 karolherbst: but if you had to downclock, there is seriously something wrong
15:33 karolherbst: because the lowest clock are really low already
15:33 RSpliet: karolherbst: he knows ;-)
15:33 specing: yes it is, RoHS solder >_>
15:33 karolherbst: use good thermal paste maybe? :D
15:34 specing: find me an adapter to mount the pentium4 heatsink onto it
15:34 karolherbst: made a difference of 10°C with my cpu
15:34 specing: yes, but 70'C versus 80'C is still high
15:34 specing: I want it at like 50'C please
15:35 specing: also no "*pwm*" or "*fan*" nodes in sysfs :(
15:35 karolherbst: mhh
15:36 specing: also the li-ion battery nearly exploded
15:36 specing: so hot
15:39 karolherbst: ... seriously, this can't be only the gpu?
15:39 specing: idk, maybe I have a nuclear powerplant inside and dont realise it?
15:40 specing: lm-sensors says the CPU is at 45'C
15:40 specing: the cpu grills come before nvidia ones and are 1.5* as thick
15:52 karolherbst: soo you exchanged them?
15:52 karolherbst: ohh understood it wrong
16:05 specing: ok so, the driver source says "it should probably work" but doesen't provide extra features for my particular board
16:05 specing: extra features being fan control and stuff
16:05 specing: should I risk it and hexedit the module? :)
16:09 karolherbst: RSpliet: you said skeggsb has a gddr5 tesla?
16:12 karolherbst: ohhh
16:12 karolherbst: there isn't even a bit of gddr5 code inside ramgt215.c
16:20 RSpliet: correct
16:20 RSpliet: and more specifically, skeggsb has *"my"* GDDR5 tesla :-P
16:21 skeggsb: RSpliet: do you want me to bring that to xdc btw?
16:21 karolherbst: mhhh
16:21 karolherbst: I was wondering
16:21 karolherbst: is there a trace of that tesla clocking to highest pstate?
16:21 RSpliet: skeggsb: that's up to you really. I won't be there to take it back though :-(
16:21 karolherbst: I really want to check if the gddr5 pll stuff is the same on tesla
16:21 skeggsb: RSpliet: well, that kinda defeats the point of bringing it :P
16:22 karolherbst: or does gddr5 works with that tesla card with nouveau
16:22 RSpliet: karolherbst: the same as DDR2, DDR3 and GDDR3
16:22 RSpliet: eg. one PLL
16:22 karolherbst: the clock is 3400 though
16:22 karolherbst: even on my card there are two pll used for that
16:23 RSpliet: I know, but Tesla does not have two PLLs
16:23 RSpliet: for memclk
16:23 karolherbst: are you like 100% sure?
16:24 RSpliet: yes, plus I'm sure there is trace of that reclocking operation
16:24 karolherbst: mhhh
16:24 karolherbst: nva3?
16:25 RSpliet: it's not in the vbios repo
16:25 karolherbst: ohh I see
16:25 karolherbst: then I will check if fermi cards do kind of the same
16:27 RSpliet: skeggsb: well, if you're 100% certain you're not going to work on it you can always give it to mupuf or pmoreau
16:28 RSpliet: I'm more likely to meet them in a nearby future (FOSDEM perhaps? maybe sooner, who knows what crosses my path)
16:28 karolherbst: wow nice
16:29 karolherbst: look at that: { M = 0x1 | N = 0x3c | UNK16 = 0x6 | UNK24 = 0x5 }
16:29 karolherbst: that*s the second PLL
16:29 RSpliet: or more params for the same PLL
16:29 karolherbst: it says PLL2
16:29 RSpliet: I believe UNK16 and UNK24 edge out to be "*1"
16:29 karolherbst: but this entire trace is starnge
16:31 karolherbst: no, this trace is useless
16:34 karolherbst: wow
16:34 karolherbst: I don'T know but for all traces, all pll regs are the same
16:35 karolherbst: mhhh
16:36 karolherbst: okay, will name the new functions gk something then
16:43 karolherbst: skeggsb: just that you know, I try to finish the gddr5 stuff so that it could go in with 4.3 if that's okay with you
16:44 karolherbst: I heard generally only positive feedback and think it will improve the situation for most of the gddr5 kepler owner
16:57 gnurou: imirkin_: RSpliet: we have a github account (https://github.com/NVIDIA ) so probably using the issue tracker there is not a big deal
16:58 gnurou: let me see if people like the idea... I suppose the list was favored because it does not require discussion, but I don't really know actually
17:03 imirkin: gnurou: well, the biggest thing is the black hole element
17:03 imirkin: gnurou: you can make an issue tracker a black hole as well
17:03 imirkin: although it'll be more obvious as to what's pending
17:03 imirkin: the reason i pointed out the DOTA2 bugtracker is that there were people who made it clear that a particular issue was reviewed, assigned, etc
17:05 imirkin: skeggsb: RSpliet: i bet someone from collabora UK will be there though... maybe even from cambridge
17:05 imirkin: karolherbst: RSpliet: fwiw i have a nva3 gddr5 plugged in right now, so if you want me to try anything, let me know
17:06 imirkin: i started making reclocking for it "work", but it's far far far far from done
17:06 imirkin: there's a vbios and mmiotrace in http://people.freedesktop.org/~imirkin/traces/nva3/
17:07 karolherbst: ohhh nice
17:07 imirkin: this is my super-early start on reclocking for it: https://github.com/imirkin/nouveau/commit/a41f62639b14bab1f306241445398f525f8e47b7
17:08 imirkin: wholly untested btw
17:08 karolherbst: there are two PLLS?
17:08 imirkin: nfc
17:08 imirkin: didn't get that far
17:08 imirkin: i call the gddr5 calc function because it doesn't seem like the wrong thing to do ;)
17:09 imirkin: but it's not based on careful analysis to ensure that the logic is accurate
17:09 karolherbst: MPLL is for memory?
17:09 imirkin: or multiplier :)
17:09 karolherbst: ohh well
17:09 karolherbst: then SPLL is for what
17:10 karolherbst: there is also NVPLL
17:10 imirkin: sultiplier, duh!
17:10 imirkin: and the ever-popular nvultiplier
17:10 karolherbst: I see
17:11 karolherbst: so mhh looks different
17:11 karolherbst: I guess the stuff I do is really only for kepler+
17:11 karolherbst: sad
17:18 imirkin: karolherbst: did you look at my trace?
17:18 karolherbst: yeah
17:19 karolherbst: can't make much out of it sadly
17:19 karolherbst: its too different
17:19 karolherbst: also maybe its not "specilized" enough
17:19 imirkin: it was just a trace
17:19 karolherbst: yeah I know
17:19 imirkin: this was back when nouveau just *hung* when loading
17:20 karolherbst: ohh I see
17:20 imirkin: so my focus was to figure out what the blob did differently
17:20 imirkin: and after about a week of staring i gave up
17:20 imirkin: then ben got RSpliet's and figured it out in like an hour
17:20 karolherbst: it would be nice to have one just with clocking stuff
17:21 imirkin: if you send me an email with detailed instructions for what you want me to do, i can execute that proces
17:21 karolherbst: but RSpliet was telling me, that gddr5 reclocking works on his tesla card
17:21 imirkin: unlikely.
17:21 imirkin: you probably misunderstood
17:21 karolherbst: he said so
17:23 karolherbst: mhhh
17:23 karolherbst: maybe I read too much in his statements?
17:24 karolherbst: ohhhh maybe bad timing of answeres
17:24 karolherbst: mhh
17:24 karolherbst: okay
17:25 karolherbst: imirkin: basically I did this: open nvidia-settings on different gpu with -c $DISPLAY parameter
17:25 karolherbst: started trace
17:25 karolherbst: set performance mode to max perf, so that highest pstate is trigger
17:25 karolherbst: stop the trace
17:46 imirkin: karolherbst: email :) i'm not going to do it now, and i'll forget it by the time i can
18:09 gnurou: imirkin: at least with an issue tracker everybody can keep track of how things are going
18:09 gnurou: imirkin: email gets lost, deleted, and in my case I don't even receive your enquiries
18:09 imirkin: gnurou: yeah, issue tracker is a definitely step up :)
18:10 imirkin: gnurou: but having an issue tracker where you guys (not sure who "you guys" are actually) provide some sort of feedback would make it into something workable
18:18 karolherbst: why not use github (or something else) and let it autopost on the nouveau mailing list?
18:32 karolherbst: what should I put in as the copyright for a new file?
18:33 imirkin: copy from some other file, but then s/Red Hat/you/
18:33 karolherbst: okay
18:33 imirkin: it's a bsd license iirc
18:33 karolherbst: yeah, seems like it
18:34 karolherbst: I guess all of drm is bsd?
18:34 imirkin: yep
18:34 imirkin: not sure why... probably because it was imported from XFree86
18:34 karolherbst: mhh
18:35 karolherbst: I think also because its used in FreeBSD and stuff
18:35 karolherbst: don't think they want to have GPL stuff in the kernel
18:42 Karlton: More like companies such as Sony and Apple that will complain about GPL code in Freebsd and Freebsd will do their bidding and remove it
18:42 karolherbst: ?
18:43 karolherbst: no, I really think BSD don't want to have GPL code inside the kernel
18:43 karolherbst: that has nothing todo with the companies explicitly
18:43 karolherbst: they even prefer clang over gcc just because of that
18:43 imirkin: Karlton: gpl is incompatible with bsd
18:43 imirkin: Karlton: but bsd is compatible with gl
18:43 imirkin: gpl*
18:44 Karlton: yeah but they rewrite GPL software that doesn't even get linked with GPL
18:44 karolherbst: why matters the second part?
18:44 Karlton: err gets linked with BSD*
18:44 karolherbst: mhh
18:44 karolherbst: I thinkg they wrtie from scratch
18:45 karolherbst: even llvm/clang was made because of the reason GPL
18:45 Karlton: yeah I mean the will rewrite a program from scratch
18:45 karolherbst: ...
18:45 karolherbst: how ever you want to do that
18:45 karolherbst: mhh
18:46 karolherbst: or does rewrite also mean like, do new?
18:46 karolherbst: ohh nice, my patch still works by the way
18:46 imirkin: Karlton: but we're talking about the respective kernels
18:46 imirkin: Karlton: where linking is very much an issue
18:47 imirkin: hmmmm... how did i build my arm chroot
18:47 Karlton: imirkin: I know I am just saying they would refuse a copyleft license inspite of that
18:47 karolherbst: yeah
18:47 karolherbst: what's wrong with that?
18:47 karolherbst: they believe copyleft is bad and GU beleives is the right way
18:47 karolherbst: nobody knows what the right way is
18:47 karolherbst: its only about believe
18:47 karolherbst: mostly
18:49 Karlton: Well the most used Freebsd distro is Sony Playstation, so the FSF has it right
18:49 karolherbst: why?
18:49 karolherbst: Linux also failed to reach its goal
18:49 Karlton: They made more proprietary software than free software
18:50 Karlton: at least in copies
18:50 karolherbst: I see you miss the point ;)
18:50 karolherbst: its not about having the right to modify the software as a user whenever you like, but to use the source however you like
18:51 karolherbst: ofcourse BSD "failed" if you compare to GNU goals
18:51 karolherbst: so did GNU fails if you compare with BSD goals
18:51 karolherbst: but llvm is a very good example, why BSD can say, their goals are as valid as the GNU ones
18:52 karolherbst: no many researchers would rather reasearch with GCC than with llvm
18:52 karolherbst: and that's because GCC tried to exclude prop extension, so that its architecture got messy and ugly and bad
18:52 karolherbst: and nobody can write extension about internal stuff like AST trees or whatever
18:53 Karlton: Sony doesn't release their source, they don't just restrict you from modifing it
18:54 karolherbst: you shoudl really try to understand what BSD is about
18:54 Karlton: I fully understand that
18:54 imirkin: guys. this is #nouveau
18:54 Karlton: Which is why they are bad
18:54 imirkin: not #bsd-vs-gpl.
18:54 karolherbst: :D
18:54 karolherbst: okay
18:57 karolherbst: whats a good name for the rammode for clocks higher 2.4GHz?
18:57 karolherbst: 2 sounds a bit mhhh random?
19:03 karolherbst: anything I should add or isn't good enough? https://github.com/karolherbst/nouveau/commit/28a8cac921c86e1deae7110815426b6a1754b926
19:04 imirkin: karolherbst: minor, but put the { on the line with the if ()
19:05 imirkin: in ramgk104.c
19:05 karolherbst: ohh right
19:05 karolherbst: something else?
19:06 imirkin: karolherbst: no //
19:06 karolherbst: k
19:07 karolherbst: mhh I could add a loop for P though
19:08 imirkin: also i'd just declare cur_N, cur_clk, cur_err inside the loop
19:09 karolherbst: bad thing is, I don't know the cases where P=2 yet :/
19:09 karolherbst: and I don't know how stable that will be
19:11 karolherbst: and actually I don't think its worth it, if the fN part works
19:11 karolherbst: *when
19:17 karolherbst: what I find kind of strange is, that the PLL limits table doesn't contain usefull values
19:45 marcosps: imirkin: I finially managed to boot on Fedora again in my laptop :)
19:46 imirkin: congrats
19:50 marcosps: imirkin: I'll never change it again hehe Right now I'll reinstall thinkgs here and start looking at double immediates again!
19:50 imirkin: sgtm