04:11karolherbst: Tom^: do you have some time?
04:17Tom^: karolherbst: sure do
04:17Tom^: just making coffe :å
04:21mupuf: karolherbst: i'm here :)
04:21mupuf: karolherbst: for the validation, you should do this: crit = min(crit, 125); crit = max(crit, 90); that would be more readable and would implement a CLAMP function that is easier to read
04:31mupuf: so, back to this gm206 vbios-uploading issue
04:33karolherbst: yay :D
04:33karolherbst: mupuf: well another issue: on Tom^s nvf1 card, the regs are completly useless
04:34mupuf: master enable somewhere?
04:34karolherbst: he gets badf5040 for the thresholds on the blob
04:34karolherbst: for all of them
04:34karolherbst: even crit
04:35karolherbst: also I didn't find anything usefull in the vbios
04:35mupuf: Tom^: can you please nvapeek 20000 1000 please?
04:35mupuf: oh oh, double please :D
04:35Tom^: mupuf: https://gist.github.com/anonymous/42c7be5ef4b5544130b7
04:35karolherbst: mupuf: also fermi is a bit different than kepler, but it shouldn't matter, my code works on both, just a little bit different compared to the blob
04:36karolherbst: I like those maxwell regs. All useless regs are marked as bad, that makes things easier :D
04:37karolherbst: mupuf: I guess there is no harm writing the same values back to the gpu?
04:37karolherbst: so I could just min/max the values and write them
04:38karolherbst: I could also compare old new mhhh
04:39karolherbst: Tom^: my idea was to increase the faked temp on the blob with nvaforcetemp until the clocks decrease below the min clock
04:39Tom^: didnt we do that a few days ago, wasnt it like 95C or so
04:40karolherbst: this was for driver downclock
04:40karolherbst: I meant hardware downclock
04:40Tom^: oh i see
04:40karolherbst: there can be several stages
04:40karolherbst: like 1 stage: 50% clock, 2. stage: 20% clock
04:42karolherbst: mupuf: 20798?
04:43karolherbst: would be 104°C
04:44karolherbst: Tom^: I think with nvaforcetemp 105 _something_ will happen, but this could be also a disables clocks on the gpu, which means screen freeze :D
04:44josla972: imirkin_: I have looked at the code... if I understand your solution proposal correctly we want to force uploading of program code regularly to avoid the situation where we try to store too much shader code?
04:44karolherbst: so increase by +1 and check in nvidia-settings until _something_ changes with the clocks above 95
04:44Tom^: il try it in 21 minutes then, watching gold rush. :p
04:46karolherbst: k, thanks
04:48mupuf: re, sorry, lost my internet connection
04:48mupuf: and I have been tweaking it to get a higher bitrate and lower latency
04:48mupuf:is using 3g, at 2/5 bars :s
04:49karolherbst: it usually helps to have the antenna outside
04:49karolherbst: or just switch to 2g :)
04:49mupuf: yep, but the antena is called 'my phone' ;p
04:49mupuf: 2g will be much worse
04:49karolherbst: it is fine for irc
04:49karolherbst: you should get 64kbits :D
04:51karolherbst: I have my phone always on edge and this is usually fast enough for most use cases
04:52Tom^: just make a thin foil parabol place the phone in the mid of it and once you get the right angle you might get a bar or two! :p
04:52mupuf: yep, and I will get mosh working on reator, that will solve the deconnection issues while also making everything useable over high-latency network
04:52mupuf: ilia will appreciate, I am sure
04:53karolherbst: I think everybody will :D
04:54mupuf: and I need to contact my isp over this packet loss issue
04:54mupuf: this is not acceptable
04:55mupuf: I will need to test in bridge mode
04:58mupuf: hmm, seems like I already had set it up properly
04:59mupuf: it is much better :)
05:03Digit:watching https://archive.org/details/CompromiseInFreeSoftware and feels all the greater urge to try to do triple monitor on nouveau :)
05:11Tom^: karolherbst: running a few glxspheres so i was boosting i dropped to 489mhz at 96C and 122mhz at 99C , at 100 my screens turned off. :p
05:12karolherbst: Tom^: can you do nvapeek 20000 1000 with the blob?
05:13Tom^: didnt i do so a few mins ago, i thought i pasted a gist
05:13karolherbst: was this with the blob?
05:13karolherbst: ahh k
05:13karolherbst: then oncea again after forcing 99°C
05:14Tom^: karolherbst: https://gist.github.com/anonymous/b9ace02cc852d64544e4
05:38karolherbst: mupuf: 20714 + 0x10
05:38karolherbst: 0-7: temp
05:38karolherbst: 8-11: unk
05:38karolherbst: 24-27: unk
05:40karolherbst: 92°C and 87°C seems to indicate _something_
05:43karolherbst: 00020704 could be the crit one
05:43karolherbst: seems like 20700 is an array of 10 regs which some kind of temp configuration
05:45karolherbst: Tom^: okay thanks, I think the stuff is similiar on maxwell cards
05:46Tom^: yay \o/
05:46karolherbst: mupuf: same regs are set on your nv108 card
05:47karolherbst: also on imirkins nv108 :)
05:47Tom^: why arent they keeping to some standard, imagine the code mess the blob must contain. i guess it got a bit better when they dropped pre 4xx series.
05:48karolherbst: guess why they drop support for old cards
05:48karolherbst: yep, also on nv117 cards
05:48karolherbst: even on nv12x cards
05:49karolherbst: but why not on the GK208B card :/
05:49karolherbst: because nvbios just messes up there
06:06karolherbst: mupuf: still on reator?
06:06karolherbst: but I guess you have no GK110+ card plugged in anyway
06:08karolherbst: mupuf: that's the stuff I read out from the vbios and Tom^s test, needs confirmation though: https://github.com/karolherbst/envytools/commit/46a1140bee60d1c9600e81927c50bae4f7c33a9c
07:40imirkin: josla972: not quite
07:41imirkin: josla972: so the way GL works is you set a bunch of stuff, and then you say "go"
07:41imirkin: as you're setting things, you mark stuff as dirty
07:41imirkin: when you say go, you do nv50_state_validate()
07:41imirkin: which updates the gpu with whatever was dirty
07:44imirkin: so when we're in that "validate" state, we might actually end up evicting shaders that are presently needed
08:55imirkin: gnurou: looks like the etc2 formats indeed work on gk20a :)
08:56imirkin: gonna try the astc stuff now
09:06imirkin: gnurou: http://hastebin.com/uvoricarep.xml -- when i tried astc. i'm sure i did something wrong, but the lockup seems unfortunate
09:10imirkin: ok, so it turns out that it helps to modify the *nvc0* code, instead of the nv50 code, when wanting to do things for gk20a. oops. all working now
09:59mupuf: karolherbst: looks good, but you can drop the "temperature". No point in documenting the bitfield
09:59mupuf: since there is only one value anyway
10:02mupuf: sorry for this afternoon, cousins just arrived unexpectedly
10:06karolherbst: mupuf: no, there is more in there
10:40karolherbst: mupuf: any idea what it could be?
10:41mupuf: looking at it
10:42karolherbst: sw reclock at 96 (0200025f), fsrm at 99 (01000e62), off at 100 (?00001e64)
10:42karolherbst: the off thing is weird though
10:42karolherbst: because usually it was always when you go above the value
10:43karolherbst: also there are two temperatures which are really interessting: 92 and 87, but no clue what happens there
10:46mupuf: Gosh, I hate this internet access. It is so unbelievably slow!
10:49karolherbst: shall I switch to 2g too?
10:50karolherbst: ohhh my wifi latency spikes are gone :O
10:51mupuf: It seems to depend on the protocol
10:51karolherbst: yeah I had always spikes while pinging, like 200ms+
10:51mupuf: guess what, I will try a tunnel
10:51karolherbst: mhh udp is shit over mobile :D
10:52karolherbst: mupuf: which freenode server are you using?
10:52karolherbst: ohh wait, won't help you I guess
10:54karolherbst: mupuf: maybe you shouldn't use card.freenode.net as the freenode server :/ its in the US and somehow I don't think that this would be the fastest way
10:54mupuf: irc is working fine
10:54mupuf: it is the rest
10:55karolherbst: ahhh k
10:56karolherbst: how high is your ping by the way to your ISP?
10:57mupuf: rtt min/avg/max/mdev = 42.337/65.550/106.173/20.106 ms
10:58mupuf: not too bad at all
10:58karolherbst: yeah, seems fine actually
10:58mupuf: but the throughput is ...
10:58karolherbst: well if nothing helps, phone near the window could be a _little_ bit better though
12:20karolherbst: uhh, bumblebee bug: 750M on 2880x1800..... this pcie bottleneck, I really feel that already :D
13:12imirkin: anyone with a GM107 around?
14:49RSpliet: imirkin: no sorry, I do have a large supply of tumbleweed and crickets
14:55imirkin: what did i ask for?
14:56RSpliet: people with a GM107
14:56imirkin: oh yes
15:45karlmag: imirkin: I thought about getting a 750ti, but alas, didn't..
15:49imirkin: no prob... mupuf has one, a few other people around here do too
15:49mupuf: imirkin: will be back in Finland on the 28t
15:49imirkin: mupuf: cool
15:49imirkin: i'm in no rush
16:07mupuf: imirkin: ack! IIRC, I have the GM206 and GF106 (nvcf) connected
16:08mupuf: not sure the nvcf is a GF106 though
16:17mupuf: karolherbst: at nightm everything is fine
16:17mupuf: now I get good bw
16:17mupuf: and normal latency
16:18mupuf: around 11pm it started being ok. I guess I will have to work on reator at night then. It's ok, I have work on ezbench to do that I do not need internet access for
16:22karlmag: mupuf: 950 or 960?
16:38imirkin: mupuf: well, nvcf is GF116... GF106 is nvc3 :)
17:08karolherbst: mupuf: :D sounds like normal daily network overusage
18:48poffs: how can I compensate for overscan on my hdmi TV?
18:48imirkin: oftentimes there's a setting in the tv
18:48poffs: my tv doesn't have an internal memory, so the settings reset every time the power flickers
18:48imirkin: there are also underscan properties on the display
18:48poffs: go samsung
18:49imirkin: er, on the connector
18:49imirkin: screen? i forget the X terminology
18:49imirkin: anyways, look at xrandr --props
20:26poffs: xrandr --output HDMI1 --set underscan on
20:27poffs: not working
20:27poffs: says "x error of failed request: BadName (named color or font does not exist)
20:37imirkin: that's not a nouveau-powered output name
20:38imirkin: either you failed at copy/paste, or that's an intel output
20:38poffs: i copied it from http://ubuntuforums.org/showthread.php?t=2193027
20:39poffs: i'm in man xrandr
20:40imirkin: ok, well you can't just will connector names into being
20:40imirkin: probably xrandr --output RANDOMNESS --set underscan on will also fail
20:40poffs: i can try
20:40poffs: it does fail
20:40imirkin: look at the output of xrandr to figure out the connector name
20:41poffs: i have the right output name
20:41poffs: it's HDMI1
20:41poffs: but --set underscan on is wrong
20:41poffs: if I put HDMI2, then it gives me a different error
20:41imirkin: then you're not using nouveau.
20:41poffs: since hdmi2 doesn't exist
20:41poffs: then wtf am I using?
20:41imirkin: pastebin xorg log
20:42poffs: oh. how do I get nouveau?
20:42imirkin: nouveau drives nvidia hardware
20:42imirkin: intel drives intel hardware
20:42imirkin: without a fairly powerful magic wand, it'll be difficult to convert between them
20:42poffs: this laptop likely has both integrated and discrete graphics then
20:47imirkin: looks like just the VGA output bound to the nvidia gpu
20:47imirkin: and that might be a phantom port
20:48imirkin: in which case i'd recommend booting with video=VGA-2:d which should allow nouveau to suspend your gpu, saving some battery life
20:49poffs: huh. it works in windowz
20:53poffs: any suggestions for fixing my overscan issue? I don't need the dedicated graphics as long as I can fix the overscan
20:56poffs: i was having issues installing the nvidia drivers. I suppose this is why.
20:58imirkin: i think you want #intel-gfx
20:58imirkin: not sure what they have in terms of options
20:58imirkin: xrandr --props should list it though
21:00imirkin: e.g. this is what mine look like: http://hastebin.com/ijotigivuc.sm (note the various underscan options)
21:00imirkin: but again, this is on nouveau
21:00imirkin: a diff driver will present diff options
21:01poffs: yeah I see no similar options for underscan
21:54imirkin: gnurou: ok, so i think that takes care of all the texture stuff... demmt handles all the reasonable combinations now
21:54imirkin: i have no idea what that colorkey thing is, but if you try to use it on G84+, then it won't get decoded properly.
21:55imirkin: hakzsam: so i guess i took care of the kepler tic/tsc printing thing as well :) no need to look at it, although if you have better ideas, i'm all ears
21:55imirkin: the thing i did isn't so great for a bindless situation. but it's nice for bind-ed
22:26Sleepy_Coder: hi, I have an nvidia 940m (nv118/gm108) - I'm on Arch Linux and I'm fairly certain I need firmware for this to work with nouveau. how might I get that?
22:26Sleepy_Coder: I'm not entirely sure it's supported yet, but the feature matrix on nouveau's site seems to suggest it is..
22:28Sleepy_Coder: https://wiki.freedesktop.org/nouveau/FeatureMatrix/ maybe I'm reading this wrong - no firmware is required as an extra installation step? for nv110?
22:29imirkin: Sleepy_Coder: https://bugs.freedesktop.org/show_bug.cgi?id=89558
22:30imirkin: no firmware required.
22:30imirkin: just a short patch
22:32Sleepy_Coder: imirkin: I don't know what to make of that conclusion - it says partial initialization with the patch?
22:32imirkin: mmmm... not sure what he's referring to there
22:32imirkin: but it _should_ be all you need
22:32Sleepy_Coder: so I'm just waiting for the kernel with the patch I guess
22:33Sleepy_Coder: well, the arch kernel built with nouveau with the patch
22:33Sleepy_Coder: >.> <.<
22:33imirkin: i suppose. that patch is not on its way to an upstream kernel tree atm though.
22:33imirkin: if your kernel includes that patch (very surprising) you should be good to go with nouveau, assuming it's kernel 4.1 or later
22:33Sleepy_Coder: hmm I am on 4.3.3
22:34Sleepy_Coder: I am thinking that bug is currently in limbo..
22:34imirkin: someone needs to go over the golden values the blob uses
22:34imirkin: and update any as necessary
22:34imirkin: no one capable has stepped up to the task
22:35imirkin: [in fairness, there's basically just one person who's capable...]
22:35Sleepy_Coder: who would that be?
22:35imirkin: ben, the nouveau maintainer
22:35imirkin: presently not here (vacationing i would imagine)
22:35Sleepy_Coder: well if there's a script or something to diff golden values... I wish I could run it for him XD
22:36imirkin: we have a blob trace for GM108
22:36imirkin: someone just has to go through it
22:36imirkin: i haven't the faintest clue what to look for though
22:36Sleepy_Coder: no biggie really - looks like this will be good in a month or tow
22:36Sleepy_Coder: I'm on Windows for the most part, I was just curious how the i915 + nouveau experience for weston/wayland would feel
22:36Sleepy_Coder: I've never used nouveau before this
22:36imirkin: stick to intel :)
22:37Sleepy_Coder: well the objective would be using the very fast nvidia card for offloaded programs
22:37Sleepy_Coder: i currently do use just the intel card..
22:37imirkin: yeah. i get your objective...
22:37imirkin: it just won't pan out the way you like
22:37Sleepy_Coder: oh well, like I said - I don't mind waiting a few months :o)
22:38imirkin: fast speed means fast clocks
22:38Sleepy_Coder: in the feature matrix it says some of the 3d functions are somewhat slow because of power management not being properly implemented yet
22:38imirkin: fast clocks means being able to change clocks (aka reclocking)
22:38Sleepy_Coder: is reclocking related to power management? I've always associated reclocking with overclocking
22:38imirkin: changing clocks on the fly without the world ending is a tricky endeavour, even with docs (which we don't have)
22:38imirkin: reclocking = changing clocks
22:38imirkin: overclocking = changing clocks higher than rated
22:39imirkin: these chips tend to boot up in fairly low power (i.e. low clock) modes
22:39imirkin: with nouveau you get what you get... which is unlikely to be able to outpace the intel chip
22:39imirkin: reclocking is very much a work in progress, but maxwell hasn't even been looked at, afaik
22:39imirkin: [wrt the actual clock changing scripts]
22:40Sleepy_Coder: suddenly I'm kind of looking forward to the nvidia vulkan driver :(
22:40Sleepy_Coder: ...if it ever gets here :D
22:40imirkin: too late now, but if you're looking for open source, stick to intel/amd
22:41Sleepy_Coder: yeah, I went for a hybrid setup because I wanted mobility + some gaming performance. I had been on intel-only for a while on my macbook
22:41Sleepy_Coder: is the amd experience nice?
22:41imirkin: dunno, haven't tried it since the dawn of video cards
22:41Sleepy_Coder: I have heard good things if you do not use their proprietary driver, strangely
22:42imirkin: however they have people who they pay to write open-source drivers, and those people have access to documentation
22:42imirkin: and access to hardware before it hits the market
22:42Sleepy_Coder: must be nice ;x
22:42imirkin: nouveau is in large part a volunteer thing...
22:42imirkin: although redhat does employ the maintainer of nouveau
22:43Sleepy_Coder: ahh okay - well I think I just want to idle in here then :3 is this a channel for devs mostly?
22:43imirkin: almost exclusively... with the occasional user coming in and asking questions