[00:01] <racarr> in this little demo shell the application switcher event filter is constructed from in the_event_filters from, but needs to get the_frontend_shell() hich needs the_input_focus_selector() which needs the_event_filters() ;)
[00:02] <racarr> hmm. I don't think I have moved more than 15 feet since tvoss went to sleep
[00:13] <thomi> ugh - as an interim hacky solution, benchmark data is being stored here: https://code.launchpad.net/~mir-team/+junk/benchmark-graphs  - so please nobody delete that branch ;)
[00:53] <racarr> weird problems with my demo shell server configuration...seems the contents of my std::initializer_list are being lost in passing around
[01:08] <kdub> fbnativewindow defeats me another day :/
[01:09] <racarr> aww
[01:40] <smspillaz> hmm, neat http://codicesoftware.blogspot.com/2013/04/put-your-hands-on-programming-language.html
[01:40] <smspillaz> language aware merge tool
[02:11] <RAOF> Hm. Interesting. Build Mesa with clang and Mir segfaults.
[02:23] <RAOF> Woot!
[02:23] <RAOF> We draw!
[02:30] <duflu> RAOF: Still building Mir with gcc?
[02:30] <RAOF> Yes.
[02:31] <RAOF> Fun fact: A radeon 5350 can't render mir_eglplasma at 1920x1200 at 60 FPS
[02:31] <duflu> RAOF: My first guess is accidental writes to const variables (which are memory protected under clang)
[02:31] <duflu> RAOF: I'll look at optimizations :)
[02:41] <duflu> RAOF: Oh. eglplasma is trying to do 1.3 billion single precision cosines per second :/
[02:41] <RAOF> That's… quite a lot :)
[02:42] <duflu> RAOF: I've been thinking for some cases (like this) it may make sense to create a low-res surface and flag it as needing upscaling. The other case I thought of was simple games
[02:43] <RAOF> That's a part of the "fullscreen" request, isn't it?
[02:43] <RAOF> You say "make me fullscreen" with flags such as "and please change the output's resolution" or "upscale me if necessary" or etc.
[02:44] <duflu> RAOF: Yeah in the real world. Though some of our work-items are marked as DONE without such forethought :/
[02:44] <duflu> I've been guilty of similar
[02:44] <RAOF> Oh, have we marked fullscreen as done?
[02:44] <duflu> RAOF: No, that one's in progress pending my state work
[02:45] <RAOF> <value optimised out>
[02:45] <RAOF> MY NEMESIS!
[02:47] <duflu> RAOF: What was your frame rate BTW?
[02:47] <RAOF> 40 FPS
[02:48] <RAOF> Which is not bad for a two-generations-ago low-power GPU.
[02:48] <duflu> RAOF: Hah. I call that a great success then
[02:52] <duflu> Hmm, we're out by two orders of magnitude. Best I can find, AMD advertise the 5450 as "Processing power (single precision): 104 GigaFLOPS"
[02:53] <duflu> Though it's likely that cosine takes many FLOPS
[02:53] <duflu> This might also be a limiting factor: Pixel fill rate: 1.6 Gigapixels - 2.6 Gigapixels/sec
[02:54] <duflu> I can't find specs for 5350. Seems to happen with all my graphics cards too. They're always so low-end that the manufacturer does not publish their existence
[02:55] <RAOF> You can find it on http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units - it's an RV710
[02:55] <RAOF> Which has specs around what you've listed.
[02:58] <RAOF> Hm. With -O0 I can see why clang's failing - the glFlush pointer appears to be garbage.
[03:00] <duflu> glFlush has a "pointer"?
[03:00] <duflu> To the context?
[03:01] <RAOF> The dri2_drv structure has a glFlush function pointer.
[03:01] <RAOF> ...which is populated via dri2_drv->get_proc_address("glFlush"), which is presumably the thing that's broken.
[03:02] <RAOF> ...which, in turn, is dlsym()'d from _glapi_get_proc_address
[03:03] <RAOF> And clang does throw a warning somewhere in the mapi/glapi build, so that might be it.
[03:04] <RAOF> And that suggests that the problem is not in *my* code, and we build mesa with gcc, so I'm going to call it good :).
[03:07] <duflu> Sounds a bit odd. Plain old C issues with clang should be easy to resolve. I surprised Mesa is not yet clang-friendly
[03:11] <RAOF> Oh, it's Wednesday!
[03:12] <RAOF> That means it's SRU DAY!
[03:19]  * duflu wonders if the SRU/SRY pun has been overdone yet
[04:19] <thomi> behold: mir/glmark benchmark graphs: http://people.canonical.com/~thomir/
[04:19] <thomi> errr... kind of hacky, I know
[04:19] <thomi> now the preasure is on RAOF to fix that bug in mir :P
[04:19] <thomi> err, mesa
[04:22] <RAOF> The pleasure's all mine!
[04:28] <racarr> https://bugs.launchpad.net/mir/+bug/1167133 this stuf is weird
[04:29] <racarr> thomi: I see only 59 fps on one of the tests
[04:29] <racarr> I guess someone is to be fired.
[04:29] <smspillaz> isn't fps a bad metic ?
[04:29] <racarr> :p
[04:29] <racarr> yes
[04:30] <racarr> espescially when its capped to vsync ;)
[04:30] <thomi> right, so let's fix the vsync issue
[04:30] <smspillaz> I thought I read this article on arstechnica about measuring frame time
[04:30] <racarr> it's just a start
[04:30] <thomi> if anyone has any better ideas, I'm open to suggestions
[04:30] <smspillaz> racarr: the clear answer to this one is to just make mir hot-patch monitor firmware to make them refresh faster
[04:31] <smspillaz> "hey guys"
[04:31] <smspillaz> "my monitor goes at 50,000fps"
[04:31] <racarr> smspillaz: What do you think mir is doing no??
[04:31] <racarr> w*
[04:31] <smspillaz> "all thanks to mir"
[04:31] <racarr> we stole the code from beryl
[04:31] <smspillaz> racarr: you stole code from norwood?
[04:31] <racarr> err...^H^H^H
[04:32] <smspillaz> oh sorry, norwood is the protocol
[04:32] <smspillaz> I meant northfield
[04:32] <smspillaz> you stole code from northfield
[06:04] <robert_ancell> duflu, you seem to have a very unreliable computer!
[06:04] <duflu> robert_ancell: It was working fine. Then I upgraded gtalk
[06:04] <robert_ancell> alf_, racarr, meeting?
[06:05] <alf_> robert_ancell: ah, sorry I was waiting for a link on irc :)
[06:05] <robert_ancell> alf_, np :)
[06:06] <robert_ancell> kdub, ^
[06:12] <RAOF> Aaah, hangouts :)
[06:22] <alf_> robert_ancell: sorry, network died for a moment there
[06:22] <robert_ancell> alf_, :)
[06:24] <alf_> thomi: btw, glmark2 prints frametime if you prefer to parse and display that (although you could also calculate it yourself easily)
[06:24] <RAOF> Only if we're not vsyncd :)
[06:24] <duflu> Argh. Stupid audio subsystem. Now looks like system-wide, my audio goes to/from the wrong devices and ignores my selection of devices to use. It worked last week...
[06:25] <RAOF> Wheee!
[06:25] <duflu> It's even broken in gnome-control-center
[06:27] <duflu> Oh, and my other headphones that would have worked recently disintegrated from age
[06:55] <thomi> alf_: yeah, I have frametime - if you think that's a better metric to use it'd be simple to switch
[08:46] <RAOF> alf_: Do we need nouveau support for use-dma-buf before landing it? I've got radeon support.
[08:47] <RAOF> Eh, I'll just implement nouveau support as well. It's not like it's hard.
[08:47] <mlankhorst> erm
[08:47] <mlankhorst> didn't I do that? :P
[08:47] <RAOF> mlankhorst: That was in xmir; it needs mesa as well.
[08:47] <mlankhorst> oh
[08:47] <mlankhorst> glxgears seemed to have worked though
[08:48] <RAOF> You probably didn't do that, because the gallium changes you need only just landed on github :)
[08:48] <mlankhorst> ok
[08:48] <RAOF> Yeah glxgears will work. es2gears_mir won't :)
[08:48] <alf_> RAOF: Feel free to add nouveau now or leave it for later, I don't think it blocks anyone.
[08:49] <mlankhorst> it blocks meeeeeeee and I'm not a mesa developer
[08:49] <alf_> RAOF: ^^ well I guess you have your answer ;)
[08:50] <mlankhorst> alright alright I'll poke mesa some
[08:50] <RAOF> mankhorst: Ok. I'll do nouveau as well and land use-dma-buf tomorrow.
[08:50] <mlankhorst> RAOF: I was sarcastic :P
[08:51] <RAOF> Probably a better idea anyway; landing in the morning means I can put out fires at my leisure during the day.
[08:51] <mlankhorst> i'll fix up nouveau and any bugs I come across myself
[08:52] <mlankhorst> just put it somewhere
[08:54] <mlankhorst> RAOF: ^
[09:19] <RAOF> mlankhorst: github.com/RAOF/mesa - egl-platform-mir-dma-buf and mir-ppa.
[09:20] <mlankhorst> kk
[09:21] <RAOF> You need to implement whandle->type == DRM_API_HANDLE_TYPE_FD in bo_from_handle and bo_get_handle. See also: https://github.com/RAOF/mesa/commit/4deaa1bd5377e6224eb266f6a5c8e602f666aeff
[09:22] <RAOF> (You might notice the stunning kludge in that commit )
[09:23] <mlankhorst> aw, installing some armhf packages removes some amd64 ones
[09:27] <mlankhorst> libboost doesn't like multilib, it seems :(
[11:50] <mlankhorst> looks like my nexus 7 doesn't like mir either, I tried the instructions, but mir just crashes
[12:03] <mlankhorst> done with nouveau I think, I'm ignoring the GART stuff as it's unneeded with the kernel patches..
[12:03] <alf_> mlankhorst: for nexus 7, ping kdub, he should know more about what's up there
[12:04] <kgunn> mlankhorst: something about libhybris mods required only for nexus7 & only to egl...something about pthreads....platform team is workin' on it
[12:04] <kgunn> w kdub
[12:04] <mlankhorst> sounds about right
[12:27] <mlankhorst> RAOF: mir_egltriangle seems to work for me(TM)
[12:28] <mlankhorst> http://people.canonical.com/~mlankhorst/mir-mesa-nouveau.patch
[12:43] <mlankhorst> it's against the dma-buf branch but with debian from your ppa-dma-buf branch, which is why i disabled the egl-platform-mir patch
[14:59] <racarr> Morning!
[15:02] <kdub> good morning
[15:05] <alf_> racarr: kdub: Good morning!
[15:10] <alf_> status: Proposed VT switching MP, investigating potential performance improvements
[15:12] <kdub> status, working on stabilizing my fb branch, i suspect i'm not using the hwc right somehow
[15:30]  * kdub likes how a fresh day brings fresh perspective on problems 
[15:30] <kdub> mlankhorst, with the nexus 7, hybris at the moment, does not support process-shared pthreads (which the nvidia drivers need for sharing buffers with clients)
[15:59] <katie> morning racarr
[16:06] <racarr> Hi Katie!
[16:07] <katie> racarr, how's it going? do you have time for a brief hangout?
[16:15] <racarr> katie: Sure lets do it!
[17:23] <racarr> hmm xkbcommon-mapper test hangs on jenkins
[17:23] <racarr> for 120 minutes until jenkins quits ;)
[17:44] <racarr> comcast business = faster downloading of chroots woo
[18:56] <racarr> kdub: Did another around of updates on enable-inprocess-egl
[18:59] <kdub> racarr, will look it over shortly
[19:34] <racarr> kdub: more to xkbcommon-mapper too (I think the latest jenkins error there is a network quirk should be fixed soon)
[19:34] <racarr> fixed build in with FindXKBCommon.cmake :)
[19:54] <thomi> morning all
[20:01] <racarr> morning
[20:59] <robert_ancell> racarr, hello
[21:35] <kgunn> robert_ancell: hey...how did the team meeting go?
[21:35] <kgunn> robert_ancell: i literally woke up at 12:50 with no alarm....like an internal clock went off
[21:36] <robert_ancell> kgunn, we had alf, RAOF, duflu me and thomi there
[21:36] <kgunn> robert_ancell: i thot about joining....then thot better
[21:36] <robert_ancell> mostly did a round of "what we're doing" then talked about some CI stuff
[21:36] <robert_ancell> kgunn, good idea :)
[21:36] <kgunn> robert_ancell: bummer...no racarr or kdub?
[21:36] <robert_ancell> kgunn, no :(
[21:36]  * kdub is here
[21:37] <robert_ancell> kgunn, we found it funny that we moved the meeting to a better time but had less people!
[21:37] <kgunn> kdub: past tense
[21:37] <kgunn> robert_ancell: and alan was out
[21:41] <kgunn> robert_ancell: so did you know what to do after leaving that prd review with richard?
[21:42] <robert_ancell> kgunn, I didn't think we had any actions other than to keep him up to date on planning changes
[21:43] <kgunn> robert_ancell: i suppose we did agree to split out mir into pieces...like, input support, system compositor, app copy/paste etc
[21:43] <robert_ancell> kgunn, the PRDs not editable by us right?
[21:43] <robert_ancell> kgunn, and those splits are reflected in the blueprints
[21:45] <kgunn> robert_ancell: prd isn't editable but the m2m planning one is....
[21:45] <kgunn> i'm gonna take a crack
[21:45] <kgunn> i'll let you correct the damage :)
[21:46] <robert_ancell> kgunn, heh :)
[21:47] <thomi> I just finished configuring jenkins to graph mir autolanding build times. The result is: http://static.inky.ws/image/3841/showChart.png
[21:47] <thomi> tl:dr: it's getting longer
[22:01] <thomi> robert_ancell: got a minute?
[22:01] <robert_ancell> thomi, sure
[22:02] <thomi> robert_ancell: so WRT the lightdm autolanding, we need to hack the packaging stuff a bit. Lots of the PS projects have started using inline packaging, which makes it easier to keep the packaging & source code synced
[22:02] <thomi> so I could either propose a MP that adds the debian/ dir to lp:lightdm, *or* I could make a new branch: lp:lightdm-team/lightdm/trunk-packaging
[22:02] <thomi> it's up to you :)
[22:04] <robert_ancell> thomi, yeah, I'd prefer the packaging was separate as lightdm is used outside of ubuntu
[22:04] <thomi> robert_ancell: sure, OK.
[22:06] <thomi> I think there's some script that strips out the debian/ dir for "upstream" releases for Unity... but that's some deep juju that I have nothing to do with
[22:10] <kgunn> robert_ancell: hey is duflu going to propose his surface state stuff this week? (curious)
[22:10] <robert_ancell> kgunn, I though he was but I'm not 100% sure. I'll ask today
[23:01] <thomi> robert_ancell: any chance you could add me to the lightdm-team so I can push these packaging branches to be owned by that team?
[23:01] <robert_ancell> thomi, what's you LP id?
[23:01] <thomi> thomir
[23:02] <robert_ancell> thomi, done
[23:02] <thomi> thanks
[23:10] <RAOF> PSA: I've pushed the use-dma-buf mesa changes and marked use-dma-buf as approved. In the period while these things are not in sync, Mir EGL will not work.
[23:10] <RAOF> And by that I mean "Mir clients won't be able to use EGL"
[23:18] <racarr> robert_ancell: Merr...sorry...forgot about IRC.
[23:18] <racarr> ripping the InputDispatcher controller stuff (for focus) out of the InputManager to fix a focus  bug to make my demo shell work :)
[23:21] <racarr> I made a demo shell that fullscreens everything and adds and alt tab keybinding but it crashes when you cycle focus because
[23:22] <racarr> the second time a window is made focused the way we recycle the android window handles in set_input_focus_to
[23:22] <racarr> causes the InputChannel to be destroyed and recreated...closing the fd
[23:22] <racarr> triggering an assert!
[23:23] <racarr> So it seemed like a good time to just go ahead and bite the bullet and implement the proper focus selection where the dispatcher controller maintains a list of all the window handles (this is what is needed to enable picking for touch input as well)
[23:23] <racarr> but then it became a refactoring spiral
[23:24] <racarr> haha
[23:24] <racarr> almost done
[23:41] <racarr> RAOF: Do you think you could do another review of https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888 to override Alf's need's fixing (was fixed yesterday)
[23:41] <racarr> kevin approved so I think if you are ok with it we can land it
[23:41] <RAOF> racarr: Sure
[23:41] <racarr> Would like to land it so I can do a software cursor example
[23:41] <racarr> (a really funny one ;))
[23:43] <racarr> kdub: Does this mean anything to you https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/337/console
[23:43] <racarr> err, loaded question maybe :p but you know what I mean
[23:44] <kdub> racarr, no unfortunately :/
[23:45] <racarr> hmm
[23:45] <racarr> ill try a rebuild in an hour or so and maybe it will fix itself
[23:45] <racarr> if not investigate deeper