13:31 Yoshimo: can someone tell me why OpenGL is not available for my 980 any more?
13:31 Yoshimo: https://pastee.org/7tcng
13:41 Calinou: Yoshimo: did you try rebooting?
13:42 Yoshimo: yes, and i have that issue for quite some time now
13:42 Calinou: with the NVIDIA driver, sometimes I lose the ability to start OpenGL applications after an update
13:42 Calinou: and need to reboot
13:42 Calinou: but I guess that doesn't apply to open source drivers
15:42 karolherbst: mwk: interessted in an envytools port to mac os x ?
15:43 karolherbst: Yoshimo: dlopen of /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
15:43 karolherbst: Yoshimo: I think your mesa is screwed :p
15:46 Yoshimo: possible, is swrast necessary though? I thought that was just a fallback if the hardware isn't properly supported
15:50 imirkin: glamor fails to load
15:50 imirkin: chances are your mesa is messed up
15:51 imirkin: e.g. you tried to make install over another pre-existing distro installation
15:51 imirkin: or who knows
15:53 karolherbst: Yoshimo: LD_DEBUG=libs glxinfo
16:22 imirkin: skeggsb: did you kill it? https://bugzilla.kernel.org/show_bug.cgi?id=120591 - you were messing with fbcon recently no? (to fix those stupid cursor overruns)
17:50 mwk: karolherbst: sure, why not
18:03 karolherbst: mwk: k, then I guess I try to port that stuff. will have enough time on the train to do things which don't involve using linux :p
19:03 Yoshimo: karolherbst: https://pastee.org/p4q5q
19:22 karolherbst: mwk: seems like pciaccess doesn't really work on mac os x :/ pci_device_vgaarb_init doesn't get exported for whatever reasons :(
19:23 karolherbst: Yoshimo: meh, it aborts too early :/
19:28 Yoshimo: karolherbst: yea it is a nasty case
19:29 karolherbst: Yoshimo: well the issue is, your system is broken. I am sure there is somewhere an old library installed
19:30 Yoshimo: mhm, the question is how to find that beast
19:30 imirkin: Yoshimo: moral of the story: don't try to outsmart the distro packaging system.
19:30 imirkin: Yoshimo: remove /usr/local/lib from your ld.so.conf
19:30 imirkin: and run ldconfig
19:32 karolherbst: and _never_ install something system wide outside of /usr/local
19:32 karolherbst: never ever
19:32 karolherbst: if you did, remove all the files :p
19:33 imirkin: oh nice. that fixes the mega-flickering i had in talos. now it's back to the regular ol' bugs that i had with it on fermi too.
19:35 imirkin: hmmmm.... though i wonder if it's right
19:35 imirkin: or if i should just only ever do the dominate check for instructions dominated by the tex...
19:36 karolherbst:is wondering if we will be able to switch the GPU used for OpenGL on the fly on Linux in the future :/
19:37 karolherbst: like when plugging in the charger -> application move to the dedicated GPU automatically
19:40 Yoshimo: that did it, thanks guys
19:43 Yoshimo: or almost, fell back to llvmpipe but glxinfo returns valid data now
19:45 imirkin: for help operating your distro, you should consult a distro-specific support channel
19:47 Yoshimo: i assumed it is a driver issue so i came here
19:47 Yoshimo: it is better than before so i am gratefull
19:47 imirkin: the issue is that you don't have the right version of mesa installed
19:47 imirkin: i'm guessing you did a manual install into /usr/local/lib but something got subtly messed up
20:22 airlied: karolherbst: for running applications, unlikely
20:22 karolherbst: airlied: well yeah, a new API would be needed for that, but on mac os x there is such, and you can actually switch the gpu for running applications which implements that stuff
20:23 imirkin: airlied: any opinions on https://bugs.freedesktop.org/show_bug.cgi?id=96570 ?
20:23 karolherbst: but on macs it is also hard muxed, so the entire desktop moves
20:23 karolherbst: so adding such an API isn't _as_ difficult I think
20:24 karolherbst: airlied: on mac os x an application gets an notification that the GPU got switched and the application needs to reparse the extensions and adjust their rendering path, but most of the OpenGL context gets moved by the system
20:24 karolherbst: except some minor things
20:26 airlied: karolherbst: I'm nearly sure they just shut down the context
20:27 airlied: and the app pretty much restarts
20:27 karolherbst: airlied: nope, it doesn't
20:27 airlied: got a link to their extension?
20:27 airlied: since GL doesn't have any capabilites for this
20:27 karolherbst: there is no gl extension for that
20:27 airlied: so GL apps wouldn't work
20:27 karolherbst: it is done throug outside means
20:27 karolherbst: but there are some docs on that
20:27 airlied: if I'm running a normal OSX ported game it won't work
20:28 airlied: since it definitely would need app support
20:28 karolherbst: you need to enable it in the piist
20:28 airlied:doesn't know of any apps that reparse extensions etc
20:28 karolherbst: that you support that thing
20:29 airlied: oh I'd be interested in the docs for it
20:29 karolherbst: google messes up now, but I shwoed those things to mupuf once
20:30 karolherbst: ahh
20:30 karolherbst: "NSSupportsAutomaticGraphicsSwitching: YES" is the proerty
20:30 karolherbst: https://developer.apple.com/library/mac/qa/qa1734/_index.html#//apple_ref/doc/uid/DTS40010791
20:30 karolherbst: maybe this?
20:31 karolherbst: airlied: basically it works like that: if you use OpenGL the dedicated GPU is always used, except when you specify NSSupportsAutomaticGraphicsSwitching: YES
20:31 karolherbst: then depending on stuff, your application might get moved to the integrated one for whatever reason
20:31 karolherbst: ahh
20:31 karolherbst: https://developer.apple.com/library/mac/technotes/tn2229/_index.html
20:31 karolherbst: this is the thing
20:32 karolherbst: "Once your OpenGL context is configured to allow the hardware renderer to change, you will need to detect these changes by responding to Quartz Display Notifications (if you are not using NSOpenGLView) or by overriding -update (if you are using an NSOpenGLView subclass) in order to properly detect functionality changes. If you do not, then your OpenGL drawing may fail in various potentially catastrophic ways. Whenever the
20:32 karolherbst: virtual screen changes, the capabilities of the video card you are currently rendering to can change, so you must re-query those capabilities and adjust your drawing paths as necessary to support the newly active GPU."
20:32 airlied: ah interesting, someone should write that for Linux, and then watch it be ignored :)
20:33 karolherbst: also: "It is highly recommended that you use Framebuffer Objects over PBuffers whenever possible. If you must work with PBuffers you need to ensure that the virtual screen of the PBuffer uses the same device of the context that you wish to draw its contents into. When the virtual screen of a PBuffer changes, its conents will be lost, so you need to update the PBuffer's contents at that time. Examples for AGL (Listing 6) and CGL
20:33 karolherbst: (Listing 7) follow."
20:33 karolherbst: airlied: :D
20:35 karolherbst: maybe this is even the most important thing from a technical point of view: " Finally, while all OpenGL objects (textures, buffer objects, etc) will retain their contents, display backing stores and PBuffers will need to be updated to ensure their contents remain valid (see PBuffers vs OpenGL Textures and Buffer Objects)."
20:36 karolherbst: airlied: well, the thing is, on mac books you have the display muxed and external dispalys are hardwired to the dedicated GPU
20:36 karolherbst: airlied: so if you would like to plug in your external display, you have to switch the GPU
20:36 karolherbst: or do some reverse prime messup
20:37 karolherbst: anyway, it might be a good idea to be able to switch the rendering device on the fly
20:37 airlied: the main thing is switching the compositor
20:38 glennk: airlied, you mean for the case where you disable the internal display and plug in a monitor connected to the dgpu?
20:39 airlied: glennk: no even when the internal display is runnig
20:39 airlied: they switch the compositor to the external GPU
20:39 glennk: do they switch the internal display routing to the dgpu as well then?
20:40 karolherbst: glennk: yes
20:40 karolherbst: all applications
20:40 karolherbst: the entire desktop
20:40 karolherbst: sometimes you see a small flicker...
20:41 karolherbst: but usually this works instantly
20:41 glennk: i guess they want to power down the intel gpu then
20:41 airlied: they have special hw to switch the displays
20:41 karolherbst: glennk: yeah
20:41 karolherbst: glennk: when I switch to the nvidia gpu, the battery lifetime decreaes by like 5% :/
20:41 airlied: not sure how they do with edp
20:41 airlied: but with lvds they set the refresh rates different on the intel/nvidia
20:41 glennk: turns out intel gpus aren't great at power efficiency
20:42 airlied: and then had hw to find the cross over vblank and switch
20:42 RSpliet: airlied: yuck!
20:42 glennk: reminds me of voodoo sli for some reason
20:43 karolherbst: anyway, that is something which might come in handy for laptops where the external ports are wired to the dedicated gpu
20:43 karolherbst: allthough
20:43 karolherbst: it is always ugly there
20:44 airlied: I wonder how they do the buffer allocations
20:44 airlied: I assume they shut down the nvidia vram
20:44 glennk: presumably per driver, and have move hooks
20:44 airlied: so they must keep track in some shadowy area all the textures/buffers/fbos
20:45 airlied: and copy them over behind the scenes intel<->nvidia
20:45 karolherbst: airlied: the document talks a lot about virtual displays
20:45 karolherbst: airlied: I guess they abstract all that stuff away
20:45 imirkin: airlied: or swap them all out first
20:45 karolherbst: airlied: and just keep the important bits in the ram
20:45 karolherbst: or something like that
20:45 airlied: karolherbst: but it would be a major waste of RAM
20:45 glennk: what imirkin says
20:45 airlied: to keep a second copy
20:45 airlied: swapping sounds slow though, and it's really fast
20:46 airlied:wrote the code for X to do it
20:46 airlied: doing it for GL seemed a step further than I was crazy
20:46 glennk: swapping out 2GB takes 1/10th of a second or so on pcie3 hw
20:46 karolherbst: airlied: well...
20:46 karolherbst: airlied: my 8GB aren't enough...
20:47 imirkin: airlied: it's really fast when vram is full?
20:48 glennk: wonder what bit handles the tiling format conversions
20:48 karolherbst: imirkin: well
20:48 karolherbst: imirkin: the intel GPU stuff is in RAM anyway :p
20:48 karolherbst: ...
20:48 karolherbst: ohh wait
20:48 karolherbst: the solution :D
20:48 karolherbst: it's in ram anyway
20:52 airlied: karolherbst: but it's in RAM tiled
20:52 airlied: you'd have to use the intel GPU to put it linear
20:52 airlied: then put it into VRAM
20:52 airlied: also you'd have to recompile all the shadres
20:52 airlied: though I suppose you could do that up front
20:53 karolherbst: airlied: well, it's apple we are talking about, I am sure they have some fancy hw to do that kind of stuff or something
20:53 karolherbst: or maybe they just convert it on the fly
20:53 karolherbst: it isn't like they support a lot of hw combinations
20:55 airlied: ah well time for someone to write a GLX extension :)
20:55 glennk: i think a signal to tear down/recreate context for apps is about the only sane way
20:55 airlied: glennk: robustness pretty muhc does that
20:55 imirkin: GLX_i_am_on_apple_hw
20:56 glennk: airlied, right, its just missing the actual signal in advance
20:56 airlied: imirkin: it would be useufl to solve reverse prime stupids
20:56 airlied: glennk: yup that would require an X event
20:56 glennk: basically an opt-in extension
20:56 karolherbst: well
20:56 karolherbst: GLX could still do that, right?
20:56 imirkin: airlied: like how you render using prime offloading, copy to the main gpu, and then copy back with reverse prime?
20:56 airlied: imirkin: yup
20:56 karolherbst: :D
20:57 imirkin: airlied: i'd prefer hw cursor to work before that one got fixed
20:57 imirkin: i use the cursor a lot more often than i play 3d games
20:57 karolherbst: well apply hw is a special case here because you can use both gpus for the internal display
20:57 karolherbst: *apple
20:58 karolherbst: no idea if that applies to any laptop otherwise
20:58 airlied: karolherbst: lots of older optimus laptops do it
20:58 airlied: without the nice hw
20:58 airlied: so when you switch GPU it's all kinda of ugly
20:58 karolherbst: uhh
20:58 karolherbst: I see
20:59 karolherbst: so what we basicaly need is an extension to notiy the application: hey, gpu switched, revalidate stuff, then we could move everything to the new gpu and it will become less ugly
20:59 glennk: airlied, i guess the kernel can play sync-to-vblank games a bit to reduce the flicker for that hardware?
21:00 karolherbst: (especially because like qt5 applications use OpenGL sometimes)
21:00 glennk: i guess the notification is per display too
21:00 karolherbst: I highly doubt that
21:00 karolherbst: you either use one or the other gpu
21:00 karolherbst: never both
21:00 karolherbst: at least on apple hw
21:01 karolherbst: if you force the internal GPU, you can't plug in an external display
21:01 karolherbst: won't work
21:02 glennk: fairly sure that case works, it just copies the output
21:02 karolherbst: nope
21:02 airlied: glennk: no apple doesn't
21:02 glennk: i'm more concerned with the general mix of igpu/dgpu and dgpu/dgpu
21:03 airlied: apple only displays on external from exteranl gpu
21:03 karolherbst: which is kind of stupid though
21:03 glennk: i meant app can render on any of them
21:03 karolherbst: glennk: nope
21:03 karolherbst: glennk: everything uses the same gpu
21:03 karolherbst: glennk: if one application requires the dedicated, everything moves
21:04 karolherbst: there is even an API for that to check the status
21:04 glennk: thats not what happens on my '09 mb pro though
21:04 karolherbst: and you get even told which applications this is
21:04 karolherbst: glennk: well I have a '13 MBP here
21:05 karolherbst: glennk: wasn those '09 with the switch gpu and reboot thing?
21:05 karolherbst: or logout/login?
21:05 glennk: it had to restart the compositor to switch so logout/login
21:05 karolherbst: right
21:05 karolherbst: forget that
21:05 karolherbst: we don't talk about this old crap :p
21:06 karolherbst: I mean on my MBP the switch is instantaneous
21:06 karolherbst: no logout
21:06 karolherbst: nothing
21:06 karolherbst: one frame: intel, next frame: nvidia
21:06 karolherbst: every application still running
21:07 glennk: well, "instantaneous" as in it switches in between some arbitrary future frame
21:07 karolherbst: right
21:07 karolherbst: but you don'T see it
21:07 karolherbst: usually
21:07 glennk: it still takes time to switch
21:07 karolherbst: ...
21:07 karolherbst: <1second
21:07 karolherbst: usually it is more like 0.2seconds I think
21:07 karolherbst: it is pretty fast in any case
21:08 karolherbst: but the point is
21:08 glennk: thing is it doesn't matter how long it takes as long as it doesn't hitch
21:08 karolherbst: every application moves to the new gpu
21:08 karolherbst: though it doesn't matter much for those, because it is all abstracted away and the rendering kind of happens in an odd way on mac os x
21:09 airlied: karolherbst: what about apps that don't support switching?
21:09 karolherbst: airlied: dedicated is forced
21:09 airlied: don't they block the switch?
21:09 karolherbst: yes
21:09 karolherbst: they do
21:09 airlied: so if run glxgears it wno't switch?
21:09 karolherbst: well
21:09 karolherbst: usually you don'T have X
21:09 karolherbst: but I guess it wouldn't switch then
21:10 glennk: thing is on osx so much stuff uses the frameworks which all support the context switching
21:10 karolherbst: yeah
21:10 glennk: so in practice not a lot of apps need updating
21:10 karolherbst: only if you use OpenGL you have to implement it directly
21:10 karolherbst: and set the flag in the plist
21:10 glennk: and most of those uses are fullscreen games which want dedicated gpu anyway
21:11 karolherbst: well
21:11 karolherbst: if you switch to battery, the user don't want that
21:11 karolherbst: so you can force the internal on battery
21:11 glennk: well, not while the app is running though
21:11 karolherbst: this applies for every OpenGL application, and some don't need a dedicated gpu
21:12 karolherbst: glennk: if they implement it, then yes
21:12 glennk: ...
21:12 karolherbst: you don't outsmart the user :p
21:12 karolherbst: if the suer set: force internal on battery, you use the internal on battery
21:12 karolherbst: and if a stupid app prevents that, notify the user
21:13 glennk: s/stupid app/flash/ =-)
21:13 karolherbst: :D
21:13 karolherbst: well in any case
21:13 karolherbst: I think on mac os x you don't draw directly like you would do in X anyway
21:14 glennk: uh?
21:14 karolherbst: the compositor is... odd
21:15 karolherbst: you basically draw into a Quartz context
21:15 airlied:always meant to restart my migrating X resources between GPUs
21:15 karolherbst: which gets drawn to the display by the compositor
21:15 glennk: uh not really, its just an app private buffer quartz draws into
21:15 glennk: the compositor just composites pixels
21:16 glennk: heck a good chunk of the time quartz2d is still sw rendering
21:16 karolherbst: quartz2d is somethign else
21:16 karolherbst: it is a bit more complicated that this though
21:17 karolherbst: I meant "Core Graphics" in this case
21:17 glennk: ah thats a different thing
21:17 karolherbst: yeah, but usually meant if you say Quartz
21:17 karolherbst: but, yeah, I should have said core graphics :p
21:17 karolherbst: anyway
21:18 karolherbst: basically you have a PDF layer between the display and your application
21:18 karolherbst: well
21:18 karolherbst: PDF-like
21:18 karolherbst: and everything gets added to this first, before it gets actually drawn to the display
21:18 glennk: now you are talking about quartz2d
21:18 glennk: and no, its quite immediate mode
21:19 glennk: it is based off of the pdf display model
21:19 karolherbst: ahh right
21:19 airlied: http://www.geeks3d.com/20131105/mac-os-x-and-opengl-virtual-screens/
21:19 airlied: we need to fix xinerama as well :-P
21:20 glennk: airlied, fun with all the different igpu/dgpu and dgpu/dgpu combinations
21:20 glennk: as well as dumb displays like the usb dongles
21:21 karolherbst: uhhh wow
21:21 karolherbst: airlied: that complicates things again
21:21 karolherbst: airlied: but seriously, for apple I guess this was really easy to implement, because their entire graphics stack was kind of indirect enough to support this fancy things...
21:23 airlied: I should probably consider getting back to this at some point
21:23 airlied: I kinda burned out on it last time once I got offload/output slaves working
21:24 karolherbst: airlied: you know what? we can simply ignore that for X
21:24 karolherbst: because I am sure with X it will be toooo painful
21:24 glennk: x is probably closer to supporting this than wayland is
21:24 karolherbst: and I am not even sure if we would be able to do that with wayland
21:24 karolherbst: ..
21:24 karolherbst: yeah
21:25 karolherbst: glennk: was thinking the same while I was half way through my sentence :D
21:25 airlied: for X I had it mostly working
21:25 airlied: thinking about wayland made me hide again
21:25 airlied: it would need EGL work
21:25 glennk: a per display output signal to apps (app frameworks) which gpu is preferred
21:25 karolherbst: there is no reverse prime for wayland yet, right?
21:25 karolherbst: :/
21:25 airlied: karolherbst: nope
21:26 airlied: at least for gnome-shell it was a lot of work
21:26 airlied: someone is doing the ground work now
21:26 karolherbst: mhhh
21:26 airlied: mutter/clutter/cogl stack was too muhc of a mess
21:26 airlied: so I think jadahl is collapsing it
21:26 karolherbst: I kind of get a bad feeling about wayland regarding this
21:27 karolherbst: I think it was a _very_ smart move of apple to add the concept of virtual displays and just put a layer in the graphics stack
21:27 karolherbst: though I have no idea how the perf impact is
21:28 glennk: osx gl perf sucks
21:28 karolherbst: well
21:28 karolherbst: do we know why?
21:28 airlied: I'm assuming overheads and lower quality drivers
21:28 glennk: many reasons, but approximately a mile high stack of layers doesn't help
21:28 karolherbst: right
21:28 glennk: can easily see some of it with their own perf tools
21:29 glennk: i think people in general overstate how heavy it is for most apps to just tear down and recreate their GL contexts
21:29 airlied: glennk: the problem is reloading all the txture data
21:29 glennk: games are a special case with tons of data
21:30 karolherbst: games will end up not supporting this
21:30 airlied: having to drop back to loading the whole game at any point in the game and getting back to that point
21:30 glennk: but most apps its all dynamically composed content, very light on data and number of shaders compiled
21:30 airlied: seems like it would be unfun
21:30 karolherbst: or let's say: some games won't
21:30 airlied:assumes only things like adobe apps support this
21:30 karolherbst: some games even are a mess while changing some little graphic settings...
21:31 airlied: should do a proof of concept switching between hw/sw renderers
21:31 glennk: i don't think its too common to have games running while changing display configuration
21:32 karolherbst: I meant internal graphic settings in the games
21:32 karolherbst: some game engine support changing every setting on the fly without reloading screens
21:32 karolherbst: some games even change texture quality within a second
21:33 karolherbst: and then there are games which tell you to restart the entire game
21:33 glennk: well the games that mostly stream in their data its not an all at once deal to change things
21:59 zgwolfe: So... I've been racking my brain for the past few weeks and I am hoping someone here can point me in the right direction. I have an NVidia 760 and Nvidia 950. The 950 will not work with any monitor plugged into it. I can't seem to find any solution. (I'm on Fedora Science -- 23).
22:01 imirkin: zgwolfe: is it a GTX 950? i.e. GM206?
22:01 zgwolfe: Yes
22:01 imirkin: and what kernel are you on?
22:02 zgwolfe: 4.4x I think, If you mean the core linux kernel.
22:02 zgwolfe: I do appologize in advance, still rather new to Linux
22:02 imirkin: i do.
22:03 imirkin: and how are you plugging the monitor in?
22:03 zgwolfe: I have tried multiple methods. HDMI, VGA, and DVI. None work.
22:03 imirkin: hmmm ok. can you pastebin dmesg and xorg logs?
22:04 zgwolfe: I'll have to collect the dmesg. Never used it. But I know where the xorgs are.
22:05 imirkin: wait
22:06 imirkin: do you have both of the GPUs plugged in at the same time?
22:06 zgwolfe: Yes
22:06 imirkin: and the 760 is the primary?
22:06 zgwolfe: Indeed
22:06 imirkin: in that case i probably just need the xorg log
22:10 zgwolfe: http://pastebin.com/3Jq95M3t
22:10 zgwolfe: http://pastebin.com/GGUzEEp
22:10 zgwolfe: http://pastebin.com/TWRUMF6c
22:10 zgwolfe: xorg.0, xorg.1, xorg.9
22:11 imirkin: zgwolfe: ok cool. and now do "xrandr --listproviders"
22:11 zgwolfe: Provider 0: id: 0x90 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 4 associated providers: 1 name:nouveau
22:11 zgwolfe: Provider 1: id: 0x48 cap: 0x3, Source Output, Sink Output crtcs: 4 outputs: 5 associated providers: 1 name:modesetting
22:12 imirkin: xrandr --setprovideroutputsource 1 0
22:12 imirkin: and then you should have a bunch of new outputs in xrandr output
22:15 zgwolfe: l still see the same outputs
22:15 imirkin: pastebin the output of "xrandr"
22:16 imirkin: airlied: since when does modesetting support reverse prime? and does that support rely on glamor?
22:17 zgwolfe: http://pastebin.com/f77JU4Bh
22:17 imirkin: airlied: i mean does modesetting support being the remote output in a reverse prime thing? i assume so since it has sink/source output, but ...
22:18 imirkin: zgwolfe: hmmm... it SEEMS like it's working ...
22:18 imirkin: you have a screen connected via DVI to the GTX 950 right?
22:19 zgwolfe: I do
22:19 imirkin: that screen is not lit up right now?
22:19 zgwolfe: I can move the mouse over there, display config has always detected the monitor, the monitor acts like its on (the power light changes) but its black. Not asleep however.
22:20 imirkin: hmmmmmmm ok
22:20 imirkin: oh i wonder if that's a kernel before i fixed something....
22:20 imirkin: can you try placing it "below" your other screens
22:20 imirkin: rather than next to them?
22:21 zgwolfe: I tried placing it above once before and it royally screwed the graphics, but never below
22:21 zgwolfe: and when I say royally screwed, all screens corrupted and it was unusable.
22:22 imirkin: hm. well anyways, my fix went into v4.3
22:22 imirkin: and you're currently on v4.5.6
22:22 zgwolfe: Well the graphics didn't corrupt but it didn't work
22:23 zgwolfe: I have tried different monitors and it has the same affect FYI
22:23 zgwolfe: different models I mean
22:23 imirkin: and it would only have been an issue if you were going over 8k in width
22:23 imirkin: which you weren't
22:24 zgwolfe: I wonder if switching the positions of the cards would matter, with the 760 being secondary.
22:24 imirkin: well the only thing i can think of is that modesetting requires glamor (and thus GL) to be working
22:24 imirkin: i'd really recommend against that
22:24 zgwolfe: Thought as much lol
22:24 imirkin: to get acceleration on the GTX 950 you can update to kernel 4.6
22:25 imirkin: it could be that modesetting requires glamor to have working reverse prime
22:26 zgwolfe: I will give it a shot,
22:26 imirkin: you also need to update your linux-firmware package
22:26 imirkin: (make sure you have stuff in /lib/firmware/nvidia)
22:29 zgwolfe: there is
22:29 zgwolfe: Just checked for updates and I don't have anything,
22:30 imirkin: ok
22:31 zgwolfe: Thanks for the advice!
23:34 imirkin: hakzsam: hm ok, so now i can reproduce the flicker "fix" thing in talos with vbo push thing = 0. going to investigate.