| === duflu_ is now known as duflu | ||
| alan_g | alf_: anpok - any ideas for a "better interface"? https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069/comments/476680 | 08:26 |
|---|---|---|
| anpok | hm they could decorate the exsting policy, all they need is just selecting alpha when needed and supported - thats effectively just find_if | 09:01 |
| anpok | like in the translucent server example | 09:01 |
| duflu | On the issue of translucency... I recently discovered that making a client translucent was a big enough hit to rendering time that it could trigger clone mode frame drops, sometimes with a single client. Alpha blending is still relatively expensive, even on a Haswell desktop | 09:05 |
| alan_g | That's a bigger hit than I was expecting | 09:05 |
| anpok | duflu: how big was the client? | 09:05 |
| duflu | anpok: 1920x1200 | 09:05 |
| anpok | oh | 09:06 |
| duflu | alan_g: It was mostly due to the clone mode bug I have a fix proposed for. After that's resolved, full screen blending has no visible performance hit | 09:06 |
| alan_g | Excellent | 09:07 |
| anpok | but still it means that the blending of one output took longer than the update rate of the other output | 09:07 |
| anpok | maybe we should allow clients to provide opaque rects together with the buffer | 09:07 |
| duflu | Kind of. The issue with the clone mode bug is that we potentially have zero (or very little) rendering time at all | 09:08 |
| anpok | alan_g: i could image a better interface | 09:08 |
| anpok | alan_g: something like select( Requires(Exactly(1280x768), Try(OpaqueBuffer)); | 09:09 |
| anpok | bbl | 09:09 |
| alan_g | anpok: worth discussing with greyback & mterry when you're back? | 09:10 |
| anpok | alan_g: duflu: I would like to add something like a generic report->trace_time_span("string_id", { start,duration} ); | 09:10 |
| anpok | but still wondering where and how to visualize | 09:11 |
| anpok | alan_g: i think so.. | 09:11 |
| anpok | duflu: but the translucent greeter is translucent everywhere.. | 09:12 |
| anpok | duflu: maybe we should use the screencast feature for that | 09:12 |
| duflu | anpok: I feel that measuring time spans is best hidden inside the report implementations. The interfaces should always just be begin... and end... | 09:12 |
| duflu | Not least because the Null report should be Null | 09:13 |
| alan_g | anpok: I'm not sure that interface is the easiest to use - usually you'd want something like "Trace trace(report, "ID"); | 09:13 |
| duflu | AFK, wireless kbd issues | 09:13 |
| duflu | wfASJL: | 09:13 |
| anpok | duflu: agreed but, we dont have that many possible measure points - maybe that is enough - and i just have issues following the code flow. | 09:13 |
| duflu | fscas | 09:13 |
| anpok | and i wonder if we could make that not affect the performance at all without instrumenting the build | 09:15 |
| duflu | anpok: That's the point of defaulting to a null report with minimal parameter passing :) | 09:17 |
| duflu | Eek, I forgot what the old keyboard was like | 09:17 |
| alf_ | duflu: @async-page-flips, I don't get where I am mistaken... after we schedule a page flip we draw to a buffer that is still potentially being scanned out (since we don't wait for the page flip to complete). We can't touch a buffer that is currently on screen after a page flip, before the next page flip occurs, scanning out is not an instantaneous process. | 09:23 |
| duflu | alf_: Preparing for EOW, but let me see if I can find an answer before that | 09:25 |
| duflu | alf_: Mesa/EGL/GBM still has separate front and back buffers (obviously). The existence and rendering of the back buffer is kind of implied. But after we have called gbm_surface_lock_front_buffer we hold the locked buffer until the flip has definitely completed. This prevents the buffer from being recycled and rendered to as a back buffer while it's visible. | 09:37 |
| duflu | Aside from anything else... if you do accidentally render to the scanout buffer you will see ugly tearing | 09:38 |
| duflu | At least I do | 09:38 |
| duflu | But if you can prove it wrong, that would be appreciated. | 09:39 |
| duflu | Plus, I know the algorithm is complicated. Even *if* it is bug free, I don't expect us to digest and approve it quickly | 09:40 |
| * duflu runs away | 09:40 | |
| sil2100 | alf_: hi! Any luck with the mir unit-tests hanging up on armhf? | 10:49 |
| alf_ | sil2100: no... I can't reproduce them locally at all, and I have no idea what could be hanging so consistently in the builders | 10:50 |
| sil2100 | Troublesome... | 10:54 |
| sil2100 | hm hm | 10:54 |
| === alan_g is now known as alan_g|dentist | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g|dentist is now known as alan_g|lunch | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g|lunch is now known as alan_g | ||
| kgunn | sil2100: i also build lp:~mir-team/mir/trunk-0.1.4 natively and ran unit tests just fine | 14:14 |
| kgunn | sil2100: can we gain access to the calxeda machines ? don't know what else to do | 14:15 |
| kgunn | sil2100: curious, i used image 155 that was in devel-proposed....is that a valid configuration to try and replicate what's happening on the calxeda ? | 14:16 |
| sil2100 | kgunn: the thing is that we have no idea what triggered that, as it was passing fine earlier - who knows if those wouldn't pass now... did you guys check the code for some obvious race conditions? | 14:17 |
| sil2100 | kgunn: we tried poking people about access to the devices, but it seems it's not as easy as we thought | 14:17 |
| kgunn | sil2100: are the logs still out there ? (i don't think so as silo 005 got reused) | 14:18 |
| kgunn | sil2100: we've spent loads of time before christmas cleaning up tests | 14:18 |
| kgunn | sil2100: so doubt there'd be anything "obvious"....but if there are some logs that might indicate a particular test that would be interesting | 14:19 |
| sil2100 | kgunn: I think the logs are still there, but there was not much useful logs - just that it was hanging on, I think, the 3rd unit test | 14:20 |
| kgunn | sil2100: do you know what changed ?? that could have possibly made the unit test start to fail ?...e.g. if it was passing on tuesday...what went into the build between now and then ? | 14:20 |
| sil2100 | kgunn: nothing, the PPA was in a clean state, so the problem had to be there earlier I guess? Let me find the logs | 14:20 |
| sil2100 | kgunn: it started hanging up here https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5533752 | 14:21 |
| kgunn | sil2100: thanks | 14:21 |
| kgunn | sil2100: hang on....i thot you said mir was failing...that's unity-mir | 14:22 |
| sil2100 | Ah, wrong link! | 14:22 |
| sil2100 | One moment | 14:22 |
| sil2100 | ;) | 14:22 |
| * sil2100 ashamed | 14:23 | |
| sil2100 | kgunn: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5535453 | 14:23 |
| kgunn | sil2100: no worries...i stay permanently "ashamed" :) | 14:23 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === greyback_ is now known as greyback|food | ||
| === greyback|food is now known as greyback | ||
| kgunn | sil2100: you still there ? | 17:14 |
| kgunn | sil2100: any chance we can get a silo ? | 17:14 |
| kgunn | sil2100: we've got a potential fix for the calxeda unit test hang | 17:15 |
| sil2100 | kgunn: ! | 17:16 |
| sil2100 | kgunn: still here :) | 17:16 |
| sil2100 | kgunn: let me clean up some silos though | 17:16 |
| kgunn | sil2100: thanks and no problem... | 17:16 |
| kgunn | i know its getting late there | 17:16 |
| kgunn | bbiab | 17:26 |
| sil2100 | kgunn: ok, so I think it won't be so easy... it seems platform-api is right now blocking the slot, so until it's not released we won't be able to fill mir in | 17:39 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOW | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!