| === hikiko|off is now known as hikiko | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| 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:08 |
|---|---|---|
| greyback | duflu: yep, we need to address this somehow | 09:09 |
| 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:18 |
| * alan_g hits the launchpad prerequisite limit again | 09:20 | |
| === chihchun is now known as chihchun_afk | ||
| * duflu repeatedly kills his machine with nouveau | 09:22 | |
| greyback | oh wow kernel4.8's scheduler is lousy, during build machine is unusable | 09:26 |
| 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 | 09:28 |
| === chihchun_afk is now known as chihchun | ||
| === marcusto_ is now known as marcustomlinson | ||
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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:12 |
| greyback | alan_g: confirmed fix, apprved | 14:16 |
| === dandrader is now known as dandrader|afk | ||
| === ondra_ is now known as ondra | ||
| attente | are there performance optimizations with using opaque rgb surfaces over rgba surfaces? | 15:32 |
| alan_g | attente: Qt compositor or Mir compositor? | 15:35 |
| attente | alan_g: Mir | 15:36 |
| alan_g | I'm not entirely sure of the current state, I think kdub did some work on it a while back. | 15:37 |
| attente | alan_g: actually i guess i need to know if either optimizes non-alpha surfaces | 15:39 |
| alan_g | For the qt compositor I'd ask greyback | 15:40 |
| 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:41 |
| greyback | Qt's renderer doesn't do any occlusion culling however | 15:42 |
| attente | greyback: does disabling blending help much performance-wise? | 15:42 |
| 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:44 |
| 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:46 |
| 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:48 |
| attente | ok, thanks greyback | 15:49 |
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| anpok | attente: i believe that qt claims that they do that in their scene graph (occlusion) | 18:05 |
| 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:06 |
| 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:09 |
| attente | ok | 18:16 |
| attente | kdub: isn't that traffic all on the gpu though? | 18:17 |
| kdub | not on mobile | 18:17 |
| attente | oh ok | 18:17 |
| === dandrader|afk is now known as dandrader | ||
| greyback | anpok: qt does not, nor does it claim, to do occlusion culling :) | 18:33 |
| 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:34 |
| 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:36 |
| * 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:37 |
| anpok | greyback: hm I thought that I read a blog post.. | 18:43 |
| anpok | but maybe that was more marketing | 18:43 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!