[03:40] <duflu> RAOF: You didn't seem excited when I pointed out your branch improved performance... ?
[03:41] <RAOF> duflu: It's neat, but it's not really the point :)
[03:42] <duflu> Nice freebie
[03:42] <duflu> And quite unexpected that we can reduce round trip time at all, especially without trying
[03:44] <RAOF> Well, it can help when you don't have to do quite so much queuing on the main loop.
[03:45]  * duflu isn't familiar with any of that newfangled main loop stuff
[03:45] <duflu> Probably just as well or else I might have an opinion
[03:45] <duflu> But there are other problems to be worked on...
[03:49] <RAOF> Not newfangled :)
[03:50] <RAOF> Before the rework all IO was being deferred to the IO mainloop, afterwards you just write().
[05:50] <duflu> RAOF: Care to reconsider? https://code.launchpad.net/~vanvugt/mir/fix-1338902/+merge/225929
[05:51] <RAOF> duflu: You don't seem to have fixed the race?
[05:51] <duflu> RAOF: What race?
[05:51] <RAOF> Between if(locked) and locked = false.
[05:51] <RAOF> Unless the event handler cannot be called from multiple threads, in which case you've got a spurious std::atomic<bool> :)
[05:52] <duflu> RAOF: Yes the latter
[05:52] <RAOF> Ah. Then drop the std::atomic and I'll reconsider :)
[05:53] <duflu> RAOF: The whole only works from one particular thread thing is fragile, but I wasn't aiming to fix everything about that code
[05:54] <duflu> RAOF: So is anyone else building on utopic or am I just unlucky to have that test failing constantly?
[05:54] <RAOF> Then why not replace with if(locked.compare_exchange_strong(true, false) ?
[05:54] <RAOF> I build on Utopic; you're just unlucky to have that test reproducibly fail.
[05:55] <RAOF> Or lucky, depending on your perspective :)
[05:56] <duflu> I hate compare/exchange ops. They always mess with my head and require surprisingly careful thought every time I see one
[05:57] <duflu> But they're often necessary
[06:08] <duflu> RAOF: Done
[06:09] <RAOF> Is it really pending Nick's approval?L
[06:10] <duflu> RAOF: Not really. That was just if he's curious (since I think he's the only one the test is meaningful to)
[06:10] <RAOF> In which case... top-approved.
[06:11] <duflu> Whee... and then I won't have every branch failing the same test
[07:13] <duflu> sil2100: Hello?
[07:28] <duflu> anpok: How goes life with Mesa/GBM?
[07:32] <sil2100> duflu: morning
[07:32] <duflu> sil2100: Morning. Do you have any thoughts on this? https://code.launchpad.net/~vanvugt/mir/fix-changelog-0.4.0/+merge/225608
[07:35] <sil2100> duflu: let me take a look, hmm
[07:44] <anpok> duflu: moving to the kernel now
[07:45] <duflu> anpok: Umm, good (?)
[07:45] <duflu> sil2100: Thanks
[07:46] <anpok> duflu: different source code quality  :)
[07:46] <duflu> anpok: What in the kernel needs fixing?
[07:46] <anpok> page flipping
[07:46] <duflu> anpok: Oh, vesa doesn't do it?
[07:47] <duflu> Or is it some hypervisor driver?
[07:47] <anpok> hm qxl needs it - I think most if not all of the others provide it
[07:47] <anpok> e.g. the displaylink driver recently received support for it
[07:47] <duflu> Oh, right. Pity we can't say the kernel fixes from last year provide minimum Mir support :(
[07:48] <anpok> the qxl-spice protocol does not seem to provide something like swap command or plane configuration command
[07:49] <anpok> so I will first investigate what it would take to make a clean solution before I settle with - just copy it.
[07:49] <duflu> anpok: If there's no display hardware to accelerate the scanout offset setting then there's no performance benefit to implementing it in the kernel over userspace. Userspace would at least provide better kernel compatibility... (?)
[07:50] <anpok> but .. i mean it could be done .. if the host system allocates the buffers we could do bypass all steps to the host
[07:51] <duflu> anpok: Oh, yes.
[07:52] <anpok> duflu: well the user space fallback would have to go into mesa eglSwapBuffers and into mir and for mir we would need another mesa api to mmap the buffer
[07:52] <anpok> which is not complex either
[08:00] <sil2100> duflu: yw!
[09:07] <duflu> greyback: I'm doubting my sanity now. I think triple buffers has high latency, but actually with the current protocol design, double may not be any better
[09:07] <duflu> I wonder what I was thinking back in May !?
[09:08] <greyback> duflu: why would double not be better?
[09:08] <duflu> greyback: Because the swapping protocol still requires a round trip, either way
[09:08] <duflu> We can eliminate that round trip delay with a protocol change, but only triple-buffers would benefit
[09:11] <greyback> duflu: I can't remember the details of our discussion to make a good argument :(
[09:11] <duflu> greyback: Me too. It's present me vs past-me
[09:11] <greyback> older and wiser you
[09:23] <duflu> greyback: I sense more grey hair coming on
[10:07] <ogra_> duflu, the traceback in bug 1339610 is from the smoke tests (that crash causes 34 failures in ui-toolkit tests) ... since it has to install the test suites it cant relly work without PPAs ...
[10:09] <duflu> ogra_: OK, well I tried looking into the offending function. It's trivial and has no reason to crash without further details :(
[10:09] <ogra_> :8
[10:09] <ogra_> :( even
[10:09] <duflu> And then it was dinner time
[16:41] <desrt> hihi
[16:41] <desrt> just tried to build the 0.4.0 release of mir -- it fixed some issues... but there is still this one hitting me: https://bugs.launchpad.net/mir/+bug/1323031
[16:42] <desrt> we already had a patch for it in jhbuild, so i'll just roll it over.... this is really just a 'reminder' :)
[17:31] <davmor2> kgunn: so tomorrow AM I'm going to start testing Qtcomp on mako manta and flo.  Is there anything other than testing that nothing breaks or is more broken that at present that I need to do?
[17:32] <kgunn> davmor2: it should be on par except for the one sidestage exception i describe in the wiki
[17:32] <davmor2> kgunn: no worries then
[19:42] <racarr_> I hope everyone is enjoying the cursor color change
[19:42] <racarr_> :p
[19:50] <racarr_> what is round trip time to a modern GPU
[19:51] <kdub_> like, round trip over ipc?
[19:51] <racarr_> no I mean like just from CPU to GPU
[19:51] <racarr_> not content flush or anything
[19:51] <racarr_> just like hey ping GPU
[19:52] <kdub_> like, command submission to some sort of end point?
[19:54] <racarr_> yeah or something like that.
[19:54] <racarr_> It doesn't really matter lol, im just curious all of a sudden.
[19:55] <kdub_> like, writing to a register is fast of course, the time comes from processing/pushing pixels
[19:56] <racarr_> Mm but I mean writing to a register
[19:57] <racarr_> is slower than writing to a register on the CPU
[19:57] <racarr_> so by how much?
[19:59] <racarr_> I guess it has to be slower than writing to system memory
[19:59] <racarr_> which basically answers my question "its a lot slower" :p
[19:59] <kdub_> racarr_, yeah, i'd guess so, but in the same ballpark
[20:13] <racarr_> mm
[20:13] <racarr_> ah the joy of arguing over totally speculative performance points in small text boxes in the web browser.
[20:13] <racarr_> (touchspot-visualizer :p)
[20:14] <kdub_> yeah... well you have a +1 from me :D
[20:15] <racarr_> :)
[20:15] <racarr_> cursor as a renderable will be up soon and make it more clear
[20:15] <racarr_> just getting the mesa hardware cursor to work again
[20:22] <bschaefer> racarr_, the mouse looks to real now :)
[20:22] <bschaefer> cursor*
[20:24] <racarr_> lol
[20:24] <racarr_> bschaefer: p.s. you can implement cursor support in SDL if you want
[20:24] <bschaefer> racarr_, yay!
[20:25] <racarr_> bschaefer: In cursor-spike-phase-7 (up for review) there are mir_curosr* names for the different cursors.
[20:25] <bschaefer> racarr_, sweet, that'll be fun to get in :)
[20:25] <racarr_> so I guess not quite yet lol
[20:25] <racarr_> yes its surprisingly satisfying to watch the cursor change
[20:25] <bschaefer> but i can at lease see the api haha
[20:25] <racarr_> yeah just mir_surface_configure_cursor
[20:26] <bschaefer> racarr_, nice! also was hotspot implemented?
[20:26]  * bschaefer remembers you mentioning it wasn't before
[20:47] <racarr_> bschaefer: indeed
[20:48] <racarr_> it is implemented that is
[20:48] <bschaefer> implemented is always nice, didn't see it mentioned in the client api
[20:49] <racarr_> oh well there is no client side cursor upload yet just
[20:49] <racarr_> the system cursor theme
[20:49] <racarr_> so the hotspot is contained
[20:49] <racarr_> in the cursor theme
[20:49] <bschaefer> hopefully its just the case of "need to expose it to the client api"
[20:49] <bschaefer> oo
[20:49] <bschaefer> i see
[20:50] <bschaefer> racarr_, o, so atm its just the system themes makes much more sense :)
[20:50]  * bschaefer was thinking to far ahead :)
[20:50]  * bschaefer actually looked at the MP
[20:51] <racarr_> I guess the two remaining features are animted cursors (not actually particularly difficult) and client cursor upload
[20:52] <bschaefer> yup, and i think SDL2 only really uses client cursor upload. I didn't even think about animated cursors
[20:52] <bschaefer> racarr_, at lease, thats from the point of view of my needs haha
[20:53] <bschaefer> racarr_, (besides warp cursor, but thats a different story)
[21:03] <racarr_> mm
[21:04] <racarr_> ok ill add client side cursor uploads soon its really quite straight forward.
[21:04] <bschaefer> racarr_, no rush :), and thanks! (Cursors!!)
[21:51] <Saviq> AlbertA, kgunn, manta seems to be indeed more vulnerable, I just flashed it and left for an hour maybe → locked up
[21:52] <kgunn> Saviq: ack...btw, is it only on lock screen? or also on edge-tutorial ?
[21:53] <Saviq> kgunn, I only saw it on lock screen, rsalveti reported after phone hang-up though
[21:54] <kgunn> Saviq: does anyone know which image it actually showed up in ?
[21:54] <kgunn> e.g. which packages changed?
[21:55] <Saviq> kgunn, 114 seems to be the first people remember this
[21:55] <Saviq> kgunn, http://people.canonical.com/~ogra/touch-image-stats/114.changes
[21:55] <Saviq> doesn't really mean it wasn't there before
[21:56]  * Saviq flashes 110 on manta
[21:56] <kgunn> lol... Saviq suspects mir040
[21:56] <Saviq> kgunn, maybe I can rule it out...
[21:57] <kgunn> yep
[21:58] <Saviq> actually 109 probably makes more sense
[22:01] <AlbertA> huh...I got a manta here that I had not woken up, #112
[22:01] <AlbertA> it seems unity8 is locked up...
[22:02] <AlbertA> so to replicate just let the device sleep for a while?
[22:05] <kgunn> Saviq: just curious...for stuff like qtdeclarative...do the core devs still do the build of the src against latest image ?
[22:05] <kgunn> e.g. no chance of someone sneaking in a bin against an "unknown" environ ?
[22:08] <Saviq> kgunn, there's nothing built outside of PPAs/distro
[22:08] <Saviq> kgunn, even if someone uploads directly, without train, stuff gets rebuilt on buildd
[22:08] <Saviq> AlbertA, yeah, looks like it
[22:09] <Saviq> AlbertA, manta seems especially vulnerable
[22:10] <AlbertA> Saviq: does it happen pretty fast in manta?
[22:11] <kgunn> AlbertA: noteworthy that the u-s-c bug fix for xmir went in on http://people.canonical.com/~ogra/touch-image-stats/113.changes
[22:14] <AlbertA> well I'm suspecting a deadlock in the timeout frame dropping policy...
[22:16] <AlbertA> because all these 3 stack traces look similar
[22:16] <AlbertA> where a compositor release, triggers an update in the policy at the same time a timeout happened
[22:17] <Saviq> AlbertA, I couldn't really say, but between when I flashed and had it locked it must've been under an hour
[22:19] <AlbertA> oh yeah, deadlock...
[22:23] <AlbertA> essentially, the compositor thread owns the buffer_queue mutex as it's releasing...
[22:23] <AlbertA> but it's trying to update the timeout framedropping policy, so it waits to own the internal alarm mutex
[22:24] <AlbertA> meanwhile a timeout has occurred, so the timedropping policy inthis thread owns the internal alarm mutex
[22:24] <AlbertA> but its waiting on the buffer queue mutex...so deadlock...
[22:35] <Saviq> AlbertA, awesome
[22:44] <AlbertA> kgunn: should I target a fix against devel or mir/0.4?
[22:45] <kgunn> AlbertA: you can dual target i suppose
[22:45] <kgunn> that might be simplest
[22:45] <AlbertA> ok
[22:46] <kgunn> AlbertA: might wanna propose as mir-team to leave on Cemil's desk overnight
[22:46] <AlbertA> kgunn: ok, still thinking of how to fix...:)
[22:46] <kgunn> ack