racarr2/3rds done!01:06
racarrunfortunately 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 own01:07
racarrHappy weekly meeting!05:57
racarr*streamers and loud horns*05:57
thomianyone joining me in the weekly meeting?06:02
thomiracarr: ?06:03
hikikothomi, in a sec06:03
racarrthomi: Link?06:04
thomikdub: ?06:07
thomiRAOF: ?06:07
alf__thomi: https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/16221106:24
alf__thomi: https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/718/console06:24
alan_galf__: @refactor-compositing-strategy - do you agree with me that the resource holding problem also applies to the "overlay rendering" we were discussing yesterday?09:09
alf__alan_g: yes09:14
alan_galf__: I'll roll that fix in too. ;)09:15
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 holding09:16
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:17
alan_galf__: 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:18
alf__alan_g: and save you the trouble of changing OverlayRenderer09:20
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
hikikothe mir/examples are only for the gbm platform?10:45
alf__hikiko: no10:58
hikikoalf__, 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 gbm11:00
hikikoit seems to compile with sdl11:00
alan_galf__: when you have time could you look over https://code.launchpad.net/~alan-griffiths/mir/refactor-compositing-strategy/+merge/16494511:01
alf__alan_g: sure11:02
=== 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
greybackkdub: hey, an progress with improving performance on Galaxy Nexus?13:23
hikiko_lunchalf__, render_to_fb is a standalone prog or i have to run something else before i start it?13:41
=== hikiko_lunch is now known as hikiko
hikikoThere are some brief guides describing how to run the Mir binaries once you have13:44
hikikothem built. <- where?13:44
alan_ghikiko: render_* are standalone programs13:47
* alan_g thinks this is https://bugs.launchpad.net/mir/+bug/1108715 again13:48
ubot5Launchpad bug 1108715 in Mir "Inadequate documentation of binaries" [Medium,Triaged]13:48
hikikocool, 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 etc13:49
hikikoyes :D alan_g that's exactly my question13:50
alan_ghikiko: The documentation that does exist is under http://unity.ubuntu.com/mir/ - e.g. "Using Mir on a PC"13:51
hikikopfff blind :( so I just start the server and then  I run the client :) thank you alan_g !13:53
alan_ghikiko: np - BTW you're welcome to propose improvements to the documentation. (It needs improvement!)13:54
hikikobut for the render_* I don't need to run the server isn't it?13:55
alan_ghikiko: no, they use the mir library directly13:55
hikikook :)13:55
hikikothank you!13:55
* alan_g is always glad to help.13:57
=== alan_g is now known as alan_g|tea
=== francisco is now known as Guest25788
=== alan_g|tea is now known as alan_g
kdubgreyback, no, haven't looked further into that... maybe we should file a bug?15:00
greybackkdub: true, I'll make one15:00
=== dpm-laptop is now known as dpm
greybackkdub: https://bugs.launchpad.net/mir/+bug/1182930 do you need more info?15:14
ubot5Launchpad bug 1182930 in Mir "Unity8 low framerate running on Mir on Galaxy Nexus" [Undecided,New]15:14
alf__status: more lttng work, started investigating mir stress test crashes15:15
=== mmrazik is now known as mmrazik|afk
kdubgreyback, looks like enough info to start15:17
kdubstatus, cleanup branch, measured our client's start times in comparison to surfaceflinegr, working on the glmark2 numbers now15:20
kgunngreyback: just curious...is the perf drop on n10 & galaxynexus? or more noticeable on one than the other15:24
greybackkgunn: Mir not functioning on N10, so I cannot say. I only have 1 device15:25
greybackthat's running Mir correctly right now15:25
kgunngreyback: ack15:25
greybackkgunn: probable perf is better. racarr has N4, he can probably say what perf is like15:26
=== Quintasan_ is now known as Quintasan
=== alan_g is now known as alan_g|life
racarrtoday will still be working on this input branch I was on all day yesterday17:12
racarrshould hopefully be wrapping it up around lunch time17:12
kgunnracarr: just curious....on nexus4, do you see the same drop for inprocess shell vs out of process (same as galaxynexus)17:37
racarrNot with17:41
racarra cursory glance17:41
racarrthats interesting17:42
racarrI have had a speculation for a while17:43
racarrthat perhaps a many threaded process17:43
racarris more difficult to schedule17:43
racarrthan multiple processes17:43
racarri.e. the assumption has always been that inprocess shell would give us a performance boost17:43
racarrbut there is no reason why that has to be true.17:43
racarrno reason obvious to me*17:45
kgunnracarr: mmm, guessing the theory is...its thread switching vs process (context) switching17:47
kgunnracarr: so you didn't see a visible drop on nexus4...hmm17:48
kgunnkdub: ^17:48
kdubyeah that could explain it :/17:49
kdubwell, rather, gpu context switching is more of a concern to me17:49
kdubbecause i'd guess the newer cores do that better than the older ones17:50
kdublike, i know the nexus4 gpu is 'hyperthreaded' (if i can overload that term :) )17:50
racarrkgunn: thread swithcing is definitely cheaper17:53
racarrthan process switching though...17:53
racarrbut, maybe that overhead is small for us17:53
racarrI have two theories (if it is in fact the case)17:53
kgunnracarr: for sure17:53
racarr1. I don't know how the kernel scheduler works anymore but17:54
racarrfrom a high level point of view if you are trying to interleave multiple processes17:54
racarrthe fewer dependencies they have17:54
racarri.e. threads have a shared memory dependency on eachother17:55
racarrwhereas processes don't17:55
racarryou can be more clever17:55
racarrOr, perhaps the scheduler just fights us by default17:56
racarrbecause the desktop scheduler tries to ensure processes get low worst case latency17:56
racarrover thouroughput17:56
racarrso 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
racarrand the shell is exhausting what would have gone to the compositor17:57
racarrif this is the case I bet we can fix it with affinities or priorities or something17:57
kdubracarr, i'm suspicious that what is happening is17:58
racarr2. The input setup is different in the out of process case17:58
kdubthe galaxy nexus gpu has to do a pipeline flush (or something funny like that) on a gpu context switch17:58
kgunnracarr: kind of makes sense, about mem dependencies too17:58
racarri.e. it's using a seperate process for input reading and delivery too17:58
kduband so in process thrashes the gpu caches and pipeline17:58
kgunnyou can hose yourself w. overhead of locking/unlock17:58
racarrkdub: It's kind of the same story out of proces though right?17:59
kdubwell, i guess17:59
kdubstill thinking, thats a good point17:59
racarrkgunn: It could be an overhead of lock/unlock too18:00
racarrsome sort of lock contention issue18:00
racarranother wild guess: Our surface stack has a single mutex18:00
racarrso input events (reading the surface stack/a surface) contend with the compositor (also reading the surface stack/a surface)18:02
racarrwhereas in the out of process setup18:02
racarrwhere we are using surface flinger18:02
racarrthere is no contention (granted there is also lot of races :p)18:02
racarr(using surface flinger for input that is)18:02
racarrA R/W lock would fix that.18:02
tvossracarr, kgunn, kdub how about running it through callgrind?18:03
racarrGood idea, or if we had deeper lltng traces might be interesting.18:04
racarrI think first we should measure and confirm it XD18:05
tvossracarr, exactly18:05
racarrim reading about18:10
tvossracarr, I do not think that we should be slower in process. Why would we need to have more context switches in process?18:12
racarrtvoss: Not more context switches18:12
racarrI just mean the scheduling is less ideal18:12
tvossracarr, can we try with renicing the the shell then?18:12
racarrpthread_setschedparam :)18:15
tvossracarr, our good old friend :)18:16
racarrI think18:16
racarrsomething that would be interesting to try in general (even if not specifically in this problem)18:16
racarrwould be scheduling the compositor thread with SCHED_FIFO18:17
racarrand all the other threads with SCHED_OTHER (the default, which is apparently round robin timeslices)18:17
racarrthe whole theory of this being the source of the performance degredation seems improbable ;)18:22
racarrperhaps the surface flinger we use for input in out of process model18:22
racarralready has a higher priority18:22
racarror higher priority threads somewhere18:22
racarror something18:22
racarrthat seems like the kind of thing they would do18:22
racarrOk. Sorry I am rambling, this is just interesting to speculate about XD18:22
racarrtvoss: I am rebuilding the input stack to get rid of setInputWindows :)18:23
tvossracarr, great :)18:23
tvossracarr, surfaceflinger has a compositing thread priority of time_critical iirc18:24
racarrIn the out of process mir demo though (which I think is what the performance degredation was observed relative to)18:24
racarrthere is the surface flinger18:24
racarrinput threads still running right18:24
tvossracarr, yup18:24
racarrI bet they tweak those threads too..18:25
racarrif 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
racarrshould 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 thread18:26
racarrI wish there were a term...18:27
racarrI run across this concept a lot, I don't think we are18:27
racarrIO bound or CPU bound rather we are18:27
racarr"contention bound"18:27
racarrkdub: Hmm. About the GPU drivers too..I guess it' not for granted that the flushing etc is the same from threads/processes18:30
racarrswitching between contexts in the same process18:31
racarryou have this instance of the driver, GL API, etc.18:31
racarrand a GL context switch require updating state in all of those.18:31
racarrin addition to the actual18:31
racarrGPU switch18:31
racarrwhereas when it goes to another process...18:32
tvossyou have to do that, too :)18:32
racarrtvoss: Do you?18:33
tvossracarr, at least on a driver level18:33
racarrwith two proceses though I think its hidden in the kernel layer? or at a lower part of the driver layer18:33
racarrwhereas say in one process, you have some libglapi.so that has some static TheCurrentGLContextBlaBla data18:34
racarrthen you have to tear it down and bring it back up when you switch contexts18:34
tvossracarr, unless we use a per-thread context stored in thread-specific storage18:35
tvossracarr, hold on ...18:35
racarrI don't know how it works :) or what18:35
racarrall the data might be (context was just a guess)18:35
kgunnracarr: mild skim of scrollback...kinda depends on gpu18:36
kgunnbut you'd take the hit generically in gl context18:36
racarrwhat I am saying is some driver implementation models18:37
kgunnwhether switching egl clients in diff thds or procs18:37
racarrmight have a higher overhead for18:37
tvossracarr, 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 operations18:37
racarrcontext switches in the same process18:37
racarrespescially fucked up cross libc driver models apparently XD18:37
racarrtvoss: Interesting...wait what are the different18:37
racarrscenarios in multi process mir/single process though18:38
tvossracarr, well, if you only have one context it might not matter, but assume you cache state in the fixed location ...18:39
tvossstate handwavingly wide18:40
racarrthat sort of thing.18:40
racarrright, you can optimize one GL context per process18:40
racarrby penalizing multiple GL contexts per process18:40
racarrwhich is certainly something I would do on a phone18:40
tvossracarr, how many gl contexts do we have for the shell?18:41
racarrtvoss: Oh so far just one because the shell is all one surface.18:41
racarrin the in process mir case.18:42
tvossracarr, why would it be slower then?18:42
racarrthen the compositor context18:42
racarr2 total18:42
tvossthat really shouldn't matter18:42
racarrNo. I agree espescially because18:42
racarrout of process, we are running multiple surfaces for launcher dah, etc18:42
racarrand its hard to believe18:43
racarrlibgl state updating actually18:43
racarrflushing the GPU pipeline.18:43
tvossracarr, okay, time to actually measure things18:44
racarrYeah XD I was just going to say I should18:44
racarrstop speculating as fascinating as this is...18:44
racarrI need to finish off this input branch.18:44
racarrtvoss: This branch is the first time we are really messing with the android-input bits much...(removing setInputWindows that is)18:45
racarrand I don't think anyone else except you has looked at InputDispatcher that much18:46
racarrso I will bug you for review on that part tomorrow or so18:46
tvossracarr, can you send me the branch by mail please?18:46
racarrYes. 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 XD18:47
racarrbut should finish it soon and will mail you18:47
racarrthe...InputDispatcher while kind of this nasty object with like 30 responsibilities18:47
racarrhas really careful threading and I am worried changing anything18:47
racarrI am going to break it all XD18:47
racarrin a way that the acceptance tests aren't rich enough to expose yet18:47
racarrOk back to the input bubble18:51
racarrthat was fascinating XD18:51
racarrgreyback: Hey just wanted to update you...all this landing stuff has been delayed but should be resolved today18:57
racarrand 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
racarrso I am hoping we can switch to multi window shell soon18:58
=== marlinc is now known as Marlinc
tvosskdub, ping19:18
=== francisco is now known as Guest82484
greybackracarr: ok cool, good to know. Anything you need from me?19:23
greybackracarr: I recall you wondering about a mock shell, you think it'd be useful? I can get on that19:24
racarrgreyback: No. Just wondering if that makes sense as a sort of shared target (multi window shell)19:24
racarrnot sure how much effort it is from your end19:24
racarrgreyback: Hmm what do you mean?19:24
greybackracarr: something to test the basics of window management, launch app, close app, switch between them, etc19:25
racarrOh! Yeah. That's why im trying to get this surace ordering in place19:25
racarrso you can see the launcher on top of apps to switch between them XD19:25
greybackaha yes19:25
greybackok, well I'll work on the simple QML mock shell for you. It'll be useful for automated testing too19:26
racarrI 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
tvossgreyback, +1 on the distilled shell19:26
racarrgreyback: Awesome19:26
racarrsuper useful for automated testing. Need to get19:26
racarrqtubuntu auto tested in process19:27
racarrgreyback: Another thing (sort of ties in)19:27
greybackagreed. 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 middle19:27
racarrI think we should kick off this, libunitymir or libmirunity codebase.19:28
racarrI was thinking about it because I wanted to write19:28
greybacktvoss: good god man, don't you ever go offline!19:28
racarrthe cursor theme loading code19:28
tvossgreyback, I'm always around ;)19:28
racarrand it doesn't really belong in libmirserver19:28
racarrbecause really it's a utility for unity to use on top of mir19:29
greybackracarr: yep, we were thinking similarly. The WM code would best live in a libmirqt or something like that19:29
tvossgreyback, but fair point :)19:29
racarror like...outside of mir or whatever19:29
racarrgreyback: mm19:29
racarrso where does the code live?19:29
greybackseparate project19:29
tvossgreyback, racarr how about libam, for libapplicationmanager?19:29
tvossas it is not window but app mgmt19:29
racarrtvoss: Hmm. Maybe.19:30
racarrtvoss: The way I think of it is19:30
greybackcursor is something I'd not thought of. Hmm19:30
greybackwe need to give this a bit of thought, what belongs where19:30
racarrCursor loading isn't exactly part of "mirqt" definitely19:31
racarrmaybe there is a libmirutil and it's unrelated19:32
racarrmaybe 90% of the code which is in this one file that everyone copies around19:32
racarrshould really be libcursorthemeloader19:32
racarrand this is a red herring19:32
greybacklol, now my head hurts19:32
racarrignore cursors for now. We do need mirqt though19:32
greybackI keed forgetting the answer to this question. For desktop, what draws the window decoration?19:33
racarrdepends on who you ask and the moon cycle19:33
racarrbut I think19:34
racarrthe client :)19:34
racarrand I feel rather strongly about it XD19:35
greybackokies. I'm not going to open this discussion :)19:35
greybackit's not my business! :D19:35
racarrwell, it sort of is, part of the theory behind client side decorations19:35
greybackwell yes, that's true19:35
racarris that it provides a more uniform model to the shell and mir (simplifying them)19:35
racarri.e. you have a surface, and it has x, y and w/h and you can treat them all the same19:36
racarras opposed to like19:36
racarrx, y, w/h, border w/h, frame w/h19:36
greybackindeed. I see that PoV.19:37
kgunngreyback: but are you thinking there should be some common do-hicky that does common window decorations?19:37
greybackkgunn: for consistency yes.19:38
kgunnunity-mir layer going to be the bucket for everything shell & mir refuse to own :)19:38
greybacksomething has to draw them, I'm just curious as to what's the best place for it19:38
racarrgreyback: It becomes difficult to model input, with server side decorations, without allowing the concept of embedded surfaces19:38
greybackracarr: now that is something I hadn't considered. hmm19:39
racarrnot impossible, it's just complex, so I lean towards client side decorations, as the consistency bit19:39
racarris solved fine by a libdrawthedecorations that all the toolkits use19:40
racarrand, of course applications/toolkits can misbehave19:40
racarrbut we allow that anyway with "Freestyle" surface type19:40
racarrwhich are undecorated19:40
racarri.e. chromium19:40
greybackyep, it's only a desktop issue. I see your technical point, that's a good one.19:42
greybackFrom 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 happy19:43
racarrgreyback: I think we can enforce19:44
greybackI do like how easily you can draw window decorations with QML on kwin. But that's just a "nice to have"19:44
racarrno showing up on the screen unless you tell me where the close button on your decorations are19:44
racarrgreyback: Couldn't it be the same client side though?19:44
greybackracarr: could be. But 1 QML engine in total, versus one per client - would be a lot more expensive19:45
mlankhorstis it hard to replace install mir and replace the GLES drivers on nexus4 with mesa?19:46
greybackracarr: I did say: "I'm not going to open this discussion" :D Sorry, please get back to your work19:46
racarrehe I understand19:46
racarryes sorry! I am19:46
racarr...a little hyperactive on discussions today it seems19:47
greybacknah, I don't want to trouble you with discussions that have happened a meellion times or more on the internets19:47
kdubtvoss, pong19:54
kgunnmlankhorst: http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html19:58
kgunnmlankhorst: and actually...you can see all the instrucations here http://unity.ubuntu.com/mir/19:58
kgunnmlankhorst: and technically...you're using the android compile gles drivers19:58
kgunnon nexus419:59
mlankhorstyeah, but robclark's been working on freedreno, I wonder if I could make it work with mir19:59
kdubmlankhorst, in theory, it could19:59
kgunnmlankhorst: yeah...in theory19:59
mlankhorstthat's fine, I don't expect it to completely work anyway20:00
kgunnmlankhorst: only worry might be egl-hwcomposer shenningans...but if rob got something working w vsynch likely it'll work20:00
mlankhorstI'm not even sure if scanout works at this point, might be worth investigating though :)20:03
=== racarr is now known as racarr|curry
=== racarr|curry is now known as racarr
=== francisco is now known as Guest56727

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!