[01:06] <racarr> *pant*
[01:06] <racarr> 2/3rds done!
[01:07] <racarr> unfortunately diff is already almost 5000 lines, wondering if I should try and propoe part of the branch even if it doesn't make sense on its own
[05:57] <racarr> Happy weekly meeting!
[05:57] <racarr> *streamers and loud horns*
[06:02] <thomi> anyone joining me in the weekly meeting?
[06:03] <thomi> racarr: ?
[06:03] <hikiko> thomi, in a sec
[06:04] <racarr> thomi: Link?
[06:04] <thomi> https://plus.google.com/hangouts/_/a9abbc8e84f85360faaab30196768ca2d9129d09?authuser=1
[06:07] <thomi> kdub: ?
[06:07] <thomi> RAOF: ?
[06:24] <alf__> thomi: https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211
[06:24] <alf__> thomi: https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/718/console
[09:09] <alan_g> alf__: @refactor-compositing-strategy - do you agree with me that the resource holding problem also applies to the "overlay rendering" we were discussing yesterday?
[09:14] <alf__> alan_g: yes
[09:15] <alan_g> alf__: I'll roll that fix in too. ;)
[09:16] <alf__> alan_g: although it's not probable (but it's possible) that the overlay render will actually need to do something that requires resource holding
[09:17] <alf__> alan_g: Did you get a chance to talk to racarr about the utility of the OverlayRenderer?
[09:17] <alf__> (vs just rolling a new CompositingStrategy)
[09:18] <alan_g> alf__: I didn't - there are more urgent questions.
[09:18] <alf__> alan_g: I am asking because perhaps racarr will agree to that, so we can get rid of OverlayRenderer...
[09:20] <alf__> alan_g: and save you the trouble of changing OverlayRenderer
[10:45] <hikiko> the mir/examples are only for the gbm platform?
[10:58] <alf__> hikiko: no
[11:00] <hikiko> alf__, I want to get 100% sure that there isn't something in my CMakeLists.txt that causes the render_to_fb example to compile with gbm
[11:00] <hikiko> it seems to compile with sdl
[11:01] <alan_g> alf__: when you have time could you look over https://code.launchpad.net/~alan-griffiths/mir/refactor-compositing-strategy/+merge/164945
[11:02] <alf__> alan_g: sure
[13:23] <greyback> kdub: hey, an progress with improving performance on Galaxy Nexus?
[13:41] <hikiko_lunch> alf__, render_to_fb is a standalone prog or i have to run something else before i start it?
[13:44] <hikiko> There are some brief guides describing how to run the Mir binaries once you have
[13:44] <hikiko> them built. <- where?
[13:47] <alan_g> hikiko: render_* are standalone programs
[13:48]  * alan_g thinks this is https://bugs.launchpad.net/mir/+bug/1108715 again
[13:49] <hikiko> cool, but where are instructions on how to run mir? I found build instructions in several places (eg doc, readme) but I can't find how to run clients etc
[13:50] <hikiko> yes :D alan_g that's exactly my question
[13:51] <alan_g> hikiko: The documentation that does exist is under http://unity.ubuntu.com/mir/ - e.g. "Using Mir on a PC"
[13:53] <hikiko> pfff blind :( so I just start the server and then  I run the client :) thank you alan_g !
[13:54] <alan_g> hikiko: np - BTW you're welcome to propose improvements to the documentation. (It needs improvement!)
[13:55] <hikiko> but for the render_* I don't need to run the server isn't it?
[13:55] <alan_g> hikiko: no, they use the mir library directly
[13:55] <hikiko> ok :)
[13:55] <hikiko> thank you!
[13:57]  * alan_g is always glad to help.
[13:57] <hikiko> :D
[15:00] <kdub> greyback, no, haven't looked further into that... maybe we should file a bug?
[15:00] <greyback> kdub: true, I'll make one
[15:14] <greyback> kdub: https://bugs.launchpad.net/mir/+bug/1182930 do you need more info?
[15:15] <alf__> status: more lttng work, started investigating mir stress test crashes
[15:17] <kdub> greyback, looks like enough info to start
[15:17] <greyback> ok
[15:20] <kdub> status, cleanup branch, measured our client's start times in comparison to surfaceflinegr, working on the glmark2 numbers now
[15:24] <kgunn> greyback: just curious...is the perf drop on n10 & galaxynexus? or more noticeable on one than the other
[15:25] <greyback> kgunn: Mir not functioning on N10, so I cannot say. I only have 1 device
[15:25] <greyback> that's running Mir correctly right now
[15:25] <kgunn> greyback: ack
[15:26] <greyback> kgunn: probable perf is better. racarr has N4, he can probably say what perf is like
[16:54] <racarr> Morning
[16:55] <alan_g> Afternoon
[17:12] <racarr> today will still be working on this input branch I was on all day yesterday
[17:12] <racarr> should hopefully be wrapping it up around lunch time
[17:37] <kgunn> racarr: just curious....on nexus4, do you see the same drop for inprocess shell vs out of process (same as galaxynexus)
[17:41] <racarr> Not with
[17:41] <racarr> a cursory glance
[17:42] <racarr> thats interesting
[17:43] <racarr> I have had a speculation for a while
[17:43] <racarr> that perhaps a many threaded process
[17:43] <racarr> is more difficult to schedule
[17:43] <racarr> than multiple processes
[17:43] <racarr> i.e. the assumption has always been that inprocess shell would give us a performance boost
[17:43] <racarr> but there is no reason why that has to be true.
[17:45] <racarr> no reason obvious to me*
[17:47] <kgunn> racarr: mmm, guessing the theory is...its thread switching vs process (context) switching
[17:48] <kgunn> racarr: so you didn't see a visible drop on nexus4...hmm
[17:48] <kgunn> kdub: ^
[17:49] <kdub> ohhh
[17:49] <kdub> yeah that could explain it :/
[17:49] <kdub> well, rather, gpu context switching is more of a concern to me
[17:50] <kdub> because i'd guess the newer cores do that better than the older ones
[17:50] <kdub> like, i know the nexus4 gpu is 'hyperthreaded' (if i can overload that term :) )
[17:53] <racarr> kgunn: thread swithcing is definitely cheaper
[17:53] <racarr> than process switching though...
[17:53] <racarr> but, maybe that overhead is small for us
[17:53] <racarr> I have two theories (if it is in fact the case)
[17:53] <kgunn> racarr: for sure
[17:54] <racarr> 1. I don't know how the kernel scheduler works anymore but
[17:54] <racarr> from a high level point of view if you are trying to interleave multiple processes
[17:54] <racarr> the fewer dependencies they have
[17:55] <racarr> i.e. threads have a shared memory dependency on eachother
[17:55] <racarr> whereas processes don't
[17:55] <racarr> you can be more clever
[17:56] <racarr> Or, perhaps the scheduler just fights us by default
[17:56] <racarr> because the desktop scheduler tries to ensure processes get low worst case latency
[17:56] <racarr> over thouroughput
[17:57] <racarr> so maybe there is some sort of timeslice that each process gets (I think this is a vast simplification of how the scheduler work now...I haven't known the details in > 2 years and there have been at least 2 rewrite)
[17:57] <racarr> and the shell is exhausting what would have gone to the compositor
[17:57] <racarr> if this is the case I bet we can fix it with affinities or priorities or something
[17:58] <kdub> racarr, i'm suspicious that what is happening is
[17:58] <racarr> 2. The input setup is different in the out of process case
[17:58] <kdub> the galaxy nexus gpu has to do a pipeline flush (or something funny like that) on a gpu context switch
[17:58] <kgunn> racarr: kind of makes sense, about mem dependencies too
[17:58] <racarr> i.e. it's using a seperate process for input reading and delivery too
[17:58] <kdub> and so in process thrashes the gpu caches and pipeline
[17:58] <kgunn> you can hose yourself w. overhead of locking/unlock
[17:59] <racarr> kdub: It's kind of the same story out of proces though right?
[17:59] <kdub> well, i guess
[17:59] <kdub> well
[17:59] <kdub> still thinking, thats a good point
[18:00] <racarr> kgunn: It could be an overhead of lock/unlock too
[18:00] <racarr> some sort of lock contention issue
[18:00] <racarr> another wild guess: Our surface stack has a single mutex
[18:02] <racarr> so input events (reading the surface stack/a surface) contend with the compositor (also reading the surface stack/a surface)
[18:02] <racarr> whereas in the out of process setup
[18:02] <racarr> where we are using surface flinger
[18:02] <racarr> there is no contention (granted there is also lot of races :p)
[18:02] <racarr> (using surface flinger for input that is)
[18:02] <racarr> A R/W lock would fix that.
[18:03] <tvoss> racarr, kgunn, kdub how about running it through callgrind?
[18:04] <racarr> Good idea, or if we had deeper lltng traces might be interesting.
[18:05] <racarr> I think first we should measure and confirm it XD
[18:05] <tvoss> racarr, exactly
[18:10] <racarr> im reading about
[18:12] <tvoss> racarr, I do not think that we should be slower in process. Why would we need to have more context switches in process?
[18:12] <racarr> tvoss: Not more context switches
[18:12] <racarr> I just mean the scheduling is less ideal
[18:12] <tvoss> racarr, can we try with renicing the the shell then?
[18:15] <racarr> pthread_setschedparam :)
[18:16] <tvoss> racarr, our good old friend :)
[18:16] <racarr> I think
[18:16] <racarr> something that would be interesting to try in general (even if not specifically in this problem)
[18:17] <racarr> would be scheduling the compositor thread with SCHED_FIFO
[18:17] <racarr> and all the other threads with SCHED_OTHER (the default, which is apparently round robin timeslices)
[18:22] <racarr> the whole theory of this being the source of the performance degredation seems improbable ;)
[18:22] <racarr> perhaps the surface flinger we use for input in out of process model
[18:22] <racarr> already has a higher priority
[18:22] <racarr> or higher priority threads somewhere
[18:22] <racarr> or something
[18:22] <racarr> that seems like the kind of thing they would do
[18:22] <racarr> Ok. Sorry I am rambling, this is just interesting to speculate about XD
[18:23] <racarr> tvoss: I am rebuilding the input stack to get rid of setInputWindows :)
[18:23] <tvoss> racarr, great :)
[18:24] <tvoss> racarr, surfaceflinger has a compositing thread priority of time_critical iirc
[18:24] <racarr> In the out of process mir demo though (which I think is what the performance degredation was observed relative to)
[18:24] <racarr> there is the surface flinger
[18:24] <racarr> input threads still running right
[18:24] <tvoss> racarr, yup
[18:25] <racarr> I bet they tweak those threads too..
[18:26] <racarr> if you really trust what you are doing even, all your input receiving threads on the client (which have a chance to back up the server input processing)
[18:26] <racarr> should be scheduled FIFO as well, because all they should do is read from the socket, respond and block/yield on injecting the event in to the toolkit thread
[18:27] <racarr> XD
[18:27] <racarr> I wish there were a term...
[18:27] <racarr> I run across this concept a lot, I don't think we are
[18:27] <racarr> IO bound or CPU bound rather we are
[18:27] <racarr> "contention bound"
[18:30] <racarr> kdub: Hmm. About the GPU drivers too..I guess it' not for granted that the flushing etc is the same from threads/processes
[18:31] <racarr> switching between contexts in the same process
[18:31] <racarr> you have this instance of the driver, GL API, etc.
[18:31] <racarr> and a GL context switch require updating state in all of those.
[18:31] <racarr> in addition to the actual
[18:31] <racarr> GPU switch
[18:32] <racarr> whereas when it goes to another process...

