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