[09:08] <duflu> greyback: Sorry, forgot to test that option you suggested for nouveau. Such is the way with multi-part questions. It's worth noting though that the Nvidia binary driver we will only be able to support with newish GPUs. So any Nvidia chip more than a few years old like yours will always need to use nouveau anyway
[09:09] <greyback> duflu: yep, we need to address this somehow
[09:18] <alan_g> greyback: I found had to rework this (when I realised I had no tests), could you re-review? https://code.launchpad.net/~alan-griffiths/miral/identify-code-using-libmirserver-directly/+merge/309080
[09:18] <greyback> ok
[09:20]  * alan_g hits the launchpad prerequisite limit again
[09:22]  * duflu repeatedly kills his machine with nouveau
[09:26] <greyback> oh wow kernel4.8's scheduler is lousy, during build machine is unusable
[09:28] <duflu> greyback: Excellent, a second data point. Please talk to bschaefer who was scientifically trying to prove the same thing last week. Going back to 4.4 fixes it
[09:28] <duflu> I'm not sure if a bug has been logged
[14:12] <alan_g> greyback: I think this fixes the titlebar glitch you spotted: https://code.launchpad.net/~alan-griffiths/miral/miral-shell-window-titles/+merge/309470
[14:16] <greyback> alan_g: confirmed fix, apprved
[15:32] <attente> are there performance optimizations with using opaque rgb surfaces over rgba surfaces?
[15:35] <alan_g> attente: Qt compositor or Mir compositor?
[15:36] <attente> alan_g: Mir
[15:37] <alan_g> I'm not entirely sure of the current state, I think kdub did some work on it a while back.
[15:39] <attente> alan_g: actually i guess i need to know if either optimizes non-alpha surfaces
[15:40] <alan_g> For the qt compositor I'd ask greyback
[15:41] <greyback> attente: if you're using unity8/qtmir as the compositor, it will read the alpha state, and if opaque it will draw with blending disabled
[15:42] <greyback> Qt's renderer doesn't do any occlusion culling however
[15:42] <attente> greyback: does disabling blending help much performance-wise?
[15:44] <greyback> attente: it is more efficient on the GPU, no real difference to the CPU though
[15:44] <greyback> attente: are you seeing poor performance somewhere? Or just curious of current optimizations in Mir?
[15:46] <attente> greyback: i was asked about this in #gtk+, but didn't know. someone (Company) seems to be suggesting moving to just using rgba surfaces everywhere
[15:48] <attente> i guess it could be pretty slow with software rendering
[15:48] <greyback> attente: I wouldn't consider it a huge burden for any GPU rendering, but I can imagine a software renderer would suffer. A software renderer can do nice optimisations if it knows stuff is opaque (not draw what is occluded)
[15:49] <attente> ok, thanks greyback
[18:05] <anpok> attente: i believe that qt claims that they do that in their scene graph (occlusion)
[18:06] <anpok> but more importantly rgb allows the renderer to reorder stuff based on state changes instead of depth
[18:06] <anpok> so yes rgb should help alot
[18:09] <kdub> rgba blending also causes 3 hops on the bus (src-on, dest-on, dest-off)
[18:09] <kdub> so can cause bus congestion on devices that are sensitive to that
[18:16] <attente> ok
[18:17] <attente> kdub: isn't that traffic all on the gpu though?
[18:17] <kdub> not on mobile
[18:17] <attente> oh ok
[18:33] <greyback> anpok: qt does not, nor does it claim, to do occlusion culling :)
[18:34] <greyback> but it does do batching of opaque and non-opaque primitives, which saves a lot of work
[18:34] <greyback> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html for more details
[18:36] <greyback> kdub: "not on mobile" <- that's interesting. Would you have a link to a resource where I could learn about that?
[18:36] <kdub> greyback, will have to see if I can find something, nothing handy
[18:37]  * kdub just remembers optimizing that situation many moons ago for bus reasons
[18:37] <greyback> kdub: ack, no worries. Just in case you had something handy
[18:43] <anpok> greyback: hm I thought that I read a blog post..
[18:43] <anpok> but maybe that was more marketing