[18:32] <tvoss> you have to do that, too :)
[18:33] <racarr> tvoss: Do you?
[18:33] <tvoss> racarr, at least on a driver level
[18:33] <racarr> with two proceses though I think its hidden in the kernel layer? or at a lower part of the driver layer
[18:34] <racarr> whereas say in one process, you have some libglapi.so that has some static TheCurrentGLContextBlaBla data
[18:34] <racarr> then you have to tear it down and bring it back up when you switch contexts
[18:35] <tvoss> racarr, unless we use a per-thread context stored in thread-specific storage
[18:35] <tvoss> racarr, hold on ...
[18:35] <racarr> Yes.
[18:35] <racarr> I don't know how it works :) or what
[18:35] <racarr> all the data might be (context was just a guess)
[18:36] <kgunn> racarr: mild skim of scrollback...kinda depends on gpu
[18:36] <kgunn> but you'd take the hit generically in gl context
[18:36] <racarr> mm
[18:37] <racarr> what I am saying is some driver implementation models
[18:37] <kgunn> whether switching egl clients in diff thds or procs
[18:37] <racarr> might have a higher overhead for
[18:37] <tvoss> racarr, I *think* I have an idea, we patched parts of bionic for hybris, however, bionic has a pointer to gl stuff in a fixed place to speed up certain operations
[18:37] <racarr> context switches in the same process
[18:37] <racarr> espescially fucked up cross libc driver models apparently XD
[18:37] <racarr> tvoss: Interesting...wait what are the different
[18:38] <racarr> scenarios in multi process mir/single process though
[18:39] <tvoss> racarr, well, if you only have one context it might not matter, but assume you cache state in the fixed location ...
[18:40] <tvoss> state handwavingly wide
[18:40] <racarr> oh
[18:40] <racarr> yes
[18:40] <racarr> that sort of thing.
[18:40] <racarr> right, you can optimize one GL context per process
[18:40] <racarr> by penalizing multiple GL contexts per process
[18:40] <racarr> which is certainly something I would do on a phone
[18:41] <tvoss> racarr, how many gl contexts do we have for the shell?
[18:41] <racarr> tvoss: Oh so far just one because the shell is all one surface.
[18:42] <racarr> in the in process mir case.
[18:42] <tvoss> racarr, why would it be slower then?
[18:42] <racarr> then the compositor context
[18:42] <racarr> well
[18:42] <racarr> 2 total
[18:42] <tvoss> that really shouldn't matter
[18:42] <racarr> No. I agree espescially because
[18:42] <racarr> out of process, we are running multiple surfaces for launcher dah, etc
[18:43] <racarr> and its hard to believe
[18:43] <racarr> libgl state updating actually
[18:43] <racarr> outweighs
[18:43] <racarr> flushing the GPU pipeline.
[18:43] <tvoss> yup
[18:44] <tvoss> racarr, okay, time to actually measure things
[18:44] <racarr> Yeah XD I was just going to say I should
[18:44] <racarr> stop speculating as fascinating as this is...
[18:44] <racarr> I need to finish off this input branch.
[18:45] <racarr> tvoss: This branch is the first time we are really messing with the android-input bits much...(removing setInputWindows that is)
[18:46] <racarr> and I don't think anyone else except you has looked at InputDispatcher that much
[18:46] <racarr> so I will bug you for review on that part tomorrow or so
[18:46] <tvoss> racarr, can you send me the branch by mail please?
[18:47] <racarr> Yes. Will do so :) it's not quite done...I just got through all the mir refactoring that I need to actually make the InputDispatcher changes XD
[18:47] <racarr> but should finish it soon and will mail you
[18:47] <racarr> the...InputDispatcher while kind of this nasty object with like 30 responsibilities
[18:47] <racarr> has really careful threading and I am worried changing anything
[18:47] <racarr> I am going to break it all XD
[18:47] <racarr> in a way that the acceptance tests aren't rich enough to expose yet
[18:51] <racarr> Ok back to the input bubble
[18:51] <racarr> that was fascinating XD
[18:57] <racarr> greyback: Hey just wanted to update you...all this landing stuff has been delayed but should be resolved today
[18:58] <racarr> and in the meantime I have been working on the machinery in mir for doing the stacking (and then making input work with that)
[18:58] <racarr> so I am hoping we can switch to multi window shell soon
[19:18] <tvoss> kdub, ping
[19:23] <greyback> racarr: ok cool, good to know. Anything you need from me?
[19:24] <greyback> racarr: I recall you wondering about a mock shell, you think it'd be useful? I can get on that
[19:24] <racarr> greyback: No. Just wondering if that makes sense as a sort of shared target (multi window shell)
[19:24] <racarr> not sure how much effort it is from your end
[19:24] <racarr> greyback: Hmm what do you mean?
[19:25] <greyback> racarr: something to test the basics of window management, launch app, close app, switch between them, etc
[19:25] <racarr> Oh! Yeah. That's why im trying to get this surace ordering in place
[19:25] <racarr> so you can see the launcher on top of apps to switch between them XD
[19:25] <greyback> aha yes
[19:26] <greyback> ok, well I'll work on the simple QML mock shell for you. It'll be useful for automated testing too
[19:26] <racarr> I think getting the basic window management in place would be super useful (just this surface splitting has to happen before its useful, not sure how long that will take)
[19:26] <tvoss> greyback, +1 on the distilled shell
[19:26] <racarr> greyback: Awesome
[19:26] <racarr> super useful for automated testing. Need to get
[19:27] <racarr> qtubuntu auto tested in process
[19:27] <racarr> greyback: Another thing (sort of ties in)
[19:27] <greyback> agreed. Ok, adding to my list. I'm working on abstracting the existing WM code from unity8, and hopefully can get the 2 to meet in the middle
[19:27] <greyback> shot
[19:27] <greyback> shoot
[19:28] <racarr> I think we should kick off this, libunitymir or libmirunity codebase.
[19:28] <racarr> I was thinking about it because I wanted to write
[19:28] <greyback> tvoss: good god man, don't you ever go offline!
[19:28] <racarr> the cursor theme loading code
[19:28] <tvoss> greyback, I'm always around ;)
[19:28] <racarr> and it doesn't really belong in libmirserver
[19:29] <racarr> because really it's a utility for unity to use on top of mir
[19:29] <greyback> racarr: yep, we were thinking similarly. The WM code would best live in a libmirqt or something like that
[19:29] <tvoss> greyback, but fair point :)
[19:29] <racarr> or like...outside of mir or whatever
[19:29] <racarr> greyback: mm
[19:29] <racarr> so where does the code live?
[19:29] <greyback> separate project
[19:29] <tvoss> greyback, racarr how about libam, for libapplicationmanager?
[19:29] <tvoss> as it is not window but app mgmt
[19:30] <racarr> tvoss: Hmm. Maybe.
[19:30] <racarr> tvoss: The way I think of it is
[19:30] <greyback> cursor is something I'd not thought of. Hmm
[19:30] <racarr> Lib-utility-machinery--to-bridge-unity-and-mir
[19:30] <greyback> we need to give this a bit of thought, what belongs where
[19:30] <racarr> mm
[19:31] <racarr> Cursor loading isn't exactly part of "mirqt" definitely
[19:31] <greyback> yep
[19:32] <racarr> maybe there is a libmirutil and it's unrelated
[19:32] <racarr> maybe 90% of the code which is in this one file that everyone copies around
[19:32] <racarr> should really be libcursorthemeloader
[19:32] <racarr> and this is a red herring
[19:32] <racarr> XD
[19:32] <greyback> lol, now my head hurts
[19:32] <racarr> ignore cursors for now. We do need mirqt though
[19:33] <greyback> I keed forgetting the answer to this question. For desktop, what draws the window decoration?
[19:33] <racarr> depends on who you ask and the moon cycle
[19:33] <greyback> yayz
[19:34] <racarr> but I think
[19:34] <racarr> the client :)
[19:35] <racarr> and I feel rather strongly about it XD
[19:35] <greyback> okies. I'm not going to open this discussion :)
[19:35] <greyback> it's not my business! :D
[19:35] <racarr> haha
[19:35] <racarr> well, it sort of is, part of the theory behind client side decorations
[19:35] <greyback> well yes, that's true
[19:35] <racarr> is that it provides a more uniform model to the shell and mir (simplifying them)
[19:36] <greyback> yep
[19:36] <racarr> i.e. you have a surface, and it has x, y and w/h and you can treat them all the same
[19:36] <racarr> as opposed to like
[19:36] <racarr> x, y, w/h, border w/h, frame w/h
[19:37] <greyback> indeed. I see that PoV.
[19:37] <kgunn> greyback: but are you thinking there should be some common do-hicky that does common window decorations?
[19:38] <greyback> kgunn: for consistency yes.
[19:38] <kgunn> unity-mir layer going to be the bucket for everything shell & mir refuse to own :)
[19:38] <greyback> something has to draw them, I'm just curious as to what's the best place for it
[19:38] <racarr> greyback: It becomes difficult to model input, with server side decorations, without allowing the concept of embedded surfaces
[19:39] <greyback> racarr: now that is something I hadn't considered. hmm
[19:39] <racarr> not impossible, it's just complex, so I lean towards client side decorations, as the consistency bit
[19:40] <racarr> is solved fine by a libdrawthedecorations that all the toolkits use
[19:40] <racarr> and, of course applications/toolkits can misbehave
[19:40] <racarr> but we allow that anyway with "Freestyle" surface type
[19:40] <racarr> s
[19:40] <racarr> which are undecorated
[19:40] <racarr> i.e. chromium
[19:42] <greyback> yep, it's only a desktop issue. I see your technical point, that's a good one.
[19:43] <greyback> From user perspective, I definitely always want my close button drawn by something. So as long as we patch all the main toolkits, I'll be happy
[19:44] <racarr> greyback: I think we can enforce
[19:44] <greyback> I do like how easily you can draw window decorations with QML on kwin. But that's just a "nice to have"
[19:44] <racarr> no showing up on the screen unless you tell me where the close button on your decorations are
[19:44] <racarr> greyback: Couldn't it be the same client side though?
[19:45] <greyback> racarr: could be. But 1 QML engine in total, versus one per client - would be a lot more expensive
[19:46] <mlankhorst> is it hard to replace install mir and replace the GLES drivers on nexus4 with mesa?
[19:46] <mlankhorst> s/replace//
[19:46] <greyback> racarr: I did say: "I'm not going to open this discussion" :D Sorry, please get back to your work
[19:46] <racarr> ehe I understand
[19:46] <racarr> yes sorry! I am
[19:47] <racarr> ...a little hyperactive on discussions today it seems
[19:47] <greyback> nah, I don't want to trouble you with discussions that have happened a meellion times or more on the internets
[19:54] <kdub> tvoss, pong
[19:58] <kgunn> mlankhorst: http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html
[19:58] <kgunn> mlankhorst: and actually...you can see all the instrucations here http://unity.ubuntu.com/mir/
[19:58] <kgunn> mlankhorst: and technically...you're using the android compile gles drivers
[19:59] <kgunn> on nexus4
[19:59] <mlankhorst> yeah, but robclark's been working on freedreno, I wonder if I could make it work with mir
[19:59] <kdub> mlankhorst, in theory, it could
[19:59] <kgunn> mlankhorst: yeah...in theory
[20:00] <mlankhorst> that's fine, I don't expect it to completely work anyway
[20:00] <kgunn> mlankhorst: only worry might be egl-hwcomposer shenningans...but if rob got something working w vsynch likely it'll work
[20:03] <mlankhorst> I'm not even sure if scanout works at this point, might be worth investigating though :)