| robert_ancell | mterry, around? | 00:05 |
|---|---|---|
| mterry | robert_ancell, hello | 00:05 |
| robert_ancell | Can I get you to do a quick sanity check on a lightdm merge? Just pushing it now... | 00:07 |
| robert_ancell | https://code.launchpad.net/~robert-ancell/lightdm/usc-module/+merge/198479 | 00:08 |
| mterry | robert_ancell, ok, looking | 00:09 |
| robert_ancell | ta | 00:09 |
| mterry | robert_ancell, why not use xmir for this? | 00:10 |
| mterry | with a unity seat | 00:10 |
| robert_ancell | mterry, this is so we can run Unity 8 + USC from a greeter, i.e. no X | 00:10 |
| robert_ancell | you then have one USC per session | 00:11 |
| robert_ancell | and can do full user switching etc | 00:11 |
| mterry | robert_ancell, oh, huh. | 00:11 |
| mterry | robert_ancell, why not run unity8 standalone then? | 00:11 |
| robert_ancell | because then it has to be root to do the VT switching / graphics permissions | 00:11 |
| mterry | robert_ancell, sorry, got distracted by something. Coming back to this | 00:51 |
| mterry | robert_ancell, I guess I don't know enough about how Mir works, but I would have thought standalone unity8 and USC would have the same problems | 00:52 |
| mterry | robert_ancell, so the xlocal dropping ready signal seems unrelated. But the rest of it makes sense. Why is the usc class a display server? For convenience of adopting its API? | 01:04 |
| robert_ancell | mterry, it will be used as a display server in the U8+USC case, but yes, mostly a convenience | 01:14 |
| robert_ancell | actually it is required to be a display server for that case | 01:14 |
| robert_ancell | I figured it would be better to make the code common | 01:14 |
| robert_ancell | yeah, the xlocal ready signal was just something I noticed was unused | 01:14 |
| mterry | Well, seems fine. Mostly just moving code around | 01:15 |
| robert_ancell | yes | 01:15 |
| mterry | I imagine the unity seat is nice and lean now | 01:15 |
| robert_ancell | it is :) | 01:15 |
| mterry | robert_ancell, I'm working on a bug I'm seeing in Touch, with lightdm/greeter/session interaction | 01:15 |
| mterry | robert_ancell, can you look at a log real quick and maybe hit me with a cluebat? | 01:16 |
| mterry | http://paste.ubuntu.com/6554125/ | 01:16 |
| robert_ancell | sure | 01:16 |
| mterry | robert_ancell, in there, I've commented some lines | 01:16 |
| mterry | robert_ancell, around line 89, why do we kill the user session? | 01:16 |
| mterry | Doesn't seem to make sense. Separately, I'm not sure 100% why the greeter is dying, but I think that's a mir crash | 01:17 |
| robert_ancell | that is odd | 01:18 |
| robert_ancell | mterry, A guess - it's reset_session in greeter.c killing the existing sessions which for some reason we still hold a reference to? | 01:19 |
| robert_ancell | grepping through the source suggests that would make the logs in the same order | 01:20 |
| robert_ancell | perhaps we have a reference to the old greeter for some reason | 01:20 |
| robert_ancell | because obviously the new greeter shouldn't know about an existing session | 01:21 |
| mterry | hm | 01:21 |
| mterry | I can add more debugging logs and drill down | 01:23 |
| mterry | Might be another of these 'mir does things instantly' bugs like with the other display/session bug | 01:24 |
| === duflu_ is now known as duflu | ||
| mterry | What causes the "Could not unblank display" error? I can't remember. I know we used to see it often | 02:13 |
| mterry | I'm seeing it now in the USC during greeter testing | 02:13 |
| RAOF | On the device I'd be pointing fingers at powerd. | 02:20 |
| RAOF | That seems like the scapegoat of choice :) | 02:21 |
| kgunn | robert_ancell: cool...just found out you're gonna do something to usc to make xmir not req'd for the unity8 preview thanks! | 02:33 |
| kgunn | i was worrying about that one | 02:33 |
| robert_ancell | yeah, as discussed on a piece of paper in a hotel room :) | 02:34 |
| === shuduo_afk is now known as shuduo | ||
| robert_ancell | we just need Mir on Mir working... | 02:34 |
| * robert_ancell looks at RAOF | 02:34 | |
| robert_ancell | no pressure | 02:34 |
| RAOF | robert_ancell: Mostly working :) | 02:35 |
| RAOF | robert_ancell: Or, at least, the non-Mir-on-Mir bit of Mesa is working again | 02:36 |
| RAOF | kgunn: Why was xmir required for the unity8 preview in the first place? | 02:37 |
| kgunn | RAOF: only if we took in usc as-is today...in order to run unity8 on mir-on-mir w/ usc | 02:38 |
| kgunn | so a knock on effect | 02:38 |
| RAOF | Ah, for the greeter? | 02:39 |
| kgunn | yes... | 02:39 |
| RAOF | Right. | 02:41 |
| RAOF | Gah! What a super-useless error message: “session_error("egldemo")” | 02:42 |
| RAOF | Thanks, SessionMediatorReport! | 02:42 |
| RAOF | (For those playing at home - current state of Mir-on-Mir-on-Mesa is ‘everything seems to work, except that clients mysteriously fail to connect’) | 02:43 |
| duflu | RAOF: How do unthrottled frame rates of fullscreen clients compare (-n -f) ? | 02:45 |
| RAOF | duflu: Between mir-on-mir and mir-on-hardware. | 02:46 |
| duflu | RAOF: Yes | 02:46 |
| RAOF | duflu: Unknown; clients fail to connect to the nested mir server. | 02:46 |
| duflu | RAOF: OK. We'll get there. Will be interesting to see. In fact I think that's my job. I just don't have the right Mesa to test desktop nesting yet | 02:47 |
| RAOF | duflu: Yeah. You'll have the right mesa just as soon as I can verify that the mesa I've got here *is* the right mesa :) | 02:47 |
| RAOF | Well, modulo buildd time. | 02:47 |
| RAOF | Oh, and a small Mir change. | 02:47 |
| duflu | RAOF: That's fine. I have plenty of other stuff to get through before I'm back on that task | 02:49 |
| === chihchun_afk is now known as chihchun | ||
| === shuduo is now known as shuduo_afk | ||
| RAOF | duflu: So, quick and dirty eglplasma FPS eyeballing suggests that running nested slightly *increases* framerate, and seems to reduce variance. | 03:26 |
| duflu | RAOF: That's totally weird :) | 03:26 |
| RAOF | Not at all. | 03:26 |
| duflu | RAOF: Reduced variance is not weird. Only increased throughput | 03:26 |
| duflu | RAOF: You know it outputs framerate to stdout? | 03:27 |
| RAOF | Yes, that's what I was reading. | 03:27 |
| RAOF | There's no way I could tell the difference between 1800fps and 1700fps otherwise. | 03:27 |
| RAOF | It's also possible that there *isn't* a significant difference in throughput; I haven't actually computed averages. | 03:28 |
| duflu | RAOF: Yeah, that's what I meant. We can't just say "it's over 60FPS so who cares?". It's all about percentage differences, which often interpolate to less capable machines where a small difference is more critical | 03:29 |
| RAOF | Anyway, this now works, except for software buffers. | 03:29 |
| duflu | All too often that extra 10% on a developer machine equates to no longer missing frame deadlines on a slower customer machine | 03:30 |
| RAOF | I'm a bit surprised that nested gave different numbers at all, actually. | 03:31 |
| duflu | Yeah all things working properly, throughput should be unaffected | 03:34 |
| robert_ancell | bregma, https://code.launchpad.net/~robert-ancell/lightdm/mir-sessions2/+merge/198487 adds support for Mir sessions | 03:34 |
| RAOF | duflu: Particularly because nested currently doesn't change the swapbuffers flow at all - it's client → immediate server in both cases. | 03:36 |
| * duflu wonders if we're getting some extra N-buffering effect | 03:37 | |
| === shuduo_afk is now known as shuduo | ||
| RAOF | Hm. The client receiving a 0×0 shm buffer isn't actually going to be a Mesa problem. | 03:50 |
| RAOF | Which means that mesa works! | 03:50 |
| RAOF | Which means that it's time to upload :) | 03:50 |
| RAOF | Woot. Also works on radeon. | 04:15 |
| RAOF | duflu: Oh, this mesa should also make running Mir under vmware work. | 04:19 |
| duflu | RAOF: Very interesting | 04:19 |
| RAOF | Assuming that our drm probing method doesn't discount them. | 04:19 |
| duflu | RAOF: And qemu with the vmware graphics option? :) | 04:19 |
| RAOF | Likewise; as long as it supports the newer vmware kernel module. | 04:20 |
| RAOF | Hm. Mir team meeting today? | 04:20 |
| duflu | Not sure. Hope not. I have nothing to talk about and need to duck out at lunch | 04:21 |
| === tvoss|dinner is now known as tvoss | ||
| duflu | RAOF: proposed counts as "Fix Committed", no? | 06:03 |
| RAOF | duflu: Yes, but if you're thinking of changing the bug status, I wouldn't bother; it'll be automatically marked as fix released soon enough. | 06:06 |
| duflu | RAOF: Too late | 06:06 |
| RAOF | Hm. The commit which broke nesting on Mesa seems to have been made to fix nesting on Android. | 06:23 |
| duflu | ?? | 06:26 |
| RAOF | It switched the nested platform constructor from creating a context with EGL_NO_SURFACE to creating a dummy 1×1 pbuffer surface and creating the context on that. | 06:28 |
| RAOF | Presumably because at least one of the Android EGL stacks didn't support EGL_KHR_surfaceless_context. | 06:28 |
| RAOF | However: Mesa doesn't support pbuffer surfaces | 06:28 |
| duflu | RAOF: So the new Mesa still can't nest using dev branch? | 06:31 |
| duflu | Because of the dev branch... | 06:31 |
| RAOF | Correct. | 06:31 |
| duflu | Excellent. Yes, I suspected pbuffers were deprecated but wasn't sure so did not block that from landing... Was it mterry? | 06:32 |
| RAOF | Yeah. | 06:32 |
| duflu | Yeah I remember that commit. Sorry. At the time it appeared nesting was still very much under development. Which is only half true | 06:33 |
| duflu | RAOF: Could you log a bug for that? tagged "nested" ? | 06:54 |
| RAOF | I'd rather just fix it. | 06:54 |
| duflu | That too | 06:54 |
| RAOF | Once this branch builds you can have a merge to review :) | 06:55 |
| duflu | Whee, more reciews | 06:55 |
| duflu | And reviews | 06:55 |
| duflu | Although if Mesa prevented it from working till now, no functionality is technically lost, yet :) | 06:57 |
| RAOF | I guess I should really test this on android nested, shouldn't I. | 07:31 |
| RAOF | Bah. Why doesn't bzr lp-propose properly target lp:mir/devel when I ask it to? | 07:35 |
| RAOF | duflu: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 if you want to play the nested game. | 07:36 |
| duflu | RAOF: Looking at it | 07:36 |
| duflu | RAOF: Did I miss something? Does C++ really force us to create constructors like that? Is there no other way? | 07:37 |
| duflu | Last time the answer was "no" but I think it's worth asking again | 07:37 |
| RAOF | No other way while retaining the constness, no. | 07:38 |
| duflu | Dear C++: Be better :S | 07:38 |
| duflu | At everything | 07:38 |
| didrocks | RAOF: yeah lp-propose will still catch up to the "toppest branch" to what you target | 07:38 |
| didrocks | RAOF: that's why everytime we deploy a stack, we have to reconfigure to set trunk target as "trunk" :/ | 07:39 |
| RAOF | We *could* factor out the surface construction into a function, which would make things look a bit better. | 07:39 |
| didrocks | you shuold do the same for mir/devel I guess | 07:39 |
| didrocks | should* | 07:39 |
| RAOF | didrocks: What needs to happen? lp:mir/devel properly points at lp:~mir-team/mir/development-branch | 07:40 |
| RAOF | duflu: You wouldn't happen to know on which android device(s) nesting is most likely to work, would you? | 07:40 |
| duflu | RAOF: I had it working on N4 last week | 07:41 |
| didrocks | RAOF: I've just run "bzr config -d lp:mir/devel public_branch=~mir-team/mir/development-branch" | 07:41 |
| duflu | Without fuss | 07:41 |
| didrocks | RAOF: if you try now, it should work | 07:41 |
| didrocks | RAOF: it's a question of internal launchpad stacking branch | 07:41 |
| anpok_ | RAOF: worked on the nexus 10 too | 07:54 |
| anpok_ | where do i see which tests are executed or not executed through make test? | 07:55 |
| RAOF | They're all executed; output goes to stdout IIRC. | 07:57 |
| RAOF | There's also logs in Testing/.. | 07:58 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| anpok_ | hm why do I experience test failures when i run the binaries manually? | 08:01 |
| RAOF | Because you need the environment set up by umockdev | 08:02 |
| RAOF | (Running the binaries with “umockdev-run bin/unit-tests” will work) | 08:03 |
| anpok_ | thx! | 08:03 |
| * RAOF is hit *again* with the “find_libhardware doesn't look in the chroot” bug. Perhaps it's time to fix that. | 08:15 | |
| RAOF | What's the easiest way to test on the phone again? | 08:28 |
| tvoss | Saviq, can you help RAOF ? | 08:28 |
| Saviq | tvoss, RAOF, I can try, test what? (first time I've seen the find_libhardware thing) | 08:29 |
| * RAOF would have turned up to the session at the sprint, but it was on before I knew it was on :) | 08:29 | |
| RAOF | Saviq: You probably have libhardware-dev installed system-wide; that masks the bug. | 08:29 |
| * duflu would have gone to a couple of useful sessions, but each time mir-team was too busy in discussions and no one could escape | 08:30 | |
| Saviq | RAOF, nope, no libhardware-dev installed here | 08:30 |
| RAOF | Saviq: I need to test nesting mir on android; our documentation for that is significantly out of date. | 08:30 |
| RAOF | Saviq: Hm, odd. Building with ./cross-compile-chroot.sh? | 08:30 |
| Saviq | RAOF, haven't built mir for a long time, but when I was - yes, cross :) | 08:31 |
| duflu | RAOF: How old is your image? | 08:31 |
| RAOF | duflu: Fresh as of now. | 08:31 |
| RAOF | Newest in trusty-proposed. | 08:32 |
| duflu | RAOF: BTW, umockdev-run still not joyful on saucy... bug 1259851 | 08:32 |
| ubot5 | bug 1259851 in Mir ""umockdev-run bin/mir_unit_tests" fails with: sendmsg_all: cannot run glob: Invalid argument umockdev-run: unable to propagate signal 6 to child 9323: No such process" [Undecided,New] https://launchpad.net/bugs/1259851 | 08:32 |
| Saviq | RAOF, I'm also afraid I never touched nested mir - mterry and ricmm know most there, but obviously TZ is wrong there... | 08:32 |
| * duflu retests trusty | 08:32 | |
| RAOF | duflu: Yeah, needs a umockdev SRU | 08:32 |
| anpok_ | i could test nested on n10 .. that what i did the last two days.. | 08:35 |
| duflu | Fun. Some trusty update has bricked my laptop. Almost | 08:36 |
| duflu | ... and that's why I maintain saucy on my primary system | 08:37 |
| duflu | anpok_: Very nice first code review | 08:44 |
| RAOF | Bah. How can the phablet image not have strace installed? :) | 08:46 |
| RAOF | anpok_: Yeah, I agree that we should have an actual shared “check EGL extensions” helper. I'll factor one out of our existing stuff. | 08:47 |
| anpok_ | i was unsure whether minor stuff like that was enough for "needs fixing" or .. dunno | 08:48 |
| anpok_ | guide me .. | 08:48 |
| RAOF | I think that's a reasonable use of "needs fixing" | 08:48 |
| duflu | Sometimes. Depends if we have time and have spent much time iterating the branch yet. In this case, it's fine | 08:48 |
| RAOF | Cool, didn't break android. | 08:49 |
| anpok_ | should the integration/acceptance test run on the device | 08:50 |
| RAOF | Yes, but it doesn't. | 08:51 |
| RAOF | Oh, actually it will. | 08:51 |
| anpok_ | [ RUN ] AndroidGPUDisplay.gpu_display_ok_with_gles | 08:51 |
| anpok_ | unknown file: Failure | 08:51 |
| anpok_ | C++ exception with description "could not select EGL config for use with framebuffer" thrown in the test body. | 08:51 |
| anpok_ | [ FAILED ] AndroidGPUDisplay.gpu_display_ok_with_gles | 08:51 |
| anpok_ | but that happened with devel too | 08:51 |
| anpok_ | and that one [----------] 1 test from AndroidInternalClient | 08:51 |
| anpok_ | [ RUN ] AndroidInternalClient.internal_client_creation_and_use | 08:51 |
| anpok_ | seems to hang.. or take longer? | 08:52 |
| anpok_ | i have to shutdown lightdm and unity for that? | 08:54 |
| RAOF | Maybe? I wouldn't think so. | 08:58 |
| duflu | anpok_: bug 1249019 | 09:00 |
| ubot5 | bug 1249019 in Mir "Test failure: AndroidGPUDisplay.hwc_display_ok_with_gles" [Medium,Triaged] https://launchpad.net/bugs/1249019 | 09:00 |
| === shuduo is now known as shuduo_afk | ||
| anpok_ | how do i stop unity8? i thought kill would work.. | 09:12 |
| alan_g | anpok_: as phablet: "stop unity8" | 09:13 |
| anpok_ | hm unkown job unity8 | 09:13 |
| RAOF | anpok_: stop --user unity8 | 09:14 |
| === shuduo_afk is now known as shuduo | ||
| alf_ | anpok_: Are you logged in as user 'phablet'? | 09:15 |
| alan_g | sudo -i -u phablet | 09:15 |
| alan_g | stop unity8 | 09:16 |
| duflu | And if it can't find the "stop" command then: /sbin/stop unity 8 | 09:17 |
| duflu | /sbin/stop unity8 | 09:17 |
| anpok_ | arg not properly logged in .. now it works | 09:17 |
| anpok_ | hm it works | 09:19 |
| anpok_ | but i get strange framerates | 09:19 |
| anpok_ | 7800 on non nested | 09:19 |
| anpok_ | 32 on nested demo shell | 09:19 |
| anpok_ | 7800 on non nested demo shell | 09:20 |
| anpok_ | both eglplasma | 09:20 |
| anpok_ | hm 32 is for root .. and 7800 for phablet user.. | 09:20 |
| anpok_ | ah | 09:21 |
| * duflu just needs to reinstall the world and can then confirm :) | 09:30 | |
| anpok_ | 7800 happened when i was using the mir lbiraries from system.. | 09:34 |
| anpok_ | and i also resized the buffer | 09:34 |
| anpok_ | ah cmake default is no optimization | 09:38 |
| RAOF | cmake defaults are almost all wrong. :( | 09:40 |
| duflu | anpok_: The surface size is a huge factor in frame rate. You need to keep it unchanged if you're comparing frame rates | 09:40 |
| RAOF | Particularly for eglplasma; that thing does *lots* of per-pixel computation. | 09:41 |
| RAOF | Less so for egltriangle :) | 09:41 |
| duflu | Hmm, yes, I did promise less trig-per-fragment and never got around to it | 09:41 |
| RAOF | Nah, I wouldn't bother; it's useful that it pushes the GPU a bit. | 09:42 |
| duflu | We could move the existing shader into the planned "hand warmer" app | 09:43 |
| alan_g | duflu: in boston I found 6 levels of nesting made any app a hand-warmer | 09:45 |
| duflu | Handy | 09:45 |
| alan_g | ...and terrible frame rates | 09:45 |
| duflu | alan_g: I had a good theoretical reason why the frame rates degraded. But as recently as this morning RAOF and I couldn't see why it would happen | 09:46 |
| duflu | I had a reason many months ago which seemed to line up with your findings... Just can't remember | 09:47 |
| alan_g | duflu: well, there have been a lot of optimizations since | 09:47 |
| duflu | alan_g: We pass through to bypass now? | 09:47 |
| alan_g | I don't know. We couldn't then | 09:47 |
| RAOF | Bypass shouldn't make any difference to framerate on our current nested stack? | 09:48 |
| duflu | RAOF: It definitely should. If bypass was critical before, it's still critical now. | 09:48 |
| alan_g | RAOF: if we don't bypass then surely we copy the whole buffer for each nest | 09:49 |
| * duflu hopes alan_g is kidding | 09:49 | |
| RAOF | Yeah, we copy the buffer for each nest; I guess if you nest enough that's going to kill GPU bandwidth enough for you to notice. | 09:50 |
| RAOF | But that's only a 60Hz copy. | 09:50 |
| duflu | A 60Hz copy will kill performance on plenty of systems. Obviously we'll need to eliminate that | 09:50 |
| RAOF | Yes, indeed. | 09:50 |
| RAOF | But for things which aren't bandwidth constrained - and I'd guess that eglplasma is not bandwidth constrained - a bunch of 60Hz copies isn't going to materially affect the results. | 09:51 |
| * alan_g thinks that measurement is the key | 09:52 | |
| RAOF | Oh, certainly. | 09:52 |
| duflu | RAOF: Not sure. Seems to depend on the GPU x framebuffer dimensions | 09:52 |
| RAOF | The thing that we *don't* have with nested is spiralling IPC latency, because the relevant IPC is only client <-> immediate compositor. Once we land the generalised bypass/HWC stuff, though, IPC might be interesting. | 09:53 |
| duflu | An "extra copy" was the reason why XMir never performed as well as X, despite the fact it should have been faster than X. Let's not get into the habit of accepting extra copies, or we may indefinitely lag behind existing X performance | 09:53 |
| === shuduo is now known as shuduo_afk | ||
| anpok_ | hm for the nested hwc stuff client api needs to be changed too? or would nested behave like a client with a bag of buffers to post? | 09:59 |
| RAOF | I'm not advocating that we accept extra copies. | 09:59 |
| RAOF | Indeed the client API needs to change for the nested HWC stuff. | 09:59 |
| duflu | anpok_: It's transparent. The client should never know | 09:59 |
| duflu | Really? | 09:59 |
| anpok_ | duflu: the "can-you-compose-part".. | 09:59 |
| alan_g | anpok_: the point is that that the client doesn't know | 09:59 |
| * duflu doesn't remember that discussion | 10:00 | |
| anpok_ | yeah it starts to blur away | 10:00 |
| alan_g | anpok_: what "can-you-compose-part" was left at the end of discussions | 10:00 |
| alan_g | We ended with "you will compose..." | 10:01 |
| anpok_ | alan_g: i thought only for the nested case.. yes | 10:01 |
| alan_g | anpok_: you're talking about the revised composite loop discussion? | 10:02 |
| anpok_ | yes | 10:02 |
| anpok_ | but maybe that happened when my stomoach toldme that i am continental | 10:02 |
| alan_g | We ended with unity8 doing its own thing and then passing a set of surfaces(?) to Mir wht the instruction "you will compose this" | 10:03 |
| RAOF | alan_g: The nested compositor is a client; it has to know. | 10:03 |
| RAOF | unity8 will pass that set of surfaces to it's Mir, which will pass that set of surfaces over the client API up to usc, which will composite. | 10:04 |
| RAOF | s/'//g | 10:04 |
| duflu | That doesn't sound right. We'd be explicitly preventing hardware composition/overlay/bypass... ? | 10:05 |
| alan_g | RAOF: there's still no "can-you-compose-part" | 10:06 |
| RAOF | alan_g: Correct. | 10:06 |
| RAOF | alan_g: But there *is* a change in the client api, to allow passing the bag of buffers to composite up. | 10:06 |
| RAOF | (Because usc is the only thing that can reasonably allocate hardware resources) | 10:07 |
| * RAOF declares EOD, but may be around later to argue further :) | 10:08 | |
| anpok_ | and here i need to dig deeper | 10:09 |
| * alan_g thinks maybe we need to get into the same timezone for a proper argument | 10:09 | |
| anpok_ | we talked about usc not being able to do hardware overlays due to the way buffers got allocated | 10:09 |
| alan_g | anpok_: this is all "future optimization" as for the time being unity8 is only passing a single buffer | 10:10 |
| anpok_ | and that we might be able to remember those buffers/surfaces? | 10:10 |
| anpok_ | ah ok | 10:10 |
| anpok_ | but then we dont use hwc | 10:10 |
| alan_g | we will | 10:11 |
| anpok_ | but therfore we need to reidentifiy through one nested compositor that this is for the same surface we had in the last bag.. | 10:12 |
| anpok_ | alan_g: just wanted to finish my thoughts - while being interrupted by wife .. -> need to hunt something for lunch | 10:12 |
| duflu | OK, that kind of makes sense for the complicated case of some overlays and some non-overlays. But we should probably focus on not breaking the existing bypass in the simple one-fullscreen-surface case | 10:13 |
| alan_g | duflu: I'm not convinced it isn't already broken in nesting | 10:14 |
| alan_g | But otherwise +1 | 10:14 |
| duflu | alan_g: isn't? or is? | 10:14 |
| duflu | I'm just saying make sure bypass still works before covering complicated partial overlays | 10:14 |
| alan_g | duflu: has it ever worked in nested mode? | 10:15 |
| duflu | alan_g: No idea. I haven't been able to test nesting on desktop yet. Just reinstalling trusty at present | 10:15 |
| alan_g | duflu: me neither | 10:16 |
| duflu | But it's definitely a requirement. The need for performance at least 90% that of X is still a need | 10:16 |
| duflu | Ideally better | 10:16 |
| alan_g | Agreed. I was just reacting to "not breaking" by saying we likely need to fix first. | 10:17 |
| duflu | So if it's not implemented yet, who's working on finishing nesting? | 10:17 |
| duflu | Anyone, or are we distracted? | 10:18 |
| alan_g | No-one at the moment | 10:19 |
| duflu | OK, well it's all just talk right now anyway. I'll soon get back to speed and implement some automation for gathering numbers | 10:20 |
| alan_g | But RAOF has been landing stuff to make it work on mesa and kdub has been fixing some problems on different android stacks. It's only just getting to the "it runs" stage. | 10:21 |
| duflu | Yeah I know. Which is fine with me, because it should become usable just as I'm ready to use it | 10:21 |
| duflu | ... this week at least | 10:21 |
| anpok_ | ;32m[ RUN ] ServerDisconnect.client_detects_server_shutdown | 11:46 |
| anpok_ | unknown file: Failure | 11:46 |
| anpok_ | C++ exception with description "Timeout while waiting for child to change state" thrown in TearDown(). | 11:46 |
| anpok_ | ;31m[ FAILED ] ServerDisconnect.client_detects_server_shutdown (60188 ms) | 11:46 |
| anpok_ | something like that happened on jenkins for roafs merge request | 11:46 |
| anpok_ | is that something that happens now and then .. (timeout in unit test..) | 11:46 |
| alan_g | anpok_: something like that is happening for several requests | 11:47 |
| alan_g | Looks like recently switched on tests are failing intermittently | 11:47 |
| alan_g | alf_: are you working today? | 11:49 |
| alf_ | alan_g: yes | 11:49 |
| alan_g | I was going to look at our new test failures - but not if you're already onto it? | 11:50 |
| alf_ | alan_g: I am currently working on screenshotting/casting, but I can take a look at the failures. Are these the ones mentioned above? | 11:53 |
| alan_g | alf_: No I'll look - I just didn't want to duplicate effort | 11:53 |
| alf_ | alan_g: ok, thanks | 11:53 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === tvoss is now known as tvoss|food | ||
| === 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|lunch is now known as dandrader | ||
| mterry | I need help with Mir + Qt integration. Specifically, strategies for getting as far as possible into a process before causing Mir to wait due to screen-off (i.e. I want greeter to load as much as possible before pushing buffer to Mir) | 20:16 |
| mterry | Maybe use a different Qt backend, get everything prepped, then switch to Mir? Is that even possible? | 20:16 |
| mterry | Or use some Mir API to queue changes, but not actually push the buffer until I ask? | 20:17 |
| mterry | greyback, ^ ? Or do you know who best to ping? | 20:17 |
| mterry | ricmm, ^ | 20:28 |
| kdub | 'getting as far as possible into a process' | 20:33 |
| kdub | ? | 20:33 |
| kdub | i also think our power model isn't flexible enough to handle USC in the mix as it stands today | 20:35 |
| mterry | kdub, the way it works right now | 20:38 |
| mterry | kdub, is that if you are in your session, and press the power button to lock... | 20:38 |
| mterry | kdub, the greeter process is frozen by Mir quite early in its lifecycle and so after the user turns screen back on again, it takes a couple seconds for greeter to finish loading and display on screen | 20:39 |
| mterry | kdub, I'd like to get that loading to happen while screen is off | 20:39 |
| mterry | kdub, but right now, Mir is getting in the way | 20:39 |
| kdub | yeah, a bit of a different problem than what I was talking about | 20:40 |
| mterry | I believe Mir is freezing us in the runQMirServerWithClient call | 20:41 |
| kdub | do we know which call is blocking? | 20:41 |
| mterry | ^ I can get more details if needed, but maybe that is enough of a clue? | 20:41 |
| mterry | That call is in unity-mir | 20:41 |
| kdub | eh, doesn't mean much to me | 20:41 |
| kdub | without digging | 20:41 |
| mterry | Which eventually calls mir::run_mir | 20:42 |
| mterry | kdub, ^ does that ring a bell? | 20:42 |
| mterry | That's really all it does. And connects to QApplication::quit | 20:42 |
| mterry | Well, it also creates ShellServerConfiguration | 20:42 |
| kdub | what's probably happening is | 20:43 |
| mterry | Which might be blocking on some graphics call | 20:43 |
| kdub | usc stops serving buffers out to the greeter (because its obscured from view) | 20:43 |
| mterry | I don't think this is USC specific. I saw the same thing with just standalone unity8. When the screen is off, Mir freezes all clients | 20:44 |
| kdub | we were talking about that last week | 20:45 |
| kdub | and the plan was to improve our IPC a bit for that situation | 20:45 |
| * kdub forgets who was looking at that though | 20:47 | |
| mterry | kdub, that doesn't mean much to me. Does that mean you wouldn't freeze clients? | 20:47 |
| mterry | kgunn, ^ do you remember who was looking into that? | 20:47 |
| * kgunn reads | 20:47 | |
| kdub | kgunn, it was the discussion about the different 'channels' of ipc requests need | 20:49 |
| kdub | circa wednesday? | 20:49 |
| kdub | and how acquiring new buffers does not need to be serialized at the protocol level with display requests | 20:50 |
| kgunn | kdub: mterry ....is this the long desire racarr topic of wanting to have a split queue on the server side.... | 20:50 |
| kgunn | in order to untangle unrelated events | 20:51 |
| kgunn | e.g. some events you don't want serialized in with the rest | 20:51 |
| kdub | yes | 20:51 |
| kdub | in as far as I understand the problem mterry is describingc | 20:51 |
| kdub | mterry, what i understand you to want is... | 20:54 |
| kgunn | mterry: kdub ...if that is it, then its racarr ....we were thinking maybe january | 20:54 |
| kgunn | see this bp | 20:54 |
| kgunn | https://blueprints.launchpad.net/ubuntu/+spec/client-1404-mir-performance | 20:54 |
| kgunn | kdub: yeah...i think your right...becuase this was exactly the point...seperating render queue fom things like power event queue | 20:55 |
| kgunn | btw...i have this one weird dysgraphic tick...i often type "g" for "q"....so if you see gueue in a minute..just replace w queue in your head | 20:56 |
| mterry | :) | 20:56 |
| kgunn | its totlally weird....they;re not even close on keyboard or in alphabet....evidence i think in shapes | 20:57 |
| mterry | kgunn, well, just so ya know, without that feature, locking delay might be enough of a regression to block landing split greeter. Can still develop feature branch on side, but in terms of landing, there's probs a dependency there | 20:58 |
| kgunn | mterry: ok....so its become more than just a nusance of that "stale" screen shot appearing | 20:59 |
| kgunn | ? | 20:59 |
| mterry | kgunn, yeah. The stale screen shot is still a nit, but even with that one frame fixed, there'd still be a couple seconds delay as the greeter comes up because Mir is preventing startup | 21:00 |
| kgunn | crap | 21:01 |
| kgunn | mterry: anyway...when i do get hold of racarr...we'll try to bump this in priority (at least the split q part) | 21:04 |
| kgunn | mterry: so to distill it into what you need...you need to be able to queue up rendering even tho the screen is off ? | 21:06 |
| kdub | we won't be able to do that | 21:32 |
| kdub | if the screen is off, more likely than not, the clocks are powered down :/ | 21:33 |
| mterry | kgunn, sorry, missed highlights. Yeah, I want to queue up rendering | 22:16 |
| mterry | kdub, if something is using cpu, I don't think we suspend everything | 22:16 |
| * mterry has to jet | 22:17 | |
| kgunn | kdub: mterry ...well actually you're wanting to "pre-render" just before waking the screen right ? | 22:17 |
| kdub | mterry, but we need the cpu, gpu, and bus clocks up to perform a render | 22:18 |
| kdub | mterry, i guess once 'power on' comes over dbus from powerd, you're probably okay to do a render there | 22:21 |
| * kdub writes iterator over SurfaceStack | 23:02 | |
| kgunn | kdub: did we get to the bottom of the exception in screen blank/unblank rapidly in succession ? | 23:06 |
| kdub | kgunn, no | 23:16 |
| kdub | kgunn, still around? | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!