00:41 mlankhorst: that's not guaranteed to work right except with texture barrier?
06:48 robclark: skeggsb, imirkin, btw I don't' suppose something like this is a known issue: https://prabhugs.wordpress.com/tag/hub_init/ .. some different guy in #fedora-workstation is having a very similar issue (with I think the same laptop)..
06:48 robclark: http://fpaste.org/198944/
06:48 robclark: (trying to get traces from when nouveau.ko is loaded right now in case that gives some hint)
07:01 robclark: http://fpaste.org/198952/
07:04 robclark: is this something to worry about: ACPI Warning: \_SB_.PCI0.PEGP.DGFX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95)
07:10 pmoreau: robclark: It's not. ACPI requires a package, but old ACPI tables takes a Buffer instead.
07:11 pmoreau: Following the specif was too much trouble
07:11 imirkin: robclark: HUB_INIT timed out... yeah, known issue, very annoying, no solution atm
07:11 robclark: ahh
07:11 imirkin: robclark: skeggsb was looking into it the other day... not sure how much progress he made
07:12 robclark: don't suppose there is already a bz somewhere that I can point this guy at to follow the action?
07:12 imirkin: robclark: it's a timing issue, and somehow we're unable to upload the firmware
07:12 imirkin: robclark: https://bugs.freedesktop.org/show_bug.cgi?id=70354
07:13 robclark: hmm... where he actually seems to hit the issue is later when userspace creates a context..
07:13 robclark: thx
07:13 imirkin: robclark: coz... it's optimus, gpu is powered down until it gets used
07:13 imirkin: robclark: you can disable all that with nouveau.runpm=0
07:14 robclark: oh.. right
07:14 pmoreau: imirkin: It doesn't get power down it seems
07:14 pmoreau: There is no "Optimus decteced" or similar in the logs
07:15 imirkin: pmoreau: does that always get printed?
07:15 pmoreau: It should
07:15 pmoreau: let me check
07:16 pmoreau: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nouveau_acpi.c#n290
07:17 imirkin: interesting.
07:17 pmoreau: robclark: I could had some basic support for auto-suspend if I have the ACPI tables for that laptop
07:18 pmoreau: I need to finish patches for supporting two different MBPs
07:18 imirkin: wait a second... robclark, that dmesg doesn't seem to indicate optimus
07:18 robclark: pmoreau, ahellquist|work is the one with the laptop (fyi)
07:18 robclark: ahellquist|work, <pmoreau> robclark: I could had some basic support for auto-suspend if I have the ACPI tables for that laptop
07:19 imirkin: i had only seen the issue on optimus setups. but the issue is the same -- GR is super-powered-down, and we're not powering it up properly. or something.
07:19 robclark: pmoreau, btw, in his log I don't see either of those vga switcharoo msgs.. either the optimus one or non-optimus..
07:20 ahellquist|work: imirkin: optimus=yes
07:20 pmoreau: robclark: Right, there is no vgaswitcheroo msg. But I would expect an i7-4710MQ to have a GPU die
07:21 robclark: right.. but I don't see any i915 in the log so I guess sitting there disabled?
07:21 imirkin: ahellquist|work: i don't see i915 get loaded...
07:22 ahellquist|work: let me check my bios settings
07:23 ahellquist|work: Hybrid Graphics = Disabled (possible values, Enable, Disable, Auto)
07:23 pmoreau: :)
07:24 ahellquist|work: pmoreau: what's fun ? Would enable or auto improve my situation ?
07:25 imirkin: very unlikely
07:26 ahellquist|work: imirkin: i thought so
07:26 pmoreau: But it explains why vgaswitcheroo doesn't kick in
07:26 imirkin: right
07:26 pmoreau: Wouldn't disabling the NVidia and relying on the Intel avoid the time out issue?
07:27 ahellquist|work: according to HP, the laptop senses if one is installing a linux os and changes the bios hybrid setting.
07:28 ahellquist|work: pmoreau: according to HP, there is no way to disable the nvidia part. disable means Nvidia only, auto means auto and enable means optimus enable..
07:28 imirkin: ahellquist|work: if you enable optimus, you'll end up mostly using intel, which should work fine
07:29 imirkin: ahellquist|work: you won't be able to offload using nouveau due to the fact that it can't power up the GR component, but you'd still be able to use reverse PRIME to display to any screens that end up direct-attached to that GPU
07:29 ahellquist|work: imirkin: ok, I could try that. should I be mostly fine with just enable hybrid or am I affected by other bugs ?
07:30 imirkin: ahellquist|work: only one way to find out ;)
07:30 ahellquist|work: I really just need working grapics and have no need for performance or PM at this time
07:30 ahellquist|work: :)
07:30 imirkin: the intel gpu should suit your needs then
07:31 imirkin: the nvidia gpu should auto-power-down when not used
07:31 imirkin: (which it won't be, unless you plug in a secondary screen that is connected directly to it)
07:31 pmoreau: If it doesn't, ping me and I should be able to write some patch.
07:32 ahellquist|work: pmoreau: changed to enable and rebooting. will report back the progress
07:32 pmoreau: (I won't be able to write tha patch right now though :) )
07:33 ahellquist|work: pmoreau: no proble
07:33 ahellquist|work: m
07:34 pmoreau: I need to find out what the functions defined in the _DSM method are for, but even if I don't call them, my NVidia cards goes to sleep nicely.
07:34 pmoreau: So, if it's the same on your laptop, writing the patch will be pretty straight forward
07:34 ahellquist|work: new boot gives med cpu hard lockups..
07:35 pmoreau: :/
07:36 ahellquist|work: pmoreau: it starts with cpu lockups and the keep throwing trace dumps for wifi and various other things..
07:37 pmoreau: You could try netconsole to get the boot logs out on another computer.
07:39 ahellquist|work: pmoreau: yep, I will soon have to go offline but tomorrow I can save the boot log and post it. Is this the prefered way to run this laptop. Optimus enable and hunting down this lockup. Should I provide info from other scenarios too ?
07:40 pmoreau: Ok. Optimus would be the preferred way to run the laptop (if they were no issues), as you could run on the Intel card and have better battery life, and if you need more performance at some point, use the NVidia card.
07:40 pmoreau: Not sure what information could be needed.
07:40 pmoreau: imirkin: I guess for the HUB_TIMEOUT we already have enough information?
07:41 imirkin: pmoreau: not really, but i don't know what information we'd need
07:41 tobijk: there is a bug open for that
07:41 pmoreau: tobijk: True
07:41 imirkin: ahellquist|work: try booting with nouveau.modeset=0
07:41 imirkin: that should disable nouveau *hard*
07:41 tobijk: just gather the info there...
07:42 ahellquist|work: imirkin: right now or would i need netconsole for useful info ?
07:42 pmoreau: ahellquist|work: You should add yourself to the CC list on that bug. That way if Ben needs more information, you'll receive his request.
07:42 pmoreau: It will disable Nouveau, should be fine without netconsole
07:42 hotwings: hi. last time i was in here (quite a while ago), i was told nouveau likely wouldnt support vdpau. now im told it does if you use a firmware ripped out of the nvidia driver. if this is true, are _all_ the hw decoding features available? more specifically the deinterlacers and so on?
07:42 ahellquist|work: pmoreau: I am looking for the bug and will add to cc
07:43 imirkin: hotwings: deinterlacer is not a hw feature
07:43 pmoreau: The link was posted a bit earlier
07:43 imirkin: hotwings: there is a temporal deinterlacer in the mesa vdpau library, but no temporal_spatial
07:43 pmoreau: ahellquist|work: https://bugs.freedesktop.org/show_bug.cgi?id=70354
07:43 imirkin: hotwings: however from personal experience, the temporal one is *more* than sufficient
07:43 ahellquist|work: pmoreau: thanks
07:43 imirkin: hotwings: http://nouveau.freedesktop.org/wiki/VideoAcceleration/ shows what's supported
07:44 hotwings: imirkin - are you saying nvidia cards do temporal-spatial deinterlacing in software rather than hardware?
07:44 imirkin: hotwings: they use shaders to post-process the images
07:44 imirkin: sort of hardware, sort of software :)
07:45 hotwings: i see no mention of deinterlacers at that url.. but you already said no temporal-spatial so thats a deal-breaker. looks like nouveau will remain blacklisted here so nvidias driver loads :) :\
07:46 imirkin: hotwings: ok. like i said, the deinterlacing has nothing to do with nouveau, hence no mention on that page
07:47 hotwings: you meantioned mesa vdpau library. i guess it would be up to them to figure out how to access it? sorry, i dont really know how this stuff works
07:48 imirkin: hotwings: well, it's a shared component. the vdpau state tracker drives the video decoding hw, and applies post-processing
07:48 imirkin: it has a temporal deinterlacing shader, but no temporal-spatial deinterlacing shader
07:48 imirkin: (it's more complicated, the temporal one tends to be sufficient, and i guess no one was interested in adding it)
07:50 imirkin: hotwings: if it's something that you'd be interested in adding, you're obviously more than welcome to :)
07:50 ahellquist|work: imirkin: nouveau.modeset=0 made the laptop boot without errors. will check if grapics work but needs to change the system to gui-mode
07:51 imirkin: ahellquist|work: should work fine -- your intel gpu should be driving the display
07:52 ahellquist|work: imirkin: really nice. I will provide the optimus boot log tomorrow anyway so you can hunt down the bugs.
07:53 imirkin: ahellquist|work: yeah, having it panic on boot is not great... i don't think that's a known issue...
07:53 imirkin: ahellquist|work: often if you boot with modeset=0, you can unload the module, and reload it later on. you'll get a crash, but you'll be able to see it since the system will already have been booted up
07:55 ahellquist|work: imirkin: ok
07:56 fbe^: hi, i have a quadro k3100m (dell preciion m6800). when loading nouveau while the xserver i running with the intel driver the power saving of VGA_SWITCHEROO works well, the drivers stops the nvidia card.
07:56 fbe^: but when i put the system in suspend to ram and resume it, it works for about 3 - 4 seconds and then it starts to hang
07:57 fbe^: starting the x with nouveau only causes no screens found. i want to create a bug report for the hang problem / see the output of dmesg. do you know if it's possible to activate netconsole over ethernet while the system is running?
07:59 fbe^: http://nopaste.linux-dev.org/?450854 thats the output from loading nouveau while the xserver is running
08:00 imirkin: fbe^: same HUB_INIT timeout issue as ahellquist|work is having
08:01 fbe^: does a bug report exist where i can contribute data too?
08:02 imirkin: fbe^: i suspect you might have multiple issues, or are hitting a funky edge-case of an issue...
08:02 imirkin: are you trying to use nouveau for anything, or is it just there to suspend the nvidia gpu?
08:03 hotwings: imirkin - sorry, was away from the pc for a minute.. the deinterlacers sound more involved than i thought. id more be than happy to add it if its something a non-coder can do
08:03 imirkin: hotwings: if it were something trivial, it would have been done a long time ago... generally the lowest-hanging fruit gets picked :)
08:04 hotwings: im surprised it hasnt been added by now considering how popular nvidias stuff is for htpcs
08:04 fbe^: imirkin: i'm just trying to suspend the nvidia card
08:05 fbe^: with no VGA_SWITCHEROO + nouveau my machine is consuming ~ 10 more watts
08:05 imirkin: hotwings: i think it's considered unnecessary. perhaps you should give the plain temporal deinterlacer a shot.
08:06 fbe^: disabling vga_switcheroo works, too. but that doesn't save the power as good as with this option enabled
08:06 imirkin: hotwings: or there is no intersection between the people that consider it necessary and the people that have the {time,skill,desire} to add such a contraption.
08:06 imirkin: fbe^: right, you need switcheroo (+ runtime_pm) for nouveau to be able to shut the thing off
08:06 imirkin: fbe^: so your issue isn't that nouveau accel isn't working, it's that your box hangs on resume?
08:06 fbe^: sadly it doesn't even work with the proprietary nvidia blob :(
08:07 fbe^: imirkin: yep
08:07 fbe^: but i guess it's nouveau related.. and i'm currently not able to get any debug output..
08:07 imirkin: fbe^: netconsole would be great...
08:07 fbe^: systemd causes my interfaces to be called like enp8s0 instead of eth0
08:07 imirkin: fbe^: you can boot with e.g. netconsole=@,@ console=ether
08:07 fbe^: do you know if i have to use enp8s0 for netconsole too?
08:08 fbe^: or do i still have to use the old mapping with eth0?
08:08 imirkin: no, but i know how to fix systemd to not do that dumb shit
08:08 fbe^: ok, then i'll at first try to get my old ethernet mappings back - i can remember that there was a boot option for that purpose
08:08 pmoreau: You shouldn't as netconsole should setup before the renaming occurs
08:08 imirkin: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
08:09 imirkin: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
08:09 imirkin: those fixed me right up (i only use systemd-udevd though)
08:09 hotwings: imirkin - aside of the deinterlacers, what about the scaling? ive heard nvidias is great. does mesa support the nvidia scaling?
08:09 fbe: okay =) i'll try to setup it. brb
08:09 imirkin: hotwings: not sure what you're referring to... i think these are all just shader postprocessing features
08:10 imirkin: hotwings: the mesa vdpau impl doesn't expose any of the "HIGH QUALITY SCALING - L1" type stuff, but tbh, not sure what that does in the first place
08:10 imirkin: fbe: watch out though -- if your other init scripts/etc expect the crazy names, it'll break that :)
08:27 hotwings: imirkin - im sure its useful for people who upscale to match their tv resolution
08:27 hotwings: really any video scaling so i guess people who use computer monitors are included
08:27 imirkin: hotwings: i think the regular scaling works fine in most situations :)
08:28 imirkin: i know i've never noticed any issues, and i tend to be pretty picky
08:32 hotwings: are you using a 60" & 70" like i do? the bigger the screen, the bigger the difference makes
08:33 imirkin: nope. but you also haven't tried it with nouveau.
08:34 hotwings: true indeed. maybe i should just to see for myself as long as its not too involved or bring in any dependency hell
08:34 imirkin: which gpu do you have btw?
08:36 fbe: thats really strange. i'm receiving netconsole events now. but only small subsets of the stuff appearing in dmesg
08:36 fbe: what could be the reason for that?
08:36 imirkin: fbe: dmesg -n 10
08:38 fbe: unknown level 10
08:38 imirkin: 8?
08:38 fbe: netconsole gave only one line O_ O
08:38 imirkin: i don't remember these things :)
08:38 fbe: while booting..
08:38 imirkin: fbe: console=ether i think
08:49 fbe: ok, netconsole debugging doesn't work
08:50 fbe: http://paste.coding4.coffee/?900738f1c251bf1b#FJakVR3IOh6ITdfNpcVDkp1cALCqD3aFwTWk1FLGBRM= thats the output while going to standby
08:51 fbe: i don't get any output when resuming from standby via netconsole, but i was able to make a "screenshot" of dmesg ~ 1 second before the machine finally froze
08:52 fbe: http://i.imgur.com/GHWfKci.jpg thats the output i got after suspend before the machine finally froze
08:52 fbe: does this output help?
08:54 fbe: https://bugs.freedesktop.org/show_bug.cgi?id=54521 looks like my bug
08:55 pmoreau: gen7, gen6 prefixed functions could be Intel ones
08:55 imirkin: oooh, fun, might not be a nouveau issue afterall!
08:55 pmoreau: Ah right, just saw the bug report you linked
08:55 imirkin: fbe: maybe pop over into #intel-gfx and see if they might help?
09:01 fbe: whoh
09:02 fbe: i915.i915_enable_rc6=1 as kernel opt seems to help
09:03 fbe: i'll ask in #intel-gfx, thanks!
09:05 mlankhorst: imirkin: ugh present is still a mess :P
09:06 mlankhorst: it looks like it will fall apart with more than 1 crtc..
09:06 mupuf: ...
09:06 mlankhorst: indeed!
09:07 mupuf: yo uwant to use DRI3 to use the render nodes and dmabuf, right?
09:08 mlankhorst: I want to use present for tegra to make vblank work at all..
09:14 hotwings: imirkin - sorry, was away from pc again. my cards are all gt430 and 520gt
09:20 imirkin_: hotwings: ok cool. those should be pretty well supported (VP4.2)
09:20 imirkin_: fbe: that's weird, i thought rc6 was on by default
09:21 hotwings: yeah, theyre not the newest by any means. cheap & works great for an htpc
09:21 imirkin_: hotwings: well, if you had a G92, that one's reported to hang when trying to do video decoding for example
09:26 hotwings: thats all my cards do all day
09:26 hotwings: theyre all in dedicated htpc's that run 24/7 :)
11:10 mlankhorst: arghhh
11:10 mlankhorst: Running synchronized to the vertical refresh. The framerate should be
11:10 mlankhorst: approximately the same as the monitor refresh rate.
11:10 mlankhorst: 863 frames in 5.0 seconds = 172.510 FPS
11:10 mlankhorst: :(
11:10 imirkin_: nice monitor!
11:10 mlankhorst: still... no crash at least
11:11 imirkin_: are you sure that tegradrm properly supports vblank?
11:11 imirkin_: e.g. what happens if you use llvmpipe?
11:12 mlankhorst: it runs the modesetting driver, flip doesn't work :P
11:12 imirkin_: so not a whole lot that nouveau can do about that right?
11:12 mlankhorst: no idea
11:12 mlankhorst: I'm running a slightly patched version
11:13 mlankhorst: of xorg-server
11:13 imirkin_: are you sure tegra drm doesn't support vblank counters or whatever's required for this?
11:13 mlankhorst: hm unless I'm mistaken the glxgears should be garbled..
11:13 mlankhorst: oh well, I'll test in a moment
11:13 imirkin_: hm?
11:13 imirkin_: garbled?
11:14 mlankhorst: hm but that should only happen on fullscreen
11:16 imirkin_: ?
11:20 mlankhorst: glxgears should use tiling probably
11:20 mlankhorst: so if it flips it will show a tiled pixmap
11:21 imirkin_: exported bo's should be linear...
11:22 mlankhorst: weird
11:23 mlankhorst: goes from 4 fps back to 150 or so..
11:23 mlankhorst: not sure why all of a sudden
11:24 imirkin_: coz you went from 1080p to 100x100?
11:24 mlankhorst: no
11:25 mlankhorst: same glxgears run
11:30 mlankhorst: hm I should figure this one out, enable debugpresent probably
11:31 mlankhorst: it's a bit tricky because there are 2 screens involved
11:31 mlankhorst: so maybe it gets confused :p
12:20 specing: weird
12:20 specing: when I press the brightness up/down buttons on keyboard, the brightness changes two steps at once
12:28 RSpliet: once enforced by ACPI, once because your DM signals it?
12:31 mjg59: specing: Set /sys/module/video/paramters/key_switch to 0
12:31 mjg59: Sorry
12:31 mjg59: Set /sys/module/video/parameters/brightness_switch_enabled to 0
12:34 specing: mjg59: yeah that restores normal behaviour
12:35 mjg59: specing: Cool
12:45 imirkin_: skeggsb: if airlied hasn't pulled yet, perhaps add some stable tags to the commits you pushed to nouveau/lniux-2.6#linux-4.0 ?
12:45 imirkin_: i'm thinking the fifo fix at least... maybe the endian one too
12:45 imirkin_: although that one's less of a thing
12:46 mjg59: specing: I keep meaning to file a patch to provide a config option for that
12:48 specing: mjg59: config? What config?
12:48 specing: Xorg config?
12:50 mjg59: specing: Kernel config
12:51 imirkin_: mjg59: seems like whatever software ends up listening to the acpi events should also disable that toggle...
12:51 mjg59: imirkin_: Difficult
12:51 mjg59: It's fucking dreadful API
12:51 imirkin_: coz it's acpid + random script?
12:52 mjg59: Often
12:52 nv7300gs: how can i force nouveau to enable an monitor?
12:52 mjg59: Having the kernel automatically respond results in hilariously broken assumptions
12:52 imirkin_: in that case, the random script could force disable the thing every time, and the first time it'll switch 2 levels but wtvr
12:52 imirkin_: nv7300gs: xrandr --output foo --auto
12:53 mjg59: Like, whether your desktop needs to do something depends on which backlight device you have
12:53 nv7300gs: also then, when i thinks by itself, that there is no monitor connected to
12:53 imirkin_: nv7300gs: if it thinks there's no monitor, you can't "force" it to turn it on
12:53 nv7300gs: imirkin_: can i use kernel setting video=..... ?
12:53 imirkin_: nv7300gs: sure... you can say like video=DVI-I-1:e or something
12:53 imirkin_: i forget exactly... rtfm?
12:54 imirkin_: nv7300gs: but afaik that won't help you at all.
12:54 nv7300gs: video=DVI-I-1:1920x1200@60 have not worked
12:54 imirkin_: nv7300gs: i think that your dcb table is messed up, and no amount of video= options will fix that
12:55 nv7300gs: what helps to get able to use 1920x1200@60 with vga cable like possible on binary driver is setting video=TV1-I:1920x1200@60
12:56 imirkin_: nv7300gs: you opened a bug for your issue with your vbios, right?
12:56 nv7300gs: imirkin_: right
12:56 imirkin_: nv7300gs: can you add the output of 'lspci -vvnn -d 10de:' to it?
12:57 imirkin_: nouveau has some logic fixing up various stuff, nice to see your pci ids to see if it's already being matched
13:01 nv7300gs: imirkin_: done: https://bugs.freedesktop.org/show_bug.cgi?id=89571
13:01 imirkin_: thanks
13:02 nv7300gs: would be nice if i can help somehow to fix that for kernel 4.0 :)
13:04 imirkin_: nv7300gs: are you a developer?
13:04 nv7300gs: nv7300gs: no, not really
13:04 nv7300gs: imirkin_: no, not really
13:05 imirkin_: ok, then it may be tough... basically you have to try to understand what the current code is doing, compare it to your vbios, and see where it's going wrong
13:05 imirkin_: iirc you're getting 2 TV encoders and DVI instead of DVI + VGA + TV?
13:05 imirkin_: that likely means that all sorts of things are messed up
13:06 nv7300gs: VGA means TV1 here. yes
13:06 imirkin_: although what's really surprising is that your VGA works with nouveau thinking it's a TV encoder
13:06 imirkin_: perhaps it really is a TV encoder doing RGB-style encoding, which is _basically_ VGA
13:07 nv7300gs: yea, i remember this 3 separate cables on some old monitor
13:07 imirkin_: well, "component video"
13:08 imirkin_: and before that there was the SGI/DEC 13w3 connector
13:08 imirkin_: which was amusingly plug-compatible but they switched the meaning of some pins around
13:08 imirkin_: and there's also the "BNC" video connectors which are more along the lines of the "component video" that came later
13:08 nv7300gs: what could i provide you to get this somehow fixed?
13:09 nv7300gs: i remember this BNC video connectos too :)
13:09 imirkin_: er, not DEC... SGI and SUN both used 13w3 iirc. it was all so long ago :)
13:10 buhman:farms out brain cycles to imirkin_ so he can fix gk106
13:11 imirkin_: buhman: i doubt that even at 100% capacity our 2 brains could work it out
13:11 buhman: welp
13:11 imirkin_: i dunno. maybe eventually. would have to dedicate a day or two with the relevant hw to hack on it
13:12 imirkin_: which ain't gonna happen anytime soon
13:13 RSpliet: pmoreau: thanks for the trace
13:13 RSpliet: erm... don't try reclocking just yet on your G96 :p
13:17 nv7300gs: skeggsb: would be nice if you have an idea how to fix the bug: https://bugs.freedesktop.org/show_bug.cgi?id=89571
13:18 pmoreau: RSpliet: Why not? :(
13:18 RSpliet: 1) I don't touch GPIOs yet to change voltages
13:19 xexaxo: imirkin, nv7300gs: I'd assume a very verbose output of Xorg.log and/or mmio trace of the blob will help.
13:19 RSpliet: 2) 100da0 needs to be included for 0x96
13:19 imirkin_: xexaxo: things go wrong way before xorg
13:19 xexaxo: without that info it's random guessing.
13:19 RSpliet: 3) Timings.. not sure yet
13:19 pmoreau: What's 100da0?
13:19 imirkin_: RSpliet: 100da0 == gddr3 iirc
13:19 xexaxo: imirkin_: with the blob or nouveau ?
13:19 imirkin_: xexaxo: nouveau
13:20 RSpliet: imirkin_: 100da0 is >750MHz, not seen very often with DDR2
13:20 xexaxo: imirkin_: I was talking about the blob.
13:20 imirkin_: RSpliet: hmmmm.... are you sure that's right?
13:20 nv7300gs: xexaxo: how can i provide this "very verbose output of xorg"?
13:20 RSpliet: imirkin_; I know it's right on NVA3+
13:20 RSpliet: I'll verify when I get there
13:20 imirkin_: RSpliet: iirc 100da0 is set *based* on frequency, but only on some boards
13:20 pmoreau: It's unknown according to Envytools
13:21 imirkin_: RSpliet: and the rest of boards get the same values set in 100750 or so
13:21 imirkin_: (and by "same" i mean... same idea, diff actual content)
13:21 pmoreau: Titan X or Blaise?
13:21 RSpliet: imirkin_: I'm too foggy to actually think, I was just skimming through that trace
13:21 imirkin_: pmoreau: do you have ddr2 or 3 hanging off that board?
13:22 pmoreau: it's gddr3 memory
13:22 imirkin_: iirc i never worked out which boards needed which register set. it was either ddr2 vs gddr3, or a generation-based cut off
13:22 xexaxo: nv7300gs: that I was talking about getting some info from the blob.
13:22 imirkin_: i didn't have enough samples of various traces to tell
13:22 RSpliet: imirkin_: likely a combination of both
13:23 xexaxo: nv7300gs: X has some -verbose [n] -logverbose [n] options. I've never had fun with them.
13:23 imirkin_: nv7300gs: xexaxo is talking about doing a mmiotrace with nvidia blob drivers btw, in case that wasn't clear. not with nouveau.
13:23 pmoreau: Let's hope we will get firmwares for Maxwell before Blaise comes out
13:24 imirkin_: probably Pascal? :p
13:24 nv7300gs: imirkin_: okay. if i knew how to somehow make them with a liveUSB system, i would love to give them to you :)
13:25 pmoreau: Hum... Not sure which one I'd prefer between both
13:25 pmoreau: Blaise is faster to type though ;)
13:25 buhman: nv7300gs: https://wiki.ubuntu.com/X/MMIOTracing ?
13:25 pmoreau: s/faster/shorter
13:30 nv7300gs: thanks
13:34 imirkin_: titan x is out apparently... GM200
13:34 imirkin_: skeggsb: did they send you one of those? :) if not, i'm guessing it'll take _quite_ a while before someone tries it on nouveau
13:38 pmoreau: Depends if the team I'm doing my internship at decides to buy one. Maybe I could do some tests on it.
13:39 imirkin_: well, it'd only be able to do modesetting
13:39 pmoreau: Right
13:40 pmoreau: Would there be something to test on the Titan?
13:41 imirkin_: just bringing up modesetting on it :)
13:42 pmoreau: I mean Titan, the old one, not the Titan X
13:42 imirkin_: ah... GK110?
13:42 imirkin_: that one should work fine afaik
13:43 pmoreau: It seemed to, for the few minutes I spend using Nouveau on it.
13:43 pmoreau: Which other family is supposed to have reclocking, besides Tesla?
13:44 imirkin_: kepler
13:45 imirkin_: and nv4x :)
13:45 pmoreau: Ok, thanks
13:45 imirkin_: reclocking should work on the titan... subject to the usual gddr5 highest-level caveats
13:45 pmoreau: :)
13:46 pmoreau: I'd love to run Nouveau for my work, but I need to use Cuda.
13:46 imirkin_: and even if you didn't, nouveau doesn't do opencl
13:47 pmoreau: Right
13:47 koz_: Which NVIDIA card is best in terms of proprietary-nouveau performance parity?
13:48 imirkin_: koz_: low-end kepler card (with GDDR3 vram) which you can reclock to maximum speed
13:48 koz_: imirkin_: So any low-end Kepler will do?
13:48 imirkin_: koz_: like a GT640 or something
13:48 koz_: Ah.
13:48 koz_: Cool, thanks.
13:49 imirkin_: koz_: if you're trying to max performance, chances are e.g. a GTX 760 at the middle level will still be faster than a GT 640 at the highest level
13:49 koz_: I see.
13:49 koz_: The 760 will reclock though, right?
13:49 imirkin_: dunno what your budget/needs are
13:49 imirkin_: yeah, to the middle level... i think phoronix dod some benchmarks
13:50 koz_: imirkin_: It's more of an exploratory thing really.
13:50 Karlton: I seen the 650 reclocked all the way on the phoronix site
13:51 imirkin_: koz_: http://www.phoronix.com/scan.php?page=article&item=nvidia_nouveau_2014&num=2
13:51 koz_: imirkin_: Thanks!
13:51 imirkin_: Karlton: yeah
13:52 imirkin_: koz_: here's one that includes the GTX 650 in question: http://www.phoronix.com/scan.php?page=article&item=nouveau_linux318_blob&num=2
13:52 koz_: imirkin_: Thanks again. My 650 is non-reference though, so it won't reclock correctly. :(
13:52 imirkin_: i suspect the GTX 650 had gddr3 vram. or he got really lucky.
13:54 Karlton: imirkin: my GTX 650 ti sc is GDDR5 and doesn't reclock all the way :(
13:54 Karlton: so must by only the plain or early version of the 650
13:54 imirkin_: Karlton: yeah, there are a ton of variants...
13:55 imirkin_: Karlton: it also depends on the specific memory chips being used
13:55 imirkin_: reclocking memory is a bit of a bitch... a lot of parameters you have to get 100% right, or else everything dies
13:55 imirkin_: and no documentation on how to figure out what "right" is
13:56 koz_: imirkin_: Yep, NVIDIA are jerks.
13:56 imirkin_: meh, not really -- they have their priorities.
13:57 imirkin_: and the nvidia people who hang out in this channel tend to be generally nice people. although with limited ability to affect the company's position on documentation availability.
13:58 koz_: Well, I'm not saying any particular individual NVIDIA employee is a bad person. I just think not sharing documentation is a bit of a dick move.
13:58 imirkin_: yeah. but sadly the standard in the industry.
13:59 imirkin_: anyways, looks like clock-for-clock, nouveau performs at about 80% of blob fps
13:59 imirkin_: which is surprising given that we don't do *any* instruction scheduling
13:59 imirkin_: i figure that's worth an easy 10% in perf
13:59 imirkin_: well.. "easy"
14:00 imirkin_: [and obviously nouveau's GL driver is still stuck in the GL3 dark ages... but GL4 should work Real Soon Now (tm)]
14:01 pmoreau: How much is "Real Soon Now"? :)
14:01 imirkin_: i bet GL4 will be a thing before the end of the year
14:01 imirkin_: maybe even GL 4.2
14:01 imirkin_: 4.3 is more doubtful
14:02 imirkin_: GL4 is missing tess and subroutines. i bet tess core will land in a month, and nouveau should follow soon
14:02 pmoreau: Oh, I was thinking GL4 for this summer :D
14:02 pmoreau: Nice! :)
14:02 imirkin_: and then subroutines will be the last extension left, which means that *someone* will step up and implement it
14:02 imirkin_: hopefully not me
14:03 tobijk: :P
14:03 pmoreau: On the Nouveau side, it will probably be you :)
14:03 imirkin_: i prefer to leave the core work to people who are paid for it :)
14:03 pmoreau: Even if tobijk and RSpliet do contribe often
14:03 imirkin_: there won't be a nouveau side of subroutines
14:03 pmoreau: Oh, nice for you then! :D
14:03 tobijk: not often enough i fear :/
14:04 RSpliet: imirkin_: is insn sched the bottleneck for nouveau you think? there's also bus speed adjustment and who knows what is missing in memory bus init that could gain sth extra?
14:04 tobijk: feeding them into the ir only? or nir later on?
14:04 imirkin_: RSpliet: it's *a* bottleneck
14:04 imirkin_: among other things, we're not taking advantage of dual-issue
14:05 imirkin_: tobijk: it'll start out as a glsl ir-level feature. could add backend support for it, but not enough motivation for anyone to care.
14:08 RSpliet: imirkin_: sure, but your wording implied between the lines that insn sched accounts for the bulk of the performance gap
14:08 RSpliet: and I was curious why you think this might be... :-)
14:08 imirkin_: RSpliet: tbh i haven't a clue how much perf can be squeezed out of it
14:08 RSpliet: fair enough
14:08 imirkin_: however i suspect it's an easy single thing to do that will be able to produce a big bump
14:09 RSpliet: for certain values of easy
14:09 imirkin_: no futzing with bus speeds required :)
14:09 RSpliet: haha, for me that actually sounds easier :p
14:09 imirkin_: no hardware required either
14:09 imirkin_: it's all software
14:10 imirkin_: i dunno, i always have an easier time getting software to do the things i want than getting hardware to do things i want
14:10 RSpliet: insn sched requires combining "da arbitrary rulez" with a dependency graph
14:10 imirkin_: right
14:10 RSpliet: I find it quite difficult to suck out an algo for that :-D
14:10 imirkin_: so come up with *some* set of rules (dep graph already available)
14:10 imirkin_: and that should work better than "random order"
14:11 RSpliet: what stage would you do that... after postRA?
14:11 imirkin_: really you want 2 scheduling stages
14:11 imirkin_: pre-ra and post-ra
14:11 imirkin_: pre-ra you want to reduce live ranges a bit
14:11 imirkin_: to reduce register pressure
14:11 imirkin_: post-ra you want to reorder stuff s.t. things get paired up nicely
14:12 imirkin_: and you try to fit a bunch of stuff after, say, a texture instruction
14:12 imirkin_: (before that instruction's results get used)
14:12 imirkin_: i suspect there's a ton of research on this topic
14:12 RSpliet: yeah... although I reckon that's an ideal point for a "context switch" too...
14:13 imirkin_: however it's fun (for me) to come up with my own schemes
14:13 imirkin_: context switches are slow compared to doing a single tex fetch
14:13 imirkin_: and also you don't control them from within the shader
14:13 imirkin_: there is no "yield" instruction
14:13 RSpliet: I know... I assume HW figures that out
14:14 imirkin_: yep
14:14 RSpliet: but... it shouldn't be slow, it's a matter of switching register sets for each new instruction that enters the pipeline
14:14 RSpliet: the worst thing that could happen is icache misses
14:15 imirkin_: we're talking about diff things
14:15 imirkin_: i'm talking about hwcontext switch
14:15 imirkin_: new vm, new gpu settings, new everything
14:15 imirkin_: this takes a while
14:15 RSpliet: right
14:15 RSpliet: that's... impossible while in-flight
14:15 imirkin_: you're talking about... i dunno what
14:15 imirkin_: something that's not a thing on gpu's i think :)
14:15 RSpliet: imirkin_: absolutely
14:15 RSpliet: I think people call it hw threading
14:16 imirkin_: you have a bunch of lanes
14:16 RSpliet: *lanes
14:16 RSpliet: ?
14:16 imirkin_: which run in parallel executing the same stuff
14:16 imirkin_: imagine a SIMD cpu
14:16 imirkin_: let's say 4x32
14:16 imirkin_: you execute a bunch of instructions which do the same thing to each 32-bit "lane"
14:17 imirkin_: this is basically how gpu's execute. nvidia hides this by you specifying instructions within a lane
14:17 imirkin_: but it's still executed in lock-step
14:17 RSpliet: imirkin_: I know
14:17 imirkin_: when there's divergence it pauses all the other lanes
14:17 imirkin_: and does them one at a time
14:17 RSpliet: again, I know
14:18 imirkin_: (moral of the story: don't have diverging control flow)
14:18 RSpliet: but there's a reason why the CUDA manual states that ideally you launch about 8x more threads than cores
14:18 imirkin_: heh
14:18 imirkin_: coz CUDA core != lane
14:18 imirkin_: CUDA core == fp unit
14:19 imirkin_: there are fewer of those than lanes
14:19 imirkin_: at least iirc that's the deal
14:19 imirkin_: not sure what all a lane can do that *doesn't* require one of those shared resources
14:19 RSpliet: I believe it states something along the lines of "it helps to mask memory access"
14:20 imirkin_: right... it can sit there and wait for data to become available
14:20 imirkin_: anyways, you can think of it as "threading"
14:20 imirkin_: i dunno if that's how it's really implemented tbh
14:20 RSpliet: they hint towards it... ARM Mali has barrel processors
14:21 RSpliet: (or, the 400-series did, no idea if they still do... but I reckon they do)
14:21 mupuf: RSpliet: congrats! It would seem your code reclock my nva0 correctly!
14:21 RSpliet: mupuf: excellent!
14:21 mupuf: running a benchmark to check for stability and speed improvement
14:21 RSpliet: mine went x2 :p
14:22 imirkin_: mupuf: while switching perf levels non-stop! :)
14:23 mupuf: not yet, one thing at a time >D
14:23 imirkin_: no! all at once!
14:23 RSpliet: the Max Power way!
14:23 imirkin_: exactly
14:25 mlankhorst: it's not fast enough until it's broken!
14:26 mupuf: RSpliet: no change, do I need to set a parameter to reclock memory?
14:27 imirkin_: mupuf: pstate should tell you if clock speeds changed...
14:27 mupuf: it seems to reclock memory, at least that is what pstate says
14:27 mupuf: oh! I get it
14:27 mupuf: weird refresh rate
14:27 mupuf: 75Hz
14:27 mupuf: I'm too used to 60
14:27 mupuf: it is vsynced
14:27 mlankhorst:is on 65 or something
14:27 mlankhorst: overclocked though
14:28 imirkin_: mupuf: run heaven
14:28 imirkin_: or valley
14:28 imirkin_: that should be sure not to hit your vsync :)
14:28 mupuf: ah ah, xonotic for now
14:28 mupuf: indeed :D
14:30 mupuf: hmm, I guess xonotic is cpu limited :D
14:35 mupuf: here we go, a saner 40fps for the mid perflvl
14:35 mupuf: instead of ~200fps
14:35 mupuf: 1024*768 is not challenging enough on the vram
14:37 imirkin_: still with xonotic?
14:38 mupuf: yep
14:38 mupuf: xonotic can be very demanding
14:38 mupuf: not sure if it is because it is badly optimised or not though
14:39 imirkin_: 1920x1080 is a lot of pixels
14:39 imirkin_: a lot more than 1024x768
14:39 mupuf: nice, my guestimate was quite accurate! 39.7826426 fps
14:40 mupuf: indeed
14:40 mupuf: seems like the upclocked version runs a bit faster than 60 fps
14:40 mupuf: I'll vote for 70
14:41 imirkin_: 75!
14:43 mupuf: darn it, you are right, forgot the vblank_mode again :D
14:43 imirkin_: :p
14:43 imirkin_: you can run it with vblank_mode=0
14:43 imirkin_: which will force it to not vsync
14:43 mupuf: yes, that is what I do
14:44 mupuf: I had to run another shell because xonotic did not want to quit nicely
14:44 mupuf: and of course, I forgot again to add the vblank mode
14:46 imirkin_: really you just like watching the timedemo
14:47 mupuf: I know it by heart...
14:47 mupuf: there is apparently a shorter one
14:47 mupuf: RSpliet: 67 vs 109 fps
14:47 mupuf: nice!
14:48 mupuf: let's compare with the blob
14:48 imirkin_: i bet blob will be 130fps
14:52 mupuf: ah ah
14:52 mupuf: seems more like 200
14:53 imirkin_: ouch
14:53 mupuf: what the heck, I feel lucky tonight
14:53 mupuf: 199.6765806 fps
14:54 mupuf: seems like we are doing something wrong here!
14:54 imirkin_: yeah, like not enabling all the partitions
14:54 imirkin_: or our instruction schedule really sucks
14:55 mupuf: yeah, not enabling all the partitions could make sense
14:55 mupuf: since it is a weird card with a lot of them!
14:55 RSpliet: well, or they are enabled but the workload is inappropriately devided amongst them
14:59 mupuf: that would be interesting if they had different heuristics
14:59 imirkin_: i'm not aware of any options to configure that tbh
15:00 RSpliet: heuristics? I'm sure it's simply a matter of diving the data into burst-length chunks, and put every block on a different RAM chip
15:01 RSpliet: or... that sounds like the best way to go, so linear reads can be read out in one continuous stream
15:01 mupuf: RSpliet: mwk described it already
15:02 mupuf: and yeah, I seem to remeber that every 0x200 bytes, it would go to the next partition or MC or something else
15:02 mupuf: or was it 0x20
15:02 mupuf: nah, it was bigger
15:09 RSpliet: thinking about that, it might be equally efficient considering there's several layers of cache in between :p
15:09 imirkin_: mupuf: experimentally i've noticed that we choose predication over jumps too often
15:21 mupuf: imirkin_: predication? What are you talking about?
15:23 pmoreau: Methods 0x6 and 0x7 of _DSM on my laptop are kind of weird: they are basically just returning the content of a 4KB field.
15:23 pmoreau: I wonder what's stored in it.
15:38 imirkin_: mupuf: ($c) do stuff
15:39 imirkin_: mupuf: versus a branch to skip over things
15:39 mupuf: do we have any information about what is faster?
15:39 imirkin_: heh
15:39 imirkin_: each has its considerations
15:39 imirkin_: after a certain number of instructions it's a loss
15:40 imirkin_: i think our threshold is too high
15:52 skeggsb: robclark: that issue is really annoying, and very slow to track down over ssh with the lag from .au and the sheer number of reboots.. i've got an internal bug for el7 now for it, i'm trying to get the laptop shipped here temporarily to solve it
15:52 skeggsb: imirkin_: no, i've just got a (semi-broken) gm204
15:53 skeggsb: imirkin_: ram issues i guess, the vbios screen even shows issues
15:54 robclark: skeggsb, oh, heh.. was that the same HUB_INIT issue on the laptop in the office?
15:55 skeggsb: robclark: not entirely, bentiss' had far more issues than just that
15:55 skeggsb: i've fixed most of them, some still remain.. perhaps, for the same reasons actually, i don't really know yet
15:57 robclark: ahh
16:11 mlankhorst: hm I may have set the tests too aggressively for tegra :P
16:11 imirkin_: ?
16:13 mlankhorst: make check is taking ages
16:14 imirkin_: why would you ever run that? :p
16:17 mlankhorst: building libdrm deb on the tegra
16:17 Karlton: imirkin_: Did you or tobijk learn anything more about the purple texture since yesterday, or is it still a mystery?
16:17 mlankhorst: oh well, night
16:17 imirkin_: Karlton: tobijk tracked down which draw introduces the purple
16:17 imirkin_: Karlton: nothing further
16:18 Karlton: imirkin_: k, ty
16:18 imirkin_: it's definitely something very weird
16:18 imirkin_: coz GK10x and GF10x are *very* similar
16:19 imirkin_: the texturing is done differently, but that's about it
16:19 imirkin_: Karlton: it does look like the program may be doing something dodgy since it seems like they have the FB bound as a texture
16:19 imirkin_: but that's not strictly speaking illegal
16:24 Karlton: I haven't found any other open source games that has that issue, though I do have a proprietary windows game that does have something similar
16:25 imirkin_: well, it's not like the issue is "purple things"
16:25 imirkin_: the issue is either some sort of subtle miscompilation
16:25 imirkin_: or feeding the wrong data in
16:25 imirkin_: or... something
16:25 imirkin_: which so happens to manifest as "purple things" with this particular game, but change 2 tiny things and it could end up looking totally different
16:26 Karlton: right, well the other game that I found an issue with isn't purple but instead the ground is either invisible or reflecting the sky
16:26 imirkin_: might well be a totally different and unrelated issue
16:27 Karlton: all I know is that it sort of worked when I ran the trace on intel graphics
16:27 Karlton: but I did not have the same mesa version
16:28 imirkin_: right. for all we know it's invoking undefined behavior and just happens to work out on intel
16:28 imirkin_: not saying that's what's happening, but it could be.
16:28 imirkin_: in the case of that game, it even works on my GF108 card...
16:28 imirkin_: but it's a weaker card, only one GPC, could be that with multiple GPC's there'd be an issue
16:29 imirkin_: ooh, actually i have a GK208 here, should probably try it out
16:30 imirkin_: Karlton: do you have a link to the trace handy?
16:30 imirkin_: or did it expire already?
16:30 Karlton: imirkin_: which one?
16:30 imirkin_: your terasomething trace
16:31 Karlton: ugh, i'll have to search my logs for the link
16:31 imirkin_: airlied: is there a way to force secondary gpu driver to load in X? can i do Load "nouveau" or something? i have to have an xorg.conf for monitor configuration...
16:32 Karlton: imirkin_: https://www.sendspace.com/file/b0vlxy
16:32 imirkin_: thanks, got it
16:36 imirkin_: hrmph, well i don't have the secondary screen here coz gpus don't appear to get auto-added
16:42 airlied: imirkin_: xorg.conf support is lacking
16:43 imirkin_: airlied: _anything_ i can do?
16:43 imirkin_: i thought i could Load it in a modules section or something
16:43 airlied: nope nothing will probe if xorg.conf is provided
16:43 imirkin_: can i cause xorg.conf to probe it?
16:43 airlied: nope
16:43 imirkin_: and have it come up as a GPU rather than a regular screen
16:44 imirkin_: coz definitely if i have e.g. 2 nvidia devices
16:44 imirkin_: the second one comes up as a gpu screen even if the first has an explicit device section
16:44 imirkin_: coz once the driver is loaded, it "consumes" all devices...
16:44 airlied: I had vague ideas to either allow two drivers in one device section or something like that
16:44 imirkin_: why can't i just Load it like i load "glx"?
16:45 imirkin_: (well, glx is autoloaded nowadays, but you get the idea)
16:46 airlied: I think that will load it, but not init it properly
16:47 imirkin_: let's find out :)
16:47 airlied: even looking at the code makes me feel worse, and I have a hangover already
16:48 imirkin_: yeah, fail
16:48 imirkin_: nouveau gets loaded, but no probing
16:49 imirkin_: i suppose it'd just be insane to be able to say "gpu" in a regular device section?
16:49 airlied: oh there are any number of ways it could look, just none of them have code to back it up
16:50 imirkin_: given your somewhat higher-than-my familiarity with the code, can you suggest a reasonable way forward?
16:52 airlied: my initial thoughts are to hack xorg to allow multiple Driver lines per device section
16:52 imirkin_: ok
16:52 imirkin_: can you name one or two files i should look at? i'm really unfamiliar with X
16:53 imirkin_: and there's so much indirection there that it always takes me a while to orient myself in there
16:55 airlied: ur1.ca/jxgpn
16:55 airlied: start there
16:55 imirkin_: that should Just Work (tm) right?
16:55 airlied: nope, not even built it
16:55 imirkin_: yeah, but it seems like it has all the pieces
16:56 imirkin_: or do you think it may be missing something?
16:56 airlied: something needs to take that and use it
16:56 imirkin_: sorry, not sure what you mean
16:58 airlied: that is just the parsing, the server needs to use the parsed data
16:59 imirkin_: oh. somehow i thought that TestFree is what used it. but that's clearly bogus.
16:59 imirkin_: :)
17:03 imirkin_: airlied: ok, and any hints on what to look at for how gpu's are autoadded?
17:04 imirkin_: i guess something like probeSingleDevice(&xf86_platform_devices[j], drvp, devList[0], PLATFORM_PROBE_GPU_SCREEN);
17:04 airlied: hmm we probably want two device sections per a screen section
17:05 airlied: ur1.ca/jxgrq\
17:05 airlied: ur1.ca/jxgrq
17:05 airlied: that might work, it also might not
17:05 airlied: autoconfig just loads all the drivers and sees what sticks basically
17:06 airlied: thats also an ABI break
17:07 imirkin_: between what and what?
17:07 airlied: X server and drivers
17:07 imirkin_: ugh
17:07 xexaxo: hmm +int num_drivers; /* For multi-CRTC cards */
17:08 airlied: oops cut-n-paste ftw
17:08 imirkin_: there are a few small problems in that patch
17:08 airlied: though I dislike that patch a lot anyways so it'll never get upstream :)
17:08 imirkin_: but i dunno if i'm ready to break the abi
17:08 xexaxo: no probs. just checking if I'm still seeing right :)
17:08 airlied: well you can't fix without an abi break somewhere
17:11 imirkin_: sounds like a challenge!
17:11 imirkin_: how about a screen or serverlayout-level option of like "dotheautoaddanyways"?
17:12 imirkin_: s/autoadd/autoprobe/
17:12 airlied: I suppose you could hack that up, but not sure of how, when we see xorg.conf all bets are off wrt device probing
17:13 imirkin_: :(
17:13 imirkin_: ok... any other solutions, other than x11vnc, for getting this to work?
17:13 imirkin_: oh, shouldn't it just work with dri3?
17:14 airlied: oh maybe dri3 should support DRI_PRIME without the server loading anything
17:15 imirkin_: except the gentoo ebuild has a hard --disable-dri3 in there. EXCELLENT
22:47 dardevelin: hi everyone, just wondering how is support for NVIDIA Geforce GTX850 4GB (if anyone has experience that could share)
22:50 dardevelin: basically, I don't want to shoot myself in the foot, but this is a laptop and i would like to know how to _position_ the card in my choice
22:50 dardevelin: as I will rank higher things that are more likely to run well respecting my freedom :)
22:56 imirkin: dardevelin: seems like most likely that's a GM107
22:56 imirkin: dardevelin: upstream kernel doesn't have context switching logic for maxwell, but ben's repo now has something for GM107
22:56 imirkin: dardevelin: the 3d support is basically working, i think there are a few quirks here and there too
22:57 imirkin: dardevelin: however i wouldn't expect reclocking to work on that gpu for a long time, so in terms of performance, it won't be able to beat out the intel gpu in there, most likely
22:58 imirkin: although i haven't actually tried it
23:01 dardevelin: alright thank you very much
23:01 dardevelin: imirkin,
23:02 imirkin: dardevelin: if you get a kepler gpu, speed prospects are a bit better
23:02 dardevelin: and optimus is also no luck, except i can always fall back to the intel right
23:02 imirkin: optimus is fine
23:03 imirkin: it obviously presents its set of issues as well
23:03 imirkin: esp if you end up with screens that hang off that gpu
23:07 dardevelin: humm
23:07 dardevelin: It seems I really need to be careful with this, I don't need super gpu stuff. But you know would be nice
23:07 dardevelin: :)
23:09 imirkin: well, optimus is best if you're looking to increase battery life
23:09 imirkin: nvidia gpu's eat a lot of power, so if they can be powered off that's ideal
23:13 dardevelin: for me, I want a good cpu, a usable graphic card (like don't burn my lap) and preferably freedom respecting.
23:14 dardevelin: and somewhat future proof as I don't buy laptops that often
23:14 imirkin: dunno what 'freedom respecting' means tbh
23:14 imirkin: everyone has their own nonsensical definitions
23:15 dardevelin: sorry for being vague. well the card itself is not because nvidia does not support this freedom at all. But if there is free software drivers
23:15 dardevelin: I get happy
23:16 imirkin: right, but where do you draw the line? what about firmware that runs on the card?
23:18 dardevelin: if there is free software firmware great, but I know thats harder so
23:19 skeggsb:wonders in general why it's ok (for linux-libre types) for us to blindly execute scripts from the vbios but not upload binary firmware to the card
23:19 skeggsb: :)
23:19 imirkin: skeggsb: even open-sourced binary firmware :)
23:20 skeggsb: imirkin: it just boggles my mind, we're more or less "executing" proprietary, unmodifiable code by running vbios scripts :)
23:21 imirkin: skeggsb: and every so often they come in demanding to replace the vbios blobs :)
23:21 skeggsb: *shudder*
23:22 RAOF:also thinks it's an incoherent position.
23:22 imirkin: to me it's all simple -- unverifiable code running on cpu = bad. everything else = fine. that's what iommu's are for.
23:22 skeggsb: i wonder how we're supposed to know the board topology without them...
23:23 skeggsb: imirkin: agreed