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