05:06 chillfan: Just reporting back from some testing. From what I can tell, barring a crash bug with xonotic on the highest setting (on any clock level), 940m is stable with the reclock code.
05:07 chillfan: Pretty much put it through it's paces, though someone mentioned some patches to mesa.. perhaps I should try with that
05:10 imirkin: those patches were pushed a couple days ago
05:10 imirkin: which should greatly improve perf on maxwell
05:16 chillfan: Nice, where abouts from?
05:17 imirkin: ?
05:17 chillfan: I mean, where can I get it
05:18 imirkin: it's at mesa HEAD
05:19 chillfan: Ok thanks, will see if I can get it compiled on there some time
05:28 chillfan: I found an inacurrate clock setting on my 780ti as well. On nvboost=1 the clock setting is okay, but on nvboost=0 and the 0f state clockspeed is just shy of the factory setting. It's factory setting is 1006 MHz using the nvidia blob, but 1000 with nouveau
09:39 NanoSector: http://i.imgur.com/lUs1APO.png
09:40 NanoSector: yay
10:29 RSpliet: NanoSector: en weer een tevreden klant... glad everything works for you as well
11:15 NanoSector: RSpliet: 4.10 fixed a lot :D
15:13 michele: hi there
15:15 nyef: Tested, tested, found wanting, and debugged: vendor infoframes on gk104.
15:16 nyef: Also noticed: DP->HDMI is only detected at startup, it doesn't hotplug, and if you unplug it while the system is running you won't get it back until restart.
15:17 nyef: I think I need to rebase before I prepare the patch series, though.
15:19 nyef: I guess the next question is, do I go to the trouble and expense of obtaining hardware to cover the g84 and gf119 cases?
15:26 michele: hi have summarized my question here: https://glot.io/snippets/em9qhtt7ix
15:26 michele: can anyone give me a hand please?
15:31 nyef: michele: The first thing that comes to mind is to check the vga switcheroo state while the glxgears is running, in case using DRI_PRIME is turning it on.
15:31 nyef: I'm substantially unfamiliar with the whole switcheroo thing, so I don't know if that's expected or not.
15:34 michele: nyef: at the end of the file I did it
15:35 nyef: I have no idea, then.
16:11 NanoSector: michele: almost sounds like nouveau isn't loaded; can you confirm with 'lsmod | grep nouveau'?
16:13 michele: NanoSector: it's loaded. # lsmod | grep -i nouveau
16:13 michele: nouveau 1556480 0
16:13 NanoSector: hmm, any output in dmesg?
16:14 michele: NanoSector: https://glot.io/snippets/em9rtbwqx5
16:15 NanoSector: hmm that is working
16:15 NanoSector: can you pastebin your whole dmesg?
16:17 michele: yes
16:18 michele: NanoSector: https://glot.io/snippets/em9rxbzb6x
16:21 imirkin: is there a raw view?
16:22 NanoSector: yeah it's quite painful this way
16:23 NanoSector: michele: assuming you're using fedora, if you can get kernel 4.10 somehow i'd try that
16:23 michele: NanoSector: opensuse
16:24 NanoSector: close enough
16:24 NanoSector: try that, anyway; 4.10 includes fixes
16:24 imirkin: nyef`: the DP -> HDMI thing sounds very unexpected. that should def work fine.
16:24 michele: NanoSector: imirkin https://nopaste.xyz/?eba57e5ddf707d3a#nSoJfIRpuJUL9WKnACytXi8EyFql6i0sytpcRmx9yFY=
16:24 michele: this is the raw
16:25 michele: i see something: "\_SB.IETM._ART: Return Package type mismatch at index 0 - found Integer, expected Reference (20160831/nspredef-297)"
16:25 michele: don't know if it's related
16:25 NanoSector: that doesn't look like an ACPI path related to your GPU
16:26 NanoSector: [ 3.315341] ACPI Warning: \_SB.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
16:26 NanoSector: there's that
16:26 NanoSector: but my laptop has that too and it works
16:26 imirkin: michele: something you did must have activated the gpu. it can be very dumb things, like "lspci".
16:26 NanoSector: imirkin: the problem is that the GPU can be activated but it doesn't show up in xrandr or when using DRI_PRIME=1 glxinfo
16:26 michele: right
16:26 imirkin: ah.
16:27 imirkin: is there an xorg log i can glance at?
16:27 michele: so NanoSector your suggestion is to use a newer version of the kernel
16:27 NanoSector: michele: Linux 4.10 fixed a number of bugs for me
16:27 imirkin: michele: ignore that. 4.10 won't fix anything in that department.
16:27 NanoSector: oh
16:27 NanoSector: heh
16:27 imirkin: it *does* have various fixes, but won't address anything relating to your current situation.
16:27 NanoSector: i tried :D
16:27 michele: imirkin: https://nopaste.xyz/?18b4bf9cf74bcd9a#YcNjbxRfnnTNgzDOqfX8MBtr2DqbwA32c0Jb/M0aruo=
16:28 imirkin: you will want to eventually upgrade if you're looking to use nouveau, as it will enable reclocking on your gpu.
16:28 michele: imirkin: this is the Xorg.0.log
16:28 imirkin: michele: ok, and LIBGL_DEBUG=verbose glxinfo > /dev/null
16:30 imirkin: [i'm looking for the last line that command would output]
16:30 michele: imirkin: https://nopaste.xyz/?7e2b397e17fdfa0a#v7xucfsBsnv8vTzV6xDIsDpQai53iSFATWbeiwp2z8M=
16:30 imirkin: great
16:30 imirkin: so
16:31 imirkin: you're using DRI2, not DRI3. you don't have a DDX loaded for your secondary GPU, which means you can't set up any sort of offloading.
16:31 imirkin: two possible solutions: (a) enable DRI3 support for your intel ddx, (b) load a ddx for your secondary GPU and perform the required dance to get offloading working.
16:32 imirkin: note that released versions of the nouveau DDX won't load on your GPU, but you can use either the one from git, or use modesetting which ought to load fine.
16:32 imirkin: personally i recommend the DRI3 route though.
16:33 michele: imirkin: ok how do I enable DRI3 support for intel?
16:33 imirkin: this and more information is available at https://nouveau.freedesktop.org/wiki/Optimus/
16:33 imirkin: as for enabling DRI3 on intel ... not sure. might be an xorg config flag, or might be a compile option, or might be both.
16:35 michele: imirkin: how do I know if KMS is enabled for my two cards?
16:35 imirkin: define 'KMS is enabled'
16:36 imirkin: KMS is a little moot for your nvidia gpu as it doesn't have any outputs...
16:36 imirkin: won't be setting a whole lot of modes :)
16:36 NanoSector: heh
16:37 michele: I've added this to my xorg conf: https://nopaste.xyz/?6b57e787ebebc572#+Cb8C6ur7gAY5f50qXW7bLrCRutcI8UJmKGsZyBR6PA=
16:37 michele: let's try
16:37 NanoSector: michele: https://wiki.archlinux.org/index.php/Intel_graphics#Configuration
16:37 NanoSector: ah
16:37 NanoSector: nice
16:37 NanoSector: ninja'd :P
16:38 michele: rebooting
16:38 imirkin: just need to restart X...
16:40 michele: ok
16:40 michele: done
16:42 michele: some good news and some bad news
16:42 michele: https://nopaste.xyz/?9efb6cb34b1ddf2a#yxlVpnaObEf4q51KqBqARcWGa7PYjHP2gBGrWUp860E=
16:42 michele: https://nopaste.xyz/?d36593cdc511a7d6#+PeplsHK8IU1A5Xv12NAhSRAXEa2vDEJNcN4lE7Ms14=
16:44 michele: and now DRI_PRIME=1 glxgears keeps at 60fps
16:45 michele:facepalms
16:47 imirkin: listproviders is for DRI2-based offloading
16:47 imirkin: glxgears is normally vsync'd, if you want to max it, vblank_mode=0. however note that this is not a benchmark that measures ... anything anyone cares about.
16:48 michele: imirkin: ok how do I know if my setup is correct know?
16:48 michele: imirkin: i mean, with dynamic switching
16:49 imirkin: DRI_PRIME=1 glxinfo - does that say nouveau?
16:49 imirkin: and without the DRI_PRIME=1 does that say intel? if so, you got dynamic switching :)
16:49 imirkin: [for some definition of dynamic... and switching...]
16:50 michele: imirkin: https://nopaste.xyz/?d36593cdc511a7d6#+PeplsHK8IU1A5Xv12NAhSRAXEa2vDEJNcN4lE7Ms14
16:51 michele: imirkin: it does say intel and gallium
16:51 imirkin: well, NV118. a different line would have said nouveau.
16:51 imirkin: e.g. OpenGL vendor
16:52 michele: imirkin: so we have clarified that listproviders only work for DRI2
16:53 michele: imirkin: and that FPS for glxgears is not a special benchmark (even if before I was running high FPS with DRI_PRIME and now it stays the same)
16:53 michele: imirkin: should I need to run DRI_PRIME=1 for chrome?
16:54 michele: imirkin: last, but not least. running DRI_PRIME=1 glxgears and looking at vgaswitcheroo switch, it says: 1:DIS: :DynPwr:0000:03:00.0
16:55 imirkin: that's right
16:55 michele: imirkin: but it still does not have the +, so i'm not connected to the card?!
16:55 imirkin: no clue what the + is.
16:59 imirkin: to use any application on the nvidia gpu, you need to run it with DRI_PRIME=1 in its environment.
17:00 michele: imirkin: can you name some applications that benefit from it? e.g. chrome requires it?
17:01 michele: "requires" -> "do you suggest to use it with crome"
17:01 michele: +h
17:01 imirkin: without reclocking, i would assume that the gpu is universally slower than the SKL in your system.
17:02 michele: imirkin: what do i need for reclocking?
17:02 imirkin: kernel 4.10
17:03 michele: imirkin: by SKL you mean the integrated graphic?
17:04 imirkin: michele: yes, your skylake chip (i assume, i guess i didn't check)
17:05 imirkin: [ 7.566] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 5500
17:05 imirkin: oh wow, not even close
17:05 imirkin: [gen8/broadwell... i guess a little close... heh.]
17:06 michele: hehe
17:12 michele: imirkin: which applications do you usually run with DRI_PRIME=1 ?
17:14 RSpliet: valgrind-mmt :-D
17:16 imirkin: michele: none
17:16 imirkin: michele: i guess "most often", it'd be glretrace, but ... yeah. probably not relevant to your situation :)
17:17 imirkin: RSpliet: nice try, but mmt barely works with nouveau anymore
17:17 michele: ok
17:17 michele: thanks for the help imirkin
17:19 nyef`: Still undecided: Do I start buying hardware so that I can do the gf119 and g84 infoframe work myself, or do I leave it for other people to do?
17:19 mwk: nyef`: spoken like a true nouveau developer!
17:21 imirkin: nyef`: fwiw the gf119 might be tricky to buy - they were going pretty full-tilt with marketing obfuscation when that came out
17:22 imirkin: nyef`: i'd recommend starting by sending patches to make stuff work for the hw you *do* have... skeggsb will likely be able to fill the rest out himself if you ask him nicely.
17:22 imirkin: (or repeatedly)
17:22 nyef`: Yeah, I'm definitely considering sending the patches that I have out this week, possibly today, and there's no way that I'll have more hardware to work with before the weekend.
17:31 nyef`: The flipside to buying more hardware is that most recent non-laptop system I have other than the Mac Mini has a 32-bit CPU and an AGP slot, so I'd be looking to build out a more-or-less complete system, at which point it may as well be useful for non-nouveau-hacking purposes, which means buying more than a couple of video cards and a cpu+mainboard and hoping that my workbench power supply has enough oomph to run them.
19:56 nyef`: Hrm. $80 would get me cpu, mainboard, ram, and what should be a gf119, in time for me to find out if I have a compatible power supply this weekend. But no case, and it's nine-year-old hardware, meaning slow and obsolete, so of limited use going forwards. Upside: I'd have it this weekend. Downside: I'd have no real use for it afterwards. Prices on what should be just a gf119 are all over the map.
20:05 mwk: so remind me, how do you call RGB pixels going through a color LUT (for gamma etc.) vs RGB pixels going directly to a DAC?
20:05 mwk: it was something like true color vs direct color, right?
20:21 glennk: indexed color or paletted color
20:24 nyef`: Well, probably not: Indexed color typically involves very few bits (typically 8 or less) per pixel drawing from a much larger color depth, doesn't it?
20:32 mwk: not indexed, I mean the kind where pixels have R, G, B components, and each of them goes through CLUT separately
20:32 mwk: vs the kind without CLUT at all
20:33 nyef`: The same CLUT for each component, or separate?
20:33 mwk: separate
20:34 mwk: sort of
20:34 mwk: as in, there's one lut, but each entry has separate r/g/b values
20:35 mwk: so you have final pixel = { clut[mem_pixel.r].r, clut[mem_pixel.g].g, clut[mem_pixel.b].b }
20:35 nyef`: Three LUTs with parallel update?
20:36 mwk: effectively, yes
20:36 nyef`: So, it's not really directcolor, because there's a LUT involved.
20:36 nyef`: And pseudocolor isn't quite right, either.
20:36 RSpliet: indirectcolour! Are we searching for a marketing name or an established technical term?
20:37 nyef`: Some quick poking around (wikipedia) suggests that it's an accepted form of truecolor.
20:37 mwk: I want an established term to stuff into hwdocs
20:37 nyef`: RSpliet: established technical term.
20:37 nyef`: ... And then some maniac loads a bit-reversed palette into the LUTs. (-:
21:35 imirkin_: nyef`: you can do that with xcalib ;)
21:35 nyef`: Not particularly tempted right now, but I might at some point.
21:36 imirkin_: i used to use xcalib until i discovered xrandr --brightness
21:36 imirkin_: but it has some neat options
21:39 mwk: ... could I just set negative contrast?
21:45 imirkin_: michele: just saw your mailing list post - have your questions been answered - not sure if you wrote that before or after the irc discussion
23:00 imirkin_: nyef`: overall your patches make sense. esp the one changing drm core code should have been cc'd to dri-devel
23:00 imirkin_: nyef`: but it's not a bad policy to cc all those to dri-devel
23:08 nyef`: imirkin_: So noted. Since there will almost-certainly be a revised patch set at some point, would it be appropriate to add dri-devel to the cc list at that time?
23:09 imirkin_: yes
23:11 nyef`: ... Is there a requirement to subscribe to dri-devel, or does not subscribing just mean waiting for a bit while it sits in a mod queue?
23:12 imirkin_: just means you wait
23:12 nyef`: Okay, good. I don't really want to be dealing with that amount of message traffic at this point. (-:
23:33 imirkin_: hakzsam: if you have time, mind sending some patches for xf86-video-nouveau to update the maxwell shader latencies?
23:34 imirkin_: hakzsam: no need to do anything fancy, of course - just the minimum :)
23:35 hakzsam: imirkin_: not sure when I will have time, but I will do it at some point :)
23:35 imirkin_: hakzsam: ok. i'd like to do a release, would be nice to get that in there