00:02skeggsb: not sure it needs stable, it'd be a module unload leak, hardly critical
00:03Lyude: up to you
00:04Lyude: it's a bit worrying because there's a dangling topology reference in that case
00:04Lyude: strangely though no connectors seem to leak, which isn't what I'd expect when that happens
00:04Lyude: (connectors as in drm_connector s, everything else certainly leaks)
00:06skeggsb: pulled it into my tree
00:06Lyude: skeggsb: cool, thanks!
02:05j2lapoin: Friday i suppose to receive gtx1050
02:10HdkR: Friday someone is going to be very disappointed in performance.
02:13joepublic: I have a GTX 760 that is satisfyingly fast. I even play video games on it.
02:15HdkR: joepublic: Sadly Maxwell2+ won't be quite as pleasant of an experience
02:15orbea: buy amd :P
02:16karolherbst: HdkR: I should annoy skeggsb with my reclocking patches again :D
02:16joepublic: I pulled an AMD card out to get this GTX 760, because the GTX 760 is accellerated in Trisquel and the AMD isn't.
02:16karolherbst: but seriously, it adds an option to force enable reclocking on maxwell 2 :/ usefull for laptops though
02:17orbea: joepublic: amd provides good open source support for modern cards, nvidia doesn't.
02:17orbea: not to say nouveau isn't cool :)
02:17HdkR: karolherbst: Force reclocking?
02:17joepublic: and, their trisquel driver is called "vesa"
02:17karolherbst: HdkR: no, it enables the reclocking through pstate on maxwell2
02:18karolherbst: mofoule parameter
02:20HdkR: karolherbst: I presume that works as long as the parameter is alive? So would work on Pascal?
02:20karolherbst: HdkR: no
02:20karolherbst: HdkR: pascal requires signed PMU
02:21HdkR: Maxwell2 doesn't? Did I miss something?
02:24karolherbst: it only requires it for fan control
02:24HdkR: Which is why it's only good for laptops then
02:25karolherbst: and fanless GPUs
02:26karolherbst: uhm, with passive cooling is what you would call it
02:27joepublic: modern cooking implement
02:50rhyskidd: skeggsb: great work on the turing bringup!
02:56imirkin: skeggsb: hey, iirc your theory was that we should stop using the sw channel in the ddx, right?
02:56imirkin: what was your counter-proposal again?
08:56AndrewR: amaizing, https://cgit.freedesktop.org/~hakzsam/nouveau/commit/?h=nouveau_perfmon&id=b43e1bc3207969642613ce07dd00d744943e4580 applies to 4.2, where rest of pm functions was not present, and fail for 4.4, where everything (but those sw methods for nv50) was added ..and refactored ....
14:04skeggsb: imirkin: counter-proposal was to fix the fifo interrupt handler...
14:05skeggsb: or make the ddx use the drm vblank stuff in the usual way..
14:05skeggsb: or, you know, use -modesetting where all that stuff is done properly and maintained.
14:06imirkin: skeggsb: what's the usual way for the drm vblank thing? uevents?
14:06skeggsb: well, waiting for the vblank and firing off the buffer copies when you get it or something like that
14:06skeggsb: instead of queuing the wait in the channel right before the copies, and having hw wait for it
14:07imirkin: skeggsb: well, fixing the fifo intr handler seems ideal. but we have no clue what's wrong with it, right?
14:08skeggsb: i sorta do, but find it hard to put the time into pre-fermi hw to figure it all out and make sure it works
14:08imirkin: something you could share with me perhaps?
14:08skeggsb: i *think* it basically races horribly with context switches for certain interrupts
14:08imirkin: that's consistent with what i've observed
14:09Sarayan: so by the time you're in the interrupt handler the gpu context has switched?
17:32j2lapoin: what happen when a x server is running on two different videocard/different monitor
17:33ajax: an angel gets its wings?
17:34imirkin_: that's way better than what i was going to say
17:35j2lapoin: i'm wonder if the server is running under I915 or Nouveau
17:36j2lapoin: as you can see https://paste.linux.community/view/a5c3e045
17:36j2lapoin: dam it
17:38j2lapoin: would like to know if my server x is under i915 or nouveau
17:50imirkin_: [ 7.483] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) Sandybridge Desktop
17:50imirkin_: that'd be intel.