[01:49] This is odd. Why is Xorg slower on Haswell than Sandybridge?! [01:50] Mir has no such problems [02:06] duflu: What test? [02:06] duflu: Also, fast Sandybridge vs slow Haswell? [02:07] RAOF: I swapped my drive out of an HD2000 system into an HD4400 [02:07] And it stutters quite a bit [02:08] Oops... HD4600 [02:09] I'm suspicious of: [ 1.949] (**) intel(0): "Tear free" disabled [02:09] But can't remember what it used to be === chihchun_afk is now known as chihchun [09:14] there didn't used to be a tear free option [09:14] and it was always disabled :p [09:57] mlankhorst: Just guessing... [09:57] But if I wanted a real answer I would debug Compiz [09:57] trying to avoid that [09:58] alan_g: Any hints as to how to force gmock to match 16 elements passed to a GLfloat* parameter? :) [09:59] duflu: write a bespoke matcher? [09:59] alan_g: That's what I thought, but attempts so far don't even compile [10:00] And the docs are too vague to explain why [10:00] racarr has written quite a few around the input tests [10:05] On second thoughts, this test probably should not exist using mocks. It assumes too much about the internals of the class [10:25] Talking about assuming implementation details: Does anyone think SocketSessionTest.basic_msg is a readable or useful test? [10:25] * alan_g wants to delete it [10:28] alan_g: If you can't read it then that doesn't bode well. I though you knew that stuff better than most [10:28] +t [10:28] * duflu wanders off === chihchun is now known as chihchun_afk [11:10] kdub: asleep? ;) === chihchun_afk is now known as chihchun [13:02] alf_: can you take a look? I'm getting happier with it (but it may be just that I'm getting used to it): https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351 === alan_g is now known as alan_g|lunch [13:03] alan_g|lunch: sure === alan_g|lunch is now known as alan_g === chihchun is now known as chihchun_afk [14:11] alf_: a matter of curiosity, we don't have triple buffering on at the client level do we ? === dandrader is now known as dandrader|afk [14:17] kgunn: we don't === alan_g is now known as alan_g|afk [14:17] kgunn: alan_g: AFAIK, the code supports triple buffering for client surfaces. What is blocking it? [14:21] alf_: so i was just thinking, wrt side stage, where the code relies on snapshotting when "closing"/"revealing" [14:21] and that the pipeline is stalling [14:21] e.g. its gotta read from the buff [14:21] before it let's it continue rendering [14:21] & swapping buffs [14:21] whereas, triple buffering would at least help alleviate [14:22] this getting in at least one extra render while you're still reading [14:22] (all theory of course) [14:22] ricmm: ^ === dandrader|afk is now known as dandrader [14:26] kgunn: are we seeing an actual slowdown when the sidestage is revealed/closed? [14:26] alf_: yeah there's definitely some stall/jank at times [14:27] if you flash devel-proposed, it has sidestage...N10 of course [14:28] kgunn: And I am assuming that snapshotting been identified as the culprit or is this a theory? [14:28] alf_: all theory [14:32] alf_: do you have a N10? [14:33] ricmm: yes [14:33] can you give it a go with the latest image [14:33] you'll have the feel of whats happening [14:33] ricmm: ok === alan_g|afk is now known as alan_g === chihchun_afk is now known as chihchun [15:19] alf_: sorted tabs (and placated valgrind over the SocketSessionTest.basic_msg_is_received_and_dispatched test) [15:20] alan_g: ok === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g === dandrader is now known as dandrader|lunch === dandrader_ is now known as dandrader === alan_g is now known as alan_g|EOD === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [20:16] do you guys have trouble getting useful backtraces out of gdb on the device (arm)? [20:22] dandrader, sometimes [20:23] kdub, any trick I can do to improve it? [20:26] dandrader, unfortunately no, havent spent a lot of time looking