00:08 netz: any gentoo wizards here care to assist me with installing karolherbst's mentioned git tree?
00:10 sarnex: netz: you can just set EGIT_REPO and EGIT_BRANCH i think
00:10 netz: sarnex: oh nifty...
00:11 sarnex: depends on the ebuild tho
00:11 netz: yeah.
00:19 imirkin: netz: it's for the kernel module... what does gentoo have to do with it?
00:19 imirkin: (or do you use that genkernel insanity?)
00:19 netz: imirkin: was it? I thought it was xf86-nouveau
00:20 netz: imirkin: not yet. I do use genkernel to spin up a quick initramfs for embedding in my efistub kernel, though.
00:22 netz: other than the initramfs, its all semi-manual with localmodconfig and menuconfig
00:22 imirkin: netz: oh, was he pointing you at my tree?
00:23 netz: https://github.com/karolherbst/nouveau/tree/master_4.8 << this
00:26 imirkin: that's a kernel module.
00:26 netz: ah.
00:26 imirkin: also iirc master_4.8 in his tree == what's in kernel 4.8
00:28 netz: he had also mentioned xf86-video-nouveau 1.0.14, which I'm not seeing in emerge --search nouveau. as soon as I'm done with this emerge I'll look into the layman repo
00:29 imirkin: that's not a version that exists.
00:29 imirkin: 1.0.13 is the latest
00:30 netz: yeah, suppose so.
00:33 netz: hakzsam_ but you will need to build your own version of the DDX
00:33 netz: hakzsam_ the latest version is 1.0.13 and EXA for maxwell will be in 1.0.14
00:34 netz: it was this guy :P
00:34 netz: hakzsam_: you around?
00:34 imirkin: *will* be :)
00:35 imirkin: doubtful
00:35 netz: yeah. but then karolherbst suggested I try reclocking, so I thought I may have something I could fiddle with right now :)
00:41 netz: wooo
00:55 imirkin: gonna hold off on making a release for a while to let people test
00:56 netz: imirkin: I'd like to help in the testing :D
00:57 netz: 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2) << what I have installed :)
01:00 imirkin: go for it
01:02 netz: will do.
01:03 netz: is there any info on this particular card you need that can only be provided by an owner of this card?
01:04 imirkin: nope
01:08 netz: too old, already been reaped for info?
01:09 imirkin: among other things, i have a GM107 plugged into my box right nwo
01:11 netz: nice. as a user, how does blob vs nouveau compare?
01:12 imirkin: you should expect a small fraction of the functionality to be available on nouveau.
01:12 netz: how small we talkin? 1/10?
01:13 imirkin: depends how you weight the features
01:13 netz: in all honesty, I think the highest graphically demanding game I play is minecraft, and I've not touched that in prolly a year
01:14 netz: binding of isaac is my current poison.
01:14 imirkin: well, try it out, and see what happens
01:14 netz: will do.
01:15 imirkin: if you don't like it, you can always get a refund :p
01:15 netz: nah, I think I'll keep my reclaimed soul :)
01:16 iterati: for me the blob is not really usable, with gnome and gtx 650, after I open few programs there is massive slowdown. I wonder if it happens only to me or what. Both in arch and gentoo and multiple kernels. Maybe it doesn't reclaim used memory ?
01:17 imirkin: or buy amd and support a company that provides open-source support.
01:18 netz: imirkin: I intend to, rx480 will be the first part I purchase for my new build (because I can shove it into this box and get immediate use, unlike the other components I'm gonna get)
01:19 netz: pretty much everything else I have planned just Won'tWork™ with what I currently have :)
06:34 mupuf: 9:30, the sun is rising. Good morning everyone!
06:39 mupuf: hakzsam_: you know that the list of chipsets does should not be reorganized lightly, right?
06:40 mupuf: the goal of this list is to say what chipsets are the closest to each others, so as to maximize the chances of being able to do: GF100-GP106 for instance
06:40 mupuf: so, they need to be ordered by release date
07:03 hakzsam_: mupuf: I think I have tried all possible orders
07:03 hakzsam_: by name, wrong
07:03 hakzsam_: by chipset, wrong
07:03 hakzsam_: ...
07:04 hakzsam_: I will add a comment on top of the list :)
07:09 mupuf: hehe
07:09 mupuf: it is loosely based on the release date
07:26 mwk: it should be based on the feature list, not release date... but yeah, the order is annoying
07:27 mwk: and kind of arbitrary too
07:38 mupuf: mwk: well, feature list ... it is not like every IP is increasing its version for every new chipset
07:38 mupuf: chipset n+1 may use an older IP than chipset n
07:54 mwk: mupuf: which is why the world is a bad place.
08:27 mupuf: hehe
09:15 karolherbst: I guess since Kepler those numbers are usually marketing BS and there are no real differences technically, maybe things fused out at most
09:17 karolherbst: mupuf: wikipedia uses "ASIC-quality" as a general term for the speedo
09:17 mupuf: where did you find this?
09:18 karolherbst: wikipedia
09:18 karolherbst: also OCer talk about ASIC
09:18 mupuf: which article?
09:18 karolherbst: the overview, no reference
09:18 karolherbst: https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#GeForce_700_series
09:18 karolherbst: "Max Boost depends on ASIC quality. For example, some GTX Titan with over 80% ASIC quality can hit 1019 MHz by default, lower ASIC quality will be 1006 MHz or 993 MHz."
09:18 karolherbst: also things like that: https://www.reddit.com/r/nvidia/comments/394gb4/what_is_asic_quality/
09:18 mupuf: I see
09:18 karolherbst: seems to be the common term
09:18 karolherbst: but
09:19 karolherbst: I know why some OCer struggle with high ASIC values .D
09:19 karolherbst: :D
09:19 karolherbst: hihi
09:19 mupuf: hehe
09:20 pmoreau: hakzsam_: Are you talking about MMIO-traces or MMT ones?
09:20 hakzsam_: MMT
09:21 karolherbst: mupuf: some OC applications even have "tests" to calculate that ASIC value
09:21 mupuf: ASIC quality boils down to current leakage --> LOOL
09:21 karolherbst: :D
09:21 mupuf: ASIC quality boils down to how much voltage oyu need to reach the necessary switching timings
09:21 karolherbst: I think if I get really really bored, I troll some nvidia OC forums
09:22 mupuf: no, if you get bored, there is work on nouveau :p
09:22 karolherbst: mhhh
09:22 mupuf: let's be productive instead of bashing people's stupidity
09:22 karolherbst: boring!
09:24 karolherbst: but this weekend I have to fix that silly mmiotrace bug and look into the temperature caps on your titan again, will be interesting
09:24 karolherbst: ohh, and if the power capping depends on the temperture
09:24 karolherbst: *temperature
09:24 mupuf: well, it does because power increases
09:25 pmoreau: hakzsam_: There has been fixes pushed? I’ll have a try after lunch
09:25 mupuf: but the cap won't change, it is just the maimum frequency that will change with temperature when you limit the voltage
09:25 karolherbst: sure
09:25 karolherbst: but maybe the do crazy things with the cap too
09:25 hakzsam_: pmoreau: k
09:42 pmoreau: hakzsam_: https://phabricator.pmoreau.org/F79525 Hopefully the compression didn’t messed it up. I’ll send some more later
09:42 hakzsam_: thks
11:35 hakzsam_: imirkin: I have just added a very basic decoding support for Pascal traces in envytools
11:39 hakzsam_: skeggsb: I really need some MMT traces from your GP100, both 3D and CP to improve decoding
12:38 mupuf: skeggsb: way to go, smaller and more continuous pushes to drm-next ;)
13:20 hakzsam_: I still fail at decoding compute, but 3D/COPY work now
13:28 hakzsam_: whatever, should be good enough for now :)
13:28 RSpliet: hakzsam_: think about the pmoreau! :-P
13:29 pmoreau: RSpliet: :-D
13:29 hakzsam_: :)
13:29 pmoreau: RSpliet: I am feeding him the traces! ;-)
13:29 RSpliet: hakzsam_: but I take it your work does not touch the new IOCTLS for the latest blobs?
13:29 hakzsam_: nope
13:30 RSpliet: (which I thought required changes in valgrind-mmt)
13:30 hakzsam_: yeah, some ioctls are unknown
13:30 hakzsam_: and this might be the reason why I can't decode compute...
13:31 RSpliet: I thought they shuffled them around too
13:31 hakzsam_: but without access to the hw it's hard to write the good patch for valgrind :)
13:31 RSpliet: eg. using a newer blob on my kepler produces trace unreadable by mmt
13:31 RSpliet: *demmt
13:31 hakzsam_: which version?
13:32 hakzsam_: I didn't see that problem recently though
13:32 RSpliet: the last known working version for me at least is 367.27
13:32 RSpliet: I think I tried the one shipping with Cuda 8 (RC?)
13:32 pmoreau: I am using the latest version, 375.10
13:33 hakzsam_: I use 370 and demmt can decode the traces
13:35 hakzsam_: pmoreau: is 375 required for your gp104?
13:35 pmoreau: No, 370 should work as well I think
13:35 hakzsam_: try to downgrade? :)
13:36 hakzsam_: RSpliet: so you can't decode traces with 370 ?
13:36 RSpliet: hakzsam_: I tried it a few weeks ago with traces produced by... eh... let me find that driver version
13:37 pmoreau: Sorry, that’s a no-go. Between 367 and 375, the driver breaks my kernels. And before 367, I also need to downgrade the kernel…
13:37 hakzsam_: arf
13:37 hakzsam_: sadness
13:37 RSpliet: think it's something in the 367 series still
13:38 hakzsam_: mmh odd
13:39 hakzsam_: pmoreau: which kernel do you have btw?
13:40 pmoreau: 4.8.4
13:40 hakzsam_: same here
13:40 hakzsam_: maybe I should try 375
13:41 RSpliet: did 367.44 ship with Cuda 8? I think that was the offender for me, demmt couldn't extract much useful from traces produced from that
13:41 hakzsam_: pmoreau: 375 is not in pacman..
13:41 hakzsam_: RSpliet: no idea
13:41 pmoreau: hakzsam_: I’m on testing
13:41 hakzsam_: ah
13:42 hakzsam_: oh interesting
13:43 hakzsam_: RSpliet: you are right, I can't trace CUDA programs with 370, but compute shaders from 3D work fine...
13:43 hakzsam_: I reproduced the issue :)
13:43 hakzsam_: LOG: MSG: ==4875== Warning: noted but unhandled ioctl 0x30000001 with no size/direction hints.
13:43 hakzsam_: nice, I can try to hack something locally
13:43 RSpliet: oh that'd be fantastic
13:43 hakzsam_: not sure if I will find the issue though
13:44 RSpliet: no worries if not, I can get by with my current set-up based around 367.27 for now
13:44 RSpliet: it's an inconvenience, not a life-threatening issue :-)
13:44 hakzsam_: sure
13:45 hakzsam_: but because pmoreau cant' downgrade, I need to fix that thing for tracing compute on pascal :)
13:48 hakzsam_: mslusarz: how to figure out unknown ioctls with blob? can you give me some hints?
14:32 karolherbst: skeggsb: +1
14:33 karolherbst: uhhh
14:33 karolherbst: airlied: +1 :D
15:46 fling: Is there a regression in 4.7 affecting older cards?
15:50 imirkin_: probably
15:52 mslusarz: hakzsam_: sure
15:53 hakzsam_: cool, please explain then :)
15:54 mslusarz: ioctl id encodes command id, direction and size of a passed structure; most of the time they just changed the size of a structure and didn't even bother changing the layout - just new fields at the end
15:55 mslusarz: but if they really changed everything, then the only option is looking at the structure data and trying to match it to some existsing data, like id, classes, object ids
15:56 hakzsam_: I guess if they really chaned something it's a real pain?
15:56 mslusarz: it requires a lot of patience, but slowly you can figure out a meaning of each field
15:57 hakzsam_: k, thank you
15:57 hakzsam_: I will try to spend some time but not so much
15:57 mslusarz: just change demmt to print all unknown fields and try to match it to the rest of the command stream
15:58 hakzsam_: where can I do that?
15:58 mslusarz: demmt has decoding routine for each ioctl - just implement the ones it doesn't know about
15:59 hakzsam_: okay
16:00 mslusarz: one thing to keep in mind is that sometimes there's some data that was not recorded by mmt
16:01 hakzsam_: good to know
16:01 mslusarz: if something looks like an address in ioctl structure it's quite possible you have to write ome ioctl-specific code on the mmt side
16:02 hakzsam_: looks like not trivial :)
16:04 mslusarz: for example method call requires specific code for each "method" - take a look at handle_nvrm_ioctl_call
16:05 mslusarz: no, it's not that hard, just little frustrating at the beginning
16:06 hakzsam_: yeah, I trust you
17:23 pmoreau: Yoshimo: I just tried the technique, and it doesn’t look like it worked as I am still getting the same output filled with 0xff…
17:38 Yoshimo: pmoreau: was worth trying though
17:43 pmoreau: Yeah
17:45 pmoreau: Wasn’t there issues with XCOM on Nouveau? I thought there was a bug report, but I can’t find it.
18:03 pmoreau: karolherbst: Dunno if you saw my messages in the log, but the loop thing for getting the PMU on GM206 didn’t work.
18:05 karolherbst: uhm... let me think
18:06 karolherbst: mhh, the 4k display here has only 24Hz at 3840x2160 :(
18:06 karolherbst: or is my intel hd 4600 just bad?
18:06 karolherbst: :D
18:06 karolherbst: 30Hz didn
18:06 karolherbst: 't work out
18:08 imirkin_: that's a HSW? i think that should do 30hz ... hm.
18:08 karolherbst: mhh hdmi 1.4
18:09 imirkin_: that means nothing.
18:09 karolherbst: troublesome is, that xrandr doesn't give me the modes automatically
18:09 imirkin_: hdmi 1.4 has maximums supportable. not the max supported by a particular hw.
18:09 karolherbst: only 1920x1080 as max
18:09 imirkin_: sometimes screens don't expose the 4K resolutions by default
18:09 karolherbst: so I had to add a custom mode for 3840x2160@24
18:09 imirkin_: you may have to toggle somethin gin the OSD
18:10 karolherbst: mhh, it's a TV though
18:10 imirkin_: what 30hz modeline did you try to use?
18:10 karolherbst: what gtf gave me
18:10 imirkin_: i want to see it.
18:10 karolherbst: Modeline "3840x2160_30.00" 339.57 3840 4080 4496 5152 2160 2161 2164 2197 -HSync +Vsync
18:10 imirkin_: yeah that totally won't work
18:10 imirkin_: you need one where that second number is 297, not 339.57
18:11 karolherbst: mhh
18:11 karolherbst: 24 is Modeline "3840x2160_24.00" 266.58 3840 4048 4456 5072 2160 2161 2164 2190 -HSync +Vsync
18:11 imirkin_: in theory, hdmi 1.4 allows up to 340mhz
18:11 karolherbst: so 25 might work?
18:11 imirkin_: no, 30 will work
18:11 karolherbst: ohh I see
18:11 imirkin_: you just need different settings
18:11 imirkin_: in practice, most hw only goes up to 297mhz
18:12 karolherbst: k, so what shouldI change?
18:12 karolherbst: use a "i" mode?
18:12 imirkin_: nope
18:12 imirkin_: these things are hugely annoying to generate
18:13 imirkin_: Modeline "3840x2160" 296.70 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync
18:13 imirkin_: see what that does
18:16 karolherbst: seems to work
18:16 karolherbst: 29.97 Hz
18:16 imirkin_: cool
18:16 karolherbst: my intel is under heavy load though, totally laggy .D
18:16 karolherbst: my main display that is
18:18 karolherbst: I can set HDMI to "advanced" on the TV though
18:18 karolherbst: and normal
18:19 karolherbst: no idea what that does
18:19 karolherbst: guess I have to read a manual again
18:19 imirkin_: probably flips the 4K modeline? :)
18:19 karolherbst: nope
18:19 karolherbst: had it enabled already
18:19 karolherbst: because I thought it might be something like that
18:19 karolherbst: thing is
18:19 karolherbst: my MBP displays really weird resolutions
18:19 karolherbst: and only delivered 4:3 stuff
18:19 karolherbst: ....
18:20 karolherbst: even something like 7200x3400
18:20 imirkin_: neat
18:20 karolherbst: yeah, was as useful as it sounds
18:20 karolherbst: everything looked like 4pt font
19:30 karolherbst: the heck
19:30 karolherbst: my MBP only supports 1920x1080 through hdmi
19:30 karolherbst: allthough it's a 650m behind it
19:30 imirkin_: 650m = ?
19:30 karolherbst: nvidia
19:30 imirkin_: :p
19:30 imirkin_: looking for a chip
19:30 karolherbst: mhh
19:31 karolherbst: but the internal display is 2880x1800 already
19:31 imirkin_: kepler?
19:31 karolherbst: yeah
19:31 imirkin_: hm ok.
19:31 imirkin_: should be able to do 297MHz over hdmi.
19:31 karolherbst: gddr5 version even
19:31 imirkin_: (or 300, who knows)
19:31 karolherbst: right
19:31 karolherbst: I think I have to boot it with a live cd once
19:31 karolherbst: anc check it out
19:31 karolherbst: *and
19:32 karolherbst: mhhh right
19:32 karolherbst: no dvd drive
19:32 Yoshimo: live usb is even better, less waste
19:32 karolherbst: what I just found: http://forums.macrumors.com/threads/nvidia-gt-650m-on-rmbp-actually-better-than-nvidia-gtx-660m.1393606/
19:33 karolherbst: ohh wait
19:33 karolherbst: it would actually make sense :O
19:33 karolherbst: nvm don't read
19:34 karolherbst: mhh, it seems to support "2560x1600" as max though
19:34 imirkin_: for DVI
19:34 karolherbst: it doesn't have dvi
19:35 imirkin_: sure it does.
19:35 karolherbst: if you consider DP to be dvi
19:35 imirkin_: DP -> passive DVI, max will be 165mhz
19:35 karolherbst: ohh I see
19:35 imirkin_: DP -> active DVI, you can get dual-link, 330mhz
19:35 karolherbst: I see
19:35 imirkin_: i forget what 2560x1600 works out to
19:36 imirkin_: hm. ~270MHz
19:36 karolherbst: anyway, it sounds like crap to me what this mbp supports
19:38 karolherbst: ohh, nice, somebody seems to have gotten it to work, reading: http://blog.fosketts.net/2015/11/09/how-to-connect-a-4k-monitor-to-a-2012-retina-macbook-pro/
19:39 karolherbst: mhh, meh, tomorrow I look into it again
20:29 imirkin_: karolherbst: why would cstate selection be pointless?
20:41 karolherbst: imirkin_: because you either want the highest working or dynamic reclocking
20:41 karolherbst: why would you want to select from a list of many?
20:42 karolherbst: it might be useful for debugging, but for the end user it's useless
20:42 imirkin_: i dunno, maybe the card gets too hot at the highest cstate?
20:42 karolherbst: for that you have boost=0
20:42 imirkin_: or, on my GM107, the higher pstate can actually select lower cstates :)
20:42 karolherbst: boost=0 guarentees to never go beyond the power budget
20:42 karolherbst: imirkin_: with my patches?
20:42 imirkin_: just in general
20:42 imirkin_: there are 2 perf levels
20:43 karolherbst: well, if my patches didn't fix that
20:43 imirkin_: one has a fixed cstate
20:43 imirkin_: the other has a range, which goes higher (obviously) but also lower
20:43 karolherbst: let me check
20:43 karolherbst: ohh right, 7 has 405MHz
20:44 karolherbst: f has 270 to max
20:44 karolherbst: nvidia would clock to 270 on 7 though
20:44 karolherbst: due to this: "0: pstate 7 min 270 MHz max 810 MHz"
20:44 karolherbst: even if there is no cstate, nvidia clocks down
20:44 imirkin_: ah
20:44 imirkin_: tricksy
20:44 karolherbst: on mine nvidia clocks to 135MHz
20:44 karolherbst: allthough the lowest cstate is 405MHz
20:45 karolherbst: but it is pretty much pointless, cause the voltage stays the same
20:48 karolherbst: anyway, we have the NvBoost boot config to somehow cap the max clock and this should be good enough for 99% of all cases
20:48 karolherbst: and because we default to 0 now, we even get lower clocks on already reclockable gpus, so heat/power is a smaller issue
21:16 pmoreau: Hum… Do we really want to have "(supported cards)" next to "General code names" on the CodeNames page of the wiki?
21:17 pmoreau: In which case we should not be adding GPUs as soon as they are released.
22:02 karolherbst: pmoreau: it only causes confusion