| RAOF | :) | 00:01 |
|---|---|---|
| bschaefer | hello, getting a fun failed to mmap a buffer, only when running it through SDL: http://paste.ubuntu.com/7317028/. demo multiwin works fine :( | 03:26 |
| bschaefer | the mir surface is created, and is valid | 03:26 |
| duflu | bschaefer: Weird buffer dimensions/attributes? Tested other software buffer demos like "progress" or "fingerpaint"? | 03:34 |
| bschaefer | duflu, i tested outt he pixel formate, which was fine | 03:37 |
| bschaefer | duflu, alright | 03:37 |
| bschaefer | duflu, hmm they appear to be working, i check what other info in the surface creation bit i could be messing up | 03:39 |
| duflu | bschaefer: Either that or a buffer/structure overrun could be corrupting some critical field | 03:39 |
| duflu | (valgrind) | 03:39 |
| bschaefer | duflu, good idea! | 03:40 |
| duflu | bschaefer: Please also update this :) https://bugs.launchpad.net/mir/+bug/1247943 | 03:41 |
| ubot5 | Launchpad bug 1247943 in Mir "Mir server failing to start when compiled for 32bit" [High,New] | 03:41 |
| duflu | bschaefer: Oh, which driver? | 03:41 |
| bschaefer | duflu, that was me a bit ago, on intel | 03:42 |
| * bschaefer updates | 03:43 | |
| bschaefer | duflu, hows all else going? | 03:45 |
| duflu | bschaefer: Busy. And this week is book-ended by two public holidays in Oz | 03:50 |
| duflu | bschaefer: How's your end? | 03:50 |
| duflu | sunny Seattle :) | 03:51 |
| bschaefer | duflu, raining atm :) | 03:51 |
| bschaefer | duflu, Oz, sounds like fun! | 03:51 |
| duflu | Follow the yellow... lawn? | 03:52 |
| bschaefer | haha | 03:52 |
| bschaefer | duflu, summer coming to a nice warm end? | 03:52 |
| * bschaefer is just now starting to hit some summer days | 03:52 | |
| bschaefer | duflu, valgrid, i've not dug through it yet.... lots of info.. http://paste.ubuntu.com/7319558/ | 03:55 |
| bschaefer | did mir move to using ShmMemory? | 03:56 |
| * bschaefer doesn't remember that being around a while ago | 03:56 | |
| duflu | bschaefer: Just search for your own code to narrow it down. Then again, a simple overrun clobbering just Mir structures would not be detected as an overrun within the context of the client process :P | 03:57 |
| duflu | bschaefer: Yeah Mir's software buffers implementation changed some months ago | 03:57 |
| bschaefer | duflu, ill check it out :) | 03:57 |
| bschaefer | it has to be my issue haha | 03:57 |
| bschaefer | duflu, thats for the help! | 03:57 |
| bschaefer | thanks* | 03:57 |
| duflu | bschaefer: No problem | 03:58 |
| duflu | Whee, new Ubuntu release, new flood of teething bug reports | 04:12 |
| racarr__ | UTOPIC UNICORN | 04:46 |
| RAOF | uTopic unicorn :) | 04:52 |
| duflu | Whoa. Utopic Unicorn | 05:39 |
| * duflu wonders what this means for Ubuntu and its relevance to reality | 05:40 | |
| === chihchun_afk is now known as chihchun | ||
| anpok | RAOF: ping | 07:57 |
| RAOF | anpok: Pong | 07:57 |
| anpok | two days ago it was unsure wether your 1hz branh would make it in so I too the timer parts | 07:58 |
| anpok | and proposed them as a separate branch | 07:58 |
| anpok | now it seems like the 1hz branch would make it after 0.1.9 | 07:58 |
| anpok | or I am not sure.. | 07:58 |
| anpok | I need the functionality for the input stuff | 07:59 |
| RAOF | Heh. | 07:59 |
| anpok | and did not want to duplicate anything | 07:59 |
| RAOF | I can rebase on your branch if you like. | 07:59 |
| anpok | ok - since i would adress findings as far as possible that come up in https://code.launchpad.net/~andreas-pokorny/mir/add-timer-to-main-loop/+merge/216881 | 08:00 |
| anpok | that would be cool | 08:00 |
| RAOF | anpok: Yeah. Go for your life; address Alan's concerns, and I'll merge on top. | 08:00 |
| * RAOF -> EOD | 08:03 | |
| duflu | Hmm, my monitor exposes 50Hz modes on DisplayPort but not DVI? | 08:14 |
| duflu | ? | 08:14 |
| dandrader | anpok, got the qt compositor working with lp:~andreas-pokorny/mir/input-sender-split | 12:28 |
| dandrader | anpok, good work! | 12:28 |
| anpok | great news! | 12:42 |
| kgunn | dandrader: anpok ....that is really nice work! | 12:52 |
| kgunn | anpok: think we could try to get that landed onto dev branch in the next few days ?....it'd be really great if we could bring that along with our 0.1.9 tag | 12:53 |
| kgunn | note: i'm not going to tag until we address a couple of regressions | 12:53 |
| anpok | ah ok - i thought we would wait for after 0.1.9. I will try to clean things up | 12:54 |
| kgunn | anpok: i'll take your lead, i would like it in 0.1.9 but if you think it injects too much risk that's worth considering... | 12:57 |
| anpok | the way it is built right now, makes it work kind of in parallel to the existing dispatcher code. hence the risk is low.. | 12:58 |
| anpok | of course at some point i will remove the old send path.. | 12:58 |
| kgunn | anpok: thanks...that's good to hear, since we're at the beginning of cycle i'd like to get it into 0.1.9, risks are easier to swallow :) | 13:04 |
| kgunn | so its worth waiting on for a day or 2 for sure | 13:04 |
| === dandrader is now known as dandrader|bank | ||
| alf_ | kgunn: which regressions do we need fixes for before 0.1.9? | 14:13 |
| kgunn | alf_: we have this list... | 14:14 |
| kgunn | https://launchpad.net/mir/+milestone/0.1.9 | 14:14 |
| kgunn | but in reality there are 2 that i'd consider musts | 14:14 |
| kgunn | 1308843 | 14:14 |
| kgunn | 1308941 | 14:15 |
| kgunn | ....and this one kinda troubles me 1294510 | 14:15 |
| alf_ | kgunn: 1308843 is not as bad as it sounds, and doesn't seem to affect the phone... I would propose ignoring it for 0.1.9, because it is going to be fixed by the "1Hz" branch, but we can't land the 1Hz branch for 0.1.9 because we will need to become more confident in it. | 14:19 |
| alf_ | kgunn: unless we say that we postpone 0.1.9 for some time until 1Hz has been tested properly | 14:23 |
| kgunn | alf_: hmmm, i understand now...it does stink b/c we definitely want to land this sooner than later | 14:26 |
| kgunn | alf_: how come it doesn't manifest on the phone ? nested ? | 14:26 |
| alf_ | kgunn: I can't see it on any of my computers, so I don't have first hand experience, but my understanding is that the effect this has depends on the vsync timings of the outputs (in this case the real output and the fake 60Hz one) | 14:31 |
| kgunn | alf_: right, i was kind of assuming that the fake 60 hz will never be perfect for any display, timing will always be off somewhere | 14:32 |
| kgunn | i guess, if the fake is a bit slower than the screen you're ok? | 14:33 |
| === alan_g is now known as alan_g|tea | ||
| alf_ | kgunn: Right. So one thing we could potentially do for 0.1.9 and should be relatively safe is reduce the fake output rate to something sufficiently small e.g. 10Hz. | 14:45 |
| racarr__ | Guten morgen | 14:46 |
| alf_ | kgunn: oops, that won't work | 14:46 |
| anpok | racarr__: Guten Tag | 14:47 |
| racarr__ | :) | 14:47 |
| racarr__ | *races breakfast with standup* | 14:48 |
| === alan_g|tea is now known as alan_g | ||
| josharenson | kgunn, current graphics dashboard is broken down by resolution and GPU manufacturer. Keep that format, or categorize by device? | 16:36 |
| === dandrader|bank is now known as dandrader | ||
| kgunn | josharenson: mmm, can we expand ?...to include formfactor {phone, tablet, desktop} | 17:00 |
| kgunn | we should keep screen res | 17:00 |
| kgunn | and gpu | 17:00 |
| kgunn | for sure | 17:00 |
| kgunn | or... if not formfactor, device name.... mako, manta, macbook, dell### | 17:01 |
| josharenson | kgunn, I can probably add that... the website looks like it was originally written to show desktop performance | 17:01 |
| === alan_g is now known as alan_g|EOD | ||
| josharenson | its organized only by resolution and gpu, but can probably add anything | 17:02 |
| josharenson | kgunn, I'll work on resolution and gpu for now (cause thats what there) and add other criteria later. I'll let you know if there are issues with that... | 17:03 |
| kdub | alf_, once I fix https://code.launchpad.net/~kdub/mir/plumb-android-shader-creation/+merge/216779/comments/515830, would you be okay with a top-approve? | 17:07 |
| racarr__ | A moment of silence for null cursor *bows head* | 17:24 |
| josharenson | robotfuel, I'm working on extending the qa-dashboard/graphics page and was wondering what the significance of the "ps" prefix to the names of all gpus? | 17:25 |
| robotfuel | josharenson: it's product-strategy the name of the group that owned the machines. | 17:30 |
| kgunn | alf_: hey, so looks like i can tag the tip of devel... | 17:31 |
| kgunn | anything else outstanding that needs to merge ? | 17:31 |
| kgunn | anyone ^ | 17:31 |
| josharenson | robotfuel, ah thanks... any reason to preserve that convention? even if other machines? | 17:31 |
| kgunn | otherwise i'll do it this afternoon....and apologize to duflu at the same time :) | 17:31 |
| robotfuel | josharenson: no it was the name of the machine, that's all. ps was absorbed in to ubuntu engineering. | 17:32 |
| josharenson | robotfuel, ack | 17:33 |
| kdub | kgunn, I'm okay to merge | 17:37 |
| racarr__ | +1 | 17:38 |
| racarr__ | mieqEnqueue | 17:40 |
| racarr__ | for some reason that breaks my brain | 17:41 |
| racarr__ | (random x server function lol) | 17:41 |
| kdub | they just mis-spelled meek... see meekEnqueue | 17:41 |
| kdub | like a polite equeuement, obviously | 17:41 |
| racarr__ | hahaha | 17:44 |
| racarr__ | common locking pattern, reader, writer, and meek writer. | 17:45 |
| AlbertA | kgunn: https://code.launchpad.net/~vanvugt/mir/fix-1308941/+merge/217021 | 17:46 |
| AlbertA | kgunn: that should probably land so 1308941 is taken care of | 17:46 |
| kgunn | AlbertA: thanks...i'll keep an eye on it | 17:52 |
| racarr__ | yay shift key now outputs | 18:07 |
| racarr__ | m6 hwich must mean | 18:07 |
| racarr__ | xmir input is close to working | 18:07 |
| racarr__ | ;) | 18:07 |
| racarr__ | as in now just mapping is off | 18:07 |
| racarr__ | very off apparently | 18:07 |
| racarr__ | but besides that getting close lol | 18:07 |
| anpok | racarr__: mapping as in mapping of different keyboard types? | 18:14 |
| racarr__ | well just somewhere int he mapping of scan code to key code | 18:30 |
| racarr__ | something has gone wrong | 18:30 |
| racarr__ | as usual the answer was add or subtract 8 from scan code | 18:32 |
| racarr__ | :p | 18:32 |
| racarr__ | in this case its add 8 when going from mir scan code to x scan code | 18:32 |
| AlbertA | racarr__: can I add that comment on all bugs? "Did you try adding 8?" ;) | 19:09 |
| AlbertA | or 42 could work too... | 19:09 |
| racarr__ | AlbertA: on all input related bugs I think its a fair comment lol | 20:33 |
| racarr__ | </lunch> | 20:33 |
| racarr__ | probably top 10 lunches of the year so far. | 20:35 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| josharenson | robotfuel, just wanted your opinion... after looking at all the code, it seems creating a standalone 'performance test' category, rather than nesting under 'graphics' seems like a good idea... thoughts? | 21:16 |
| racarr__ | hahaha watching the xmir cursor follow | 21:23 |
| racarr__ | the mir cursor | 21:23 |
| racarr__ | is my new hobby | 21:23 |
| racarr__ | in other news increasming amounts of xmir input | 21:23 |
| racarr__ | work | 21:23 |
| kgunn | josharenson: camako and i were talking about comparing mir & SF | 21:38 |
| josharenson | kgunn ok | 21:38 |
| kgunn | question is, do you know if Qt on the QPA for SF just renders as if the Qt engine were a full screen app on SF ? | 21:38 |
| racarr__ | Everything (including the shell) is in fact a full screen app on SF right? | 21:39 |
| racarr__ | no in process shell or any such..suchness | 21:39 |
| josharenson | kgunn, are you trying to determine something about bypass? | 21:40 |
| josharenson | kgunn, cause I'm not sure, but if you dump layer contents, it should be obvious | 21:40 |
| kgunn | josharenson: not really about bypass...more like trying to satisfy the question of is mir on par with sf | 21:40 |
| josharenson | kgunn which I'm not sure how to do in ubuntu.... only android | 21:40 |
| kgunn | kdub: would know | 21:41 |
| kgunn | racarr__: true...no in process shell | 21:41 |
| kgunn | racarr__: also true...no nested | 21:41 |
| kgunn | hmmm | 21:41 |
| kgunn | makes comparing more difficult me thinks | 21:41 |
| kdub | kgunn, I know the stuff we have to improve, yes | 21:41 |
| robotfuel | josharenson: there are already people working on performance tests, ping cgoldburg or nuclearbob | 21:42 |
| kdub | kgunn, or did you mean something else? | 21:42 |
| kgunn | kdub: something else...but i think racarr__ negated it | 21:42 |
| kdub | right, at the end of the day, its tough to get an apples-to-apples of the whole stack | 21:43 |
| kgunn | robotfuel: do you know what kind of performance tests ? are they to compare sf & mir ? | 21:43 |
| kdub | and some of the key differences are in driver details that are abstracted from us | 21:43 |
| robotfuel | kgunn: no all kinds of performance tests. | 21:43 |
| kdub | so its tricky to negate the goodness or badness of the particular driver | 21:43 |
| kgunn | kdub: camako josharenson ...i'm starting to wonder, would a simple native gl test written specifically native to sf and then native to mir be the only wya ? | 21:43 |
| kgunn | way | 21:44 |
| robotfuel | kgunn: not sf vs mir | 21:44 |
| camako | kgunn: So we are measuring graphics perf? | 21:45 |
| kdub | kgunn, even at that, there's some serious headaches | 21:45 |
| kdub | like if you have "setprop debug.mdpcomp.maxlayer" set to two vs four on mako, you might get different results that take a while to figure out | 21:46 |
| kdub | or if you happen to run on tegra3, the hybris pthread issue might bite | 21:46 |
| camako | kdub: what is mdpcomp.maxlayer switch for? | 21:47 |
| camako | hw overlays? | 21:48 |
| josharenson | what exactly are you trying to measure? just general performance? | 21:48 |
| kdub | its just a mako switch for if the hwc happens to select the mdp core, to limit the number of layers it will accept :) | 21:48 |
| kdub | just making the point that there are sorts of little gotchas there that a quagmires to sort out | 21:49 |
| camako | kgunn: any non-trivial graphics apps should produce the same result (fps?) on mature platforms | 21:50 |
| camako | emphasis on "should" and "mature" | 21:50 |
| kdub | camako, right, agree | 21:51 |
| kdub | but also, the result is fps+power | 21:51 |
| camako | kdub: yes, cpu bw, mem bw, etc... | 21:51 |
| kdub | right | 21:52 |
| camako | I guess without messing w any switches, comp at gl level would make sense to answer "is mir up to par with Android?" | 21:53 |
| camako | Assuming we don't already know the answe :-) | 21:53 |
| racarr__ | We dont know the answer wrt power. | 21:53 |
| racarr__ | But of course both are capable of rendering rectangles at 60hz in isolated conditions | 21:54 |
| kdub | right | 21:54 |
| camako | I see | 21:54 |
| racarr__ | interesting sort of questions to me are like | 21:54 |
| kdub | like, and the other side is, are we capable of explaining any deltas? | 21:54 |
| racarr__ | say same EGL app rendering at vsync on mir and SF and measure power | 21:55 |
| racarr__ | hmm? You mean deltas over time or deltas | 21:55 |
| racarr__ | v. surface flinger | 21:55 |
| kdub | vs surfaceflinger | 21:55 |
| camako | then I guess gl perf would make sense | 21:56 |
| camako | gl perf comp* | 21:56 |
| camako | josharenson: kgunn mentioned you were (or would) work on this, have you started this comp effort bw sf and mir? | 21:57 |
| kdub | but like, do we have control over the gl drivers? we're just comparing (switching logic + ipc roundtrip) then | 21:58 |
| josharenson | I have a test that runs glmark2.... | 21:58 |
| josharenson | camako, but if we just need a simple gl app... | 21:58 |
| camako | kdub, correct... Do we care to have control over the gl drivers since what we develop is outside those | 22:00 |
| racarr__ | ok if you ignore everything that isnt a 3button+2axis mouse or a us english keyboard | 22:01 |
| racarr__ | and dont click on buttons at the same time | 22:01 |
| racarr__ | xmir input is workin perfectly :D | 22:01 |
| camako | kdub, like a stock system-level comparison.. what an avg user would experience... | 22:01 |
| racarr__ | as part of the overall process of ubuntu | 22:02 |
| racarr__ | its good to have gl performance benchmarks | 22:02 |
| kdub | like, we can plumb mir/unity8 to get that information, and its good for analyzing, but to compare to surfaceflinger | 22:02 |
| racarr__ | in terms of comparing mir to other compositors | 22:02 |
| racarr__ | I dont think its useful | 22:02 |
| kdub | we have to plumb surfaceflinger at the same points | 22:02 |
| camako | fps, cpu %, power consumption don't require mir/unity specific plumbing, do they | 22:05 |
| kdub | well, not to measure those, but if we investigate, and figure out the ipc is slow or something, we do | 22:06 |
| camako | kdub, I agree that comp at that granularity is not useful. | 22:08 |
| camako | kdub: I don't know what info kgunn wanted to get out of it, but I think it'd be useful to get those readings for a simple app on mir vs SF for comps | 22:08 |
| camako | Or may be not... :-) | 22:08 |
| camako | those readings being fps, cpu%, power | 22:10 |
| kdub | sure, but we're already in the ballpark though | 22:10 |
| camako | kdub, someone measured already? | 22:11 |
| kdub | camako, measured what? :) | 22:15 |
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!