00:32freddd: Hello beautiful free people.
00:33freddd: imirkin, you can not get rid of me that easily!
00:33freddd: Tom^ <3.
07:59Calinou: >wants free driver >plays Valve games
07:59Calinou: seriousness: -2147483648
08:18urmet: overflowing with seriousness? :)
09:29Lekensteyn: perhaps interesting to know, MS has apparently forbidden the use of muxes for the hardware certification of Win8+ (muxless is still allowed)
09:30karolherbst_work: Lekensteyn: hihi :D
09:30karolherbst_work: so is switching in the vbios still allowed?
09:33Lekensteyn: karolherbst_work: what do you mean by switching in the vbios? The intent was to improve the "user experience"
09:38freddd: Lekensteyn, why would they want to do that?
09:38freddd: (I am not that technical in the area, thus asking)
10:56karolherbst_work: Lekensteyn: some bios allow you to disable the intel GPU completly and just use the dedicated one
10:56karolherbst_work: which means wiring the internal display to the dedicated gpu
10:56karolherbst_work: which should require a mux
10:57karolherbst_work: should give you more performance, because the pcie overhead is much lower
10:58Calinou: but then battery life goes down
10:58Calinou:finds battery life of almost all laptops with dedicated GPUs too low
10:58Calinou: even in Optimus mode
11:00karolherbst_work: Calinou: *cough* gaming laptops *cough* :p
11:01karolherbst_work: some user just plug their hot shot laptop on AC all the time and use it to play some games
11:01karolherbst_work: and if turning off the intel gpu gives them likge 5% more perf, they do it then
11:02Calinou: the overhead of Bumblebee is quite high
11:02Calinou: compared to Windows
11:03Calinou: can't get to very high FPS (> 150)
11:03Calinou: so some hardcore gamers don't like it
11:30karolherbst_work: Calinou: yeah, DRI_PRIME is better here :p
11:30karolherbst_work: but I am sure this is something bumblebee does wrong
11:31karolherbst_work: because you copy basically the same data
12:55karolherbst_work: I tried to run the nva tools on a gm20x gpu, but the nva_init function failed after nvidia was loaded. Sadly I didn't had much time to debug it properly and wanted to know if anybody of you encountered this at some point?
12:58karolherbst_work: mupuf: and if you are so nice, could you place a gm20x gpu into reator? I want to check things
12:59mupuf: karolherbst_work: funny, I thought I checked this already
12:59mupuf: maybe it is a chipset we have never seen yet
12:59mupuf: I could plug my gm206
13:00karolherbst_work: would be awesome, thanks :)
13:46Lekensteyn: karolherbst_work: I got such a laptop, but this does not allow switching using the MXM methods which possible causes a short flicker
13:46Lekensteyn: which is probably the reason why it is forbidden
13:47Lekensteyn: (switching at runtime that is, I have to go to the BIOS and either have discrete only (without Intel) or hybrid mode)
13:51Lekensteyn: oh, it is about the win 8.1 certification requirements btw. It literally says: "Lastly "Switchable Graphics solutions" where the display output is moved from one GPU to another GPU are not allowed."
13:52karolherbst_work: ohh okay
13:52karolherbst_work: then that's fine
13:52karolherbst_work: ARM though
13:54karolherbst_work: right, nvidia optimus requires and addendum, but SLI is fine...
13:55Lekensteyn: the win10 reqs are at https://msdn.microsoft.com/en-us/library/windows/hardware/dn932812(v=vs.85).aspx#system_fundamentals_graphics_hybridgraphics_multigpu
13:55karolherbst_work: "The dGPU must be equal or higher performance than the iGPU" *cough* :D
13:57Lekensteyn: was apparently not always the case with some amd/amd combinations :p
14:21ajax: imirkin_, skeggsb, etc: mind if i bless myself into the nouveau group so i can fix the ddx driver for new server abi?
14:24imirkin: as long as you don't break compilation for the old abi, fine by me.
14:25imirkin: [not that i'd expect you to do any such thing...]
14:39ajax: i appear to be already in the group. wonder why i can't push.
14:39ajax: drwxr-xr-x 8 marcheu nouveau 4096 Jun 30 16:13 xf86-video-nouveau.git
14:40ajax: that'd be why then
14:44imirkin: hm? i def used to be able to push to it...
14:46imirkin: Jun 30? hm. odd. maybe that's when ben pushed the last change? it's dated as commited Jun 27 though.
14:46ajax: there was some repo management done a while ago to repack things
14:46ajax: which broke perms
14:47ajax: there we go
14:52mupuf: ajax: thx
15:28OxOO: cpu load rises to 140% when watching 1080p videos on my linux system with nouveau driver. Is there any way to fix this or is the only way to change to proprietary driver?
15:28imirkin_: OxOO: http://nouveau.freedesktop.org/wiki/VideoAcceleration/
15:32OxOO: imirkin: thank you
15:43Tom^: much todo on VP6+ :(
15:43imirkin_: Tom^: yeah. no one's looked at it yet, afaik
15:43imirkin_: it's structurally different from VP3/4/5 though, at first blush
15:44imirkin_: single engine vs 3 separate ones
15:44Tom^: i see
15:44imirkin_: maarten did VP3/4/5, i did VP2. someone else will have to come along to look at VP6. one engine per lifetime is the limit.
15:45Tom^: you need three people then
15:45imirkin_: [VP3/4/5 are all basically the same, the differences are minute]
15:45imirkin_: well, there's a high likelihood that all the recent stuff is the same
15:45imirkin_: based on the fact that no matter how much it might suck writing drivers for these things
15:45imirkin_: creating the things themselves has gotta suck more
15:49hakzsam: imirkin_, well, time to look at tess again :)
15:50imirkin_: hakzsam: how 100% sure are you that bit 56 is neg for src0 on IADD32I?
15:50imirkin_: can you pastebin nvdisasm output?
15:50hakzsam: because I trust nvdisasm
15:51hakzsam: imirkin_, http://hastebin.com/nulimejeju
15:51imirkin_: ah ok. and bit 55 is po.
15:51imirkin_: (po == plus one)
15:52hakzsam: envydis is aware of that bit now
15:52hakzsam: and I sent two patches for the emitter
15:52imirkin_: 1d8 doesn't come out with a NEG
15:52imirkin_: /*0008*/ @P0 IADD32I.PO R0, R0, 0x0; /* 0x1d80000000000000 */
15:53hakzsam: I guess it's because po is set
15:53imirkin_: yeah. just odd.
15:54imirkin_: and curiously 0x1c8 isn't in your output, which i'm guessing means that nvdisasm hated it.
15:57imirkin_: hakzsam: btw, i suspect that IMAD might have the same issue, except i don't think there's a IMAD32I we can easily use. [it exists, but src3 == dst, i think]
15:58hakzsam: imirkin_, right, this IMAD32I exists but it's buggy
15:59imirkin_: well, it's not buggy
15:59imirkin_: it works as intended by the ISA designers
15:59imirkin_: which is just inconvenient for us :)
15:59imirkin_: perhaps we should just redefine what longIMMD means for SM50
15:59imirkin_: for integers
15:59hakzsam: the third src overlaps the dst :)
16:00imirkin_: and make it be 19 bits instead of 20
16:00imirkin_: that should solve all these issues afaik
16:00imirkin_: or ... actually i think it's still 20 bits
16:00imirkin_: they're just not sign-extended
16:00imirkin_: whereas our code assumes that they are
16:01hakzsam: I think yes
16:01imirkin_: either way, figure out what's what there
16:01imirkin_: and adjust the target logic to respect that
16:07hakzsam: imirkin_, what about the images series? don't you have other comments? :)
16:09imirkin_: nnnnot yet.
16:09imirkin_: iirc it looked fine
16:10hakzsam: I updated the bind images patch locally, but I can wait tomorrow or so before sending the v2
16:11imirkin_: btw, i think the way you have it, st/mesa will start using images for pbo downloads
16:11imirkin_: or uploads or whatever
16:11imirkin_: [no, downloads]
16:12hakzsam: I need to check that
16:12imirkin_: except the way you have it, you disable all image bindings, so it won't.
16:15hakzsam: imirkin_, nope, PIPE_BIND_SHADER_IMAGE is for MaxImageSamples but try_pbo_readpixels() will also try if it's supported
16:15hakzsam: so pbo downloads are disabled on gm107 :)
16:16hakzsam: yeah, samples > 1 is probably better
16:16imirkin_: if you want to disable MS images, yes.
16:16imirkin_: in theory, more is_format_supported checks should be done
16:16imirkin_: but in practice, you better support all the required formats, or else!
16:17hakzsam: I want to disable MS images
16:17imirkin_: so ... samples > 1
16:17hakzsam: because it's really painful to implement
16:17imirkin_: really? that's surprising.
16:17hakzsam: they have to be handled explicitly
16:17imirkin_: you should just be able to use adjustCoordinatesMS() as-is
16:17hakzsam: but I didn't investigate in details
16:18imirkin_: this scales up the coords and adds the sample offset to them
16:18hakzsam: I tried, but that didn't work
16:18hakzsam: maybe I messed up something
16:18imirkin_: grab blob code for it and see how it goes
16:19hakzsam: the shader is just crazy IIRC :)
16:19imirkin_: gregory38: you may be interested in marek's recent patchset to redo state update management in st/mesa
16:19imirkin_: gregory38: among other things, it gets rid of the horrible UseProgram() hack
16:19imirkin_: hakzsam: pastebin, i can have a look
16:19gregory38: Thanks for the info
16:20hakzsam: imirkin_, sec, I need to find the MMT
16:20imirkin_: gregory38: all that and some other (radeon-related) things available in https://cgit.freedesktop.org/~mareko/mesa/log/?h=si-mid-ib-gfx-fence
16:20gregory38: imirkin_: [Mesa-dev] [PATCH 0/9] st/mesa state tracking rewrite, this one ?
16:20imirkin_: gregory38: yes, that one.
16:22gregory38: I will give it a look, not sure when but worth to profile it :)
16:22imirkin_: no action necessary from you, i just figured you might be interested.
16:23hakzsam: imirkin_, I think it's this one http://hastebin.com/adiladenar.sm
16:23imirkin_: are you kidding me?
16:23imirkin_: that thing's a monster shader!
16:23hakzsam: crazy yeah :)
16:23imirkin_: is it solving the meaning of life among other things?
16:24gregory38: imirkin_: yes I'm definitevely interested.
16:24hakzsam: imirkin_, I don't known what's trying to solve, but I don't really want to read it ;)
16:24hakzsam: imirkin_, anyway, I think I will disable MS images for now on gm107
16:25hakzsam: and maybe try to implement them later
16:25hakzsam: after tess & co
16:25hakzsam: should be more reasonable
16:30imirkin_: hakzsam: anyways, doesn't look like it's doing that shl dance. so ... it's something else.
16:30imirkin_: hakzsam: perhaps it's just the last argument
16:30imirkin_: i assume you tried that too?
16:30imirkin_: that wouldn't explain why that shader is 1000000 lines
16:31imirkin_: it almost looks as if it's doing tiling calculations by hand. that'd be most sad.
16:32hakzsam: no, I didn't try
16:32hakzsam: but yeah, it seems like it does the thing by hand
17:22OxOO: aaw. my geforce 7950 gx2 NV49(G71) VP1 card has no vdpau support by nouveau. guess I have to use proprietary driver
17:32imirkin_: OxOO: proprietary driver won't help
17:32imirkin_: OxOO: are you watching mpeg2's or mpeg4's?
17:33imirkin_: if mpeg2's, nouveau ships a XvMC lib which should be able to make use of the onboard VPE engine
17:34imirkin_: although many video players have dropped XvMC support (even thought it's the most efficient way to operate those older video decoders), but mplayer still supports it.
17:37OxOO: imirkin: well I don't know so much about the tech around this stuff, but playing 1080p H264 .mp4 video file fullscreen works fine with gmplayer, but when trying to watch youtube html5 1080p video fullscreen in firefox it's so choppy it's not watchable.
17:38imirkin_: neither is getting video accel
17:38imirkin_: or at least, video decoding accel
17:38imirkin_: perhaps firefox tries to use OpenGL instead of Xv?
17:38imirkin_: that ends in sadness esp on older chips
17:39imirkin_: try disabling everything opengl-related in the firefox settings
17:40imirkin_: VP1 was in theory supposed to be able to help with WMV acceleration, but in practice, even on windows, it was never deemed particularly useful. the linux blob drivers never made use of it.
17:40imirkin_: there's a VPE engine as well, which will decode MPEG1 and MPEG2
17:41imirkin_: which is nice for DVB/ATSC streams, which those machines are often unable to handle
17:46OxOO: imirkin: should I turn off "use hardware acceleration when available" in preferences or am I looking to disable something in about:config?
17:46imirkin_: not 100% sure what that does
17:46imirkin_: but i think that's definitely worth a shot
17:46OxOO: in about:config there is for example "webgl.disabled" that I could put to disabled
17:47OxOO: and "gl.require-hardware"
17:48imirkin_: those won't help
18:02imirkin_: try killing all accel - that should speed things up :)
18:39karolherbst: wow... the 1060 has like half the power consumption of the 980, but nearly the same performance :/
18:39karolherbst: ohh wait, I compared with the 980 ti the power consumption
18:39karolherbst: then only 25% less
18:40karolherbst: mupuf: ... somebody tested the 1060.. idle: below 5W
18:53mupuf: very very nice!
19:06donbruno: hello can someone help me? I get this "[ 3423.377118] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Unknown chipset: NV117" when i run "Optirun glxgears"?
19:08imirkin_: donbruno: see https://nouveau.freedesktop.org/wiki/Optimus/ for proper optimus setup
19:09donbruno: imirkin_: thx I read it :-)
19:09imirkin_: do you see any mention of "optirun" on that page?
19:10imirkin_: anyways, the "error" you pasted is not an error at all - it's fully expected. xf86-video-nouveau doesn't support maxwell gpu's. use modesetting for those.
19:11imirkin_: however using optirun (or bumblebee or any of those things) is a mistake with nouveau
19:11imirkin_: those things were designed as hacks for idiotic blob drivers
19:15donbruno: imirkin_: mmhhh so I can deinstall bumblebee?
19:15imirkin_: i'd recommend it.
19:15imirkin_: if you're looking to use nouveau
19:15imirkin_: if you want to use blob drivers, you kinda need those
19:16imirkin_: (i think, i've never used blob drivers on an optimus setup)
19:17donbruno: ok and how told you the programm to use nvidia or intel?
19:18imirkin_: read the wiki page i pointed you at
19:21donbruno: mmhh the point is, I get by "xrandr --listproviders" only the intel
19:22imirkin_: are you set up for DRI3?
19:22imirkin_: i very much recommend the DRI3 route
19:25donbruno: is there kms for intel?
19:25imirkin_: there is only kms for intel
19:26imirkin_: (except for the ancient i815 & co chips... on the 440BX or something.)
19:26donbruno: I have an i915 intel
19:26imirkin_: more likely you have something that is driven by the i915 intel driver, but not an actual i915 chip
19:27imirkin_: i915 chips came out over a decade ago
19:28donbruno: mmhh I have an xps15 with skylake
19:31imirkin_: skylake is a gen9 chip, whereas i915 was gen1 (i think)
19:31imirkin_: either way, intel has kms
19:33donbruno: is the any package under arch, what I must install? I found only nvidia kms packages
19:36imirkin_: should work out of the box
19:37donbruno: ahhh ok I read it :-)
19:38donbruno: ok... but I only have only intel by listproviders
19:38imirkin_: did you read that wiki page?
19:38imirkin_: i mean ACTUALLY read it, not glance at it without reading
19:40donbruno: you mean DRI3?
19:40imirkin_: that's my recommendation
19:41karolherbst: well, to be fair, distributions are a bitch and default to dri2 on intel usually
19:41karolherbst: donbruno: you should check if you have something like "(II) intel(0): direct rendering: DRI2 DRI3 enabled" in the Xorg log
19:41donbruno: ok I installed mesa, xserver and kms for nvidia...
19:42karolherbst: if not, I recommend a xorg config like that: https://gist.github.com/karolherbst/1f1bdd1a3822df74097f
19:42karolherbst: donbruno: with kms for gpu is meant: i915 and nouveau kernel driver
19:42chithead: because dri3 on intel is broken in several ways and the developers don't even react to reports https://bugs.freedesktop.org/show_bug.cgi?id=71759
19:42karolherbst: chithead: not true
19:42donbruno: karolherbst: the log told me DRI2
19:43imirkin_: chithead: dunno, i'm using it with no ill effect
19:43karolherbst: chithead: I didnt had any issues with dri3 for a year now
19:43karolherbst: chithead: usually most issues come from outdated software
19:43karolherbst: and devs usually wont fix those, because its the distribution job to backport stuff for old releases
19:43chithead: bug was reported in 2013, updating everything was tried
19:44chithead: only last week someone started looking at it
19:45karolherbst: chithead: well, if you would have read the bug complete, you would know that it was a mix of server side and application side stuff
19:45karolherbst: where the server side as fixed
19:46karolherbst: well kind of
19:46chithead: I read the bug complete, our users suffered from it and complained, until we decided to disable dri3 by default again
19:47RSpliet: chithead: "someone" -> mupuf ;-)
19:47chithead: not even someone from intel ;)
19:47RSpliet: he is actually
19:47imirkin_: he's at intel
19:47chithead: really? I didn't know
19:48imirkin_: also your users suffer from not having easily-working prime setups, but they don't complain as loudly.
19:49chithead: if prime doesn't work then performance may suck, but if your video player crashes every time you play something that is worse
19:50imirkin_: right - doesn't mean users aren't affected both ways :)
19:50imirkin_: anyways, i've legislated this problem away - i just don't do distro support and that's that. if you want help operating your distro, i just send you to a distro support channel.
19:52donbruno: ok now ich have DRI 2 and DRI3 enabled
19:52chithead: yep, I don't complain about that. just don't call distributions "bitch" because they prefer working over non-working default configurations
19:52imirkin_: chithead: meh, i'm sure distros call upstream bitches for similar reasons
19:52mupuf: chithead: I wish one configuration was working
19:52imirkin_: it's not meant with any malice :)
19:53mupuf: right now, stuff work better with one option and worse with others
19:53donbruno: but I have still no output with nouveau... only intel with listproviders
19:53imirkin_: donbruno: that's expected.
19:53imirkin_: donbruno: keep following the instructions in the wiki
19:54mupuf: as for this bug report you pointed at, I am now spending quite a lot of time on it. This libva, clutter-gst, cogl mismatch is ... entertaining!
19:55donbruno: when i use "DRI_PRIME=1 glxinfo | grep "OpenGL vendor string" I get this "libGL error: failed to create dri screen
19:55donbruno: libGL error: failed to load driver: nouveau
19:55donbruno: OpenGL vendor string: Intel Open Source Technology Center
20:09donbruno: imirkin_: ?
20:11imirkin_: donbruno: LIBGL_DEBUG=verbose DRI_PRIME=1 glxinfo > /dev/null
20:11imirkin_: pastebin the output of that
20:13donbruno: imirkin_: http://pastebin.com/W2b2cNXr
20:14imirkin_: you're not using dri3
20:14karolherbst: ohh maybe mesa is compiled without dri3
20:15imirkin_: er wait
20:15imirkin_: no it is
20:15imirkin_: hold on
20:15imirkin_: libGL: pci id for fd 5: 10de:139b, driver nouveau
20:15karolherbst: donbruno: you did restart X and verified it shows both
20:15karolherbst: donbruno: maybe you need to install the nouveau mesa package
20:15imirkin_: so why does nouveau fail to load.... hmmmmm
20:15donbruno: http://pastebin.com/eH1TY8Hj my xorg.log
20:15imirkin_: donbruno: what version of mesa do you have? also, is this file there? /usr/lib/xorg/modules/dri/nouveau_dri.so
20:16karolherbst: mupuf: oho, so you also like the most challenging things too :p
20:17mupuf: lol, of courtse
20:17donbruno: imirkin_: the file ist there and mesa 12.0.1
20:17imirkin_: donbruno: pastebin dmesg
20:19donbruno: imirkin_: http://pastebin.com/prefCRxt
20:19karolherbst: seems like no nouveau there :p
20:19imirkin_: donbruno: there's no sign of nouveau in there, and you appear to have nvidia blob driver loaded
20:20donbruno: imirkin_: lsmod --> http://pastebin.com/riHLfbMP
20:21imirkin_: right ... nvidia
20:21imirkin_: not nouveau
20:21donbruno: so I deinstall nvidia?
20:22imirkin_: as i mentioned, i don't do distro support. but it needs to not be loaded for nouveau to load :)
20:22imirkin_: how you achieve that is up to you
20:28donbruno: imirkin: pastebin with nouveau --> http://pastebin.com/eusm1r02
20:29imirkin_: donbruno: ok, that's better
20:31imirkin_: donbruno: so what does glxinfo say now?
20:31donbruno: imirkin_: =0 intel / =1 nouveau
20:31imirkin_: that's good.
20:33donbruno: then I think =1 is with nvidia gpu!?
20:33imirkin_: yes, as documented
20:34imirkin_: and the gpu should auto-suspend itself when you're not using it, saving battery life
20:34donbruno: but when I use =1 glxgears.... I only have 300 frames... is it the with intel
20:35imirkin_: no, your gpu is in its lowest power state
20:35imirkin_: which will probably perform at ~same level as your intel gpu
20:35imirkin_: there is experimental reclocking support if you grab nouveau from https://github.com/karolherbst/nouveau/commits/stable_reclocking_kepler_v5
20:37donbruno: ahhh ok... so it comes next times with a new version... and then the frames are higher? sorry for my bad english
20:39donbruno: imirkin_: and all other thx for help...
20:39imirkin_: donbruno: yes, at some point in the future, maybe in 6 months or so
20:39karolherbst: hey :D
20:40karolherbst: oh well, for the enduser it might take so long, right
20:53Hauke: is there some work beeing done on reclocking support for fermi?
20:54imirkin_: RSpliet is looking into it at a rate of a few hours a month
20:55RSpliet: (sorry, beeing! O:-) )
20:55imirkin_: did i overestimate?
20:55RSpliet: not really
20:55Hauke: ok, no problem, I am anyway planing to get a new PC ;-)
20:55imirkin_: you can look at his branch, but i don't think it works for anyone at this point
20:56imirkin_: Hauke: get an amd gpu :) should have much better open-source support
20:56RSpliet: depending on what you look for of course. If you want a reliable machine to hang your machine my branch is the way to go, otherwise.... sorry, there's some missing bits before I can claim partial support
20:57Hauke: ok, thanks for the information, I will prepere a recent amd GPU if I have the choice
22:09Lekensteyn: RSpliet: somehow I read that as "if you want a reliable method to hang your machine, ..." :p
22:10imirkin_: that's how he meant it
22:10Lekensteyn: current stable and dev fails pretty bad on my fermi https://bugs.freedesktop.org/show_bug.cgi?id=96968
22:10imirkin_: you don't need his help to hang your machine, but others do ;)
22:10Lekensteyn: oh, instead of patching holes we now try to rip holes further open? Lovely :P
22:11imirkin_: it was a tongue-in-cheek comment
22:11Lekensteyn: got it
22:12karolherbst: please dont confuse me with this kind of advanced english :p
22:12Lekensteyn: back to engineering
22:13karolherbst: you mean back to sleep
22:13Lekensteyn: or reverse engineering, depending on how you look at it :P
22:13Lekensteyn: still have a part of the night
22:13imirkin_: what one man put together, another can always take apart
22:14karolherbst: imirkin_: is it required, that i can be put together _again_
22:14imirkin_: that's the hard part ;)
22:14karolherbst: I see
22:14karolherbst: well glue and tape always helps :)
22:14imirkin_: no one will ever know
22:15karolherbst: once a resistor on my old ATI gpu fell off, so I taped it back on :3
22:15Lekensteyn: nice tape story
22:15karolherbst: it was on the other side of the core, but no idea if that thing was important at all