| duflu | RAOF: You didn't seem excited when I pointed out your branch improved performance... ? | 03:40 |
|---|---|---|
| RAOF | duflu: It's neat, but it's not really the point :) | 03:41 |
| duflu | Nice freebie | 03:42 |
| duflu | And quite unexpected that we can reduce round trip time at all, especially without trying | 03:42 |
| RAOF | Well, it can help when you don't have to do quite so much queuing on the main loop. | 03:44 |
| * 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:45 |
| RAOF | Not newfangled :) | 03:49 |
| RAOF | Before the rework all IO was being deferred to the IO mainloop, afterwards you just write(). | 03:50 |
| duflu | RAOF: Care to reconsider? https://code.launchpad.net/~vanvugt/mir/fix-1338902/+merge/225929 | 05:50 |
| 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:51 |
| duflu | RAOF: Yes the latter | 05:52 |
| RAOF | Ah. Then drop the std::atomic and I'll reconsider :) | 05:52 |
| 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:53 |
| 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:54 |
| RAOF | Or lucky, depending on your perspective :) | 05:55 |
| duflu | I hate compare/exchange ops. They always mess with my head and require surprisingly careful thought every time I see one | 05:56 |
| duflu | But they're often necessary | 05:57 |
| duflu | RAOF: Done | 06:08 |
| RAOF | Is it really pending Nick's approval?L | 06:09 |
| 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:10 |
| duflu | Whee... and then I won't have every branch failing the same test | 06:11 |
| duflu | sil2100: Hello? | 07:13 |
| duflu | anpok: How goes life with Mesa/GBM? | 07:28 |
| 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:32 |
| sil2100 | duflu: let me take a look, hmm | 07:35 |
| anpok | duflu: moving to the kernel now | 07:44 |
| duflu | anpok: Umm, good (?) | 07:45 |
| duflu | sil2100: Thanks | 07:45 |
| 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:46 |
| 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:47 |
| anpok | the qxl-spice protocol does not seem to provide something like swap command or plane configuration command | 07:48 |
| 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:49 |
| 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:50 |
| duflu | anpok: Oh, yes. | 07:51 |
| 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 | 07:52 |
| sil2100 | duflu: yw! | 08:00 |
| === yofel_ is now known as yofel | ||
| 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:07 |
| 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:08 |
| 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:11 |
| duflu | greyback: I sense more grey hair coming on | 09:23 |
| 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:07 |
| ubot5 | bug 1339610 in Mir "unity8 crashed with SIGSEGV in mir::frontend::ClientBufferTracker::client_has()" [Undecided,Incomplete] https://launchpad.net/bugs/1339610 | 10:07 |
| 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 | 10:09 |
| === 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 | ||
| 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:41 |
| ubot5 | Ubuntu bug 1323031 in Mir "google::ShutDownCommandLineFlags not available on Fedora" [Medium,Triaged] | 16:41 |
| desrt | we already had a patch for it in jhbuild, so i'll just roll it over.... this is really just a 'reminder' :) | 16:42 |
| === alan_g is now known as alan_g|EOD | ||
| 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:31 |
| 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 | 17:32 |
| === renato_ is now known as Guest36942 | ||
| === DalekSec_ is now known as DalekSec | ||
| racarr_ | I hope everyone is enjoying the cursor color change | 19:42 |
| racarr_ | :p | 19:42 |
| racarr_ | what is round trip time to a modern GPU | 19:50 |
| 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:51 |
| kdub_ | like, command submission to some sort of end point? | 19:52 |
| racarr_ | yeah or something like that. | 19:54 |
| racarr_ | It doesn't really matter lol, im just curious all of a sudden. | 19:54 |
| kdub_ | like, writing to a register is fast of course, the time comes from processing/pushing pixels | 19:55 |
| racarr_ | Mm but I mean writing to a register | 19:56 |
| racarr_ | is slower than writing to a register on the CPU | 19:57 |
| racarr_ | so by how much? | 19:57 |
| 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 | 19:59 |
| 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:13 |
| kdub_ | yeah... well you have a +1 from me :D | 20:14 |
| 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:15 |
| bschaefer | racarr_, the mouse looks to real now :) | 20:22 |
| bschaefer | cursor* | 20:22 |
| racarr_ | lol | 20:24 |
| racarr_ | bschaefer: p.s. you can implement cursor support in SDL if you want | 20:24 |
| bschaefer | racarr_, yay! | 20:24 |
| 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:25 |
| bschaefer | racarr_, nice! also was hotspot implemented? | 20:26 |
| * bschaefer remembers you mentioning it wasn't before | 20:26 | |
| racarr_ | bschaefer: indeed | 20:47 |
| racarr_ | it is implemented that is | 20:48 |
| bschaefer | implemented is always nice, didn't see it mentioned in the client api | 20:48 |
| 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:49 |
| 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:50 | |
| racarr_ | I guess the two remaining features are animted cursors (not actually particularly difficult) and client cursor upload | 20:51 |
| 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:52 |
| bschaefer | racarr_, (besides warp cursor, but thats a different story) | 20:53 |
| racarr_ | mm | 21:03 |
| racarr_ | ok ill add client side cursor uploads soon its really quite straight forward. | 21:04 |
| bschaefer | racarr_, no rush :), and thanks! (Cursors!!) | 21:04 |
| Saviq | AlbertA, kgunn, manta seems to be indeed more vulnerable, I just flashed it and left for an hour maybe → locked up | 21:51 |
| kgunn | Saviq: ack...btw, is it only on lock screen? or also on edge-tutorial ? | 21:52 |
| Saviq | kgunn, I only saw it on lock screen, rsalveti reported after phone hang-up though | 21:53 |
| kgunn | Saviq: does anyone know which image it actually showed up in ? | 21:54 |
| kgunn | e.g. which packages changed? | 21:54 |
| 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:55 |
| * Saviq flashes 110 on manta | 21:56 | |
| kgunn | lol... Saviq suspects mir040 | 21:56 |
| Saviq | kgunn, maybe I can rule it out... | 21:56 |
| kgunn | yep | 21:57 |
| Saviq | actually 109 probably makes more sense | 21:58 |
| AlbertA | huh...I got a manta here that I had not woken up, #112 | 22:01 |
| AlbertA | it seems unity8 is locked up... | 22:01 |
| AlbertA | so to replicate just let the device sleep for a while? | 22:02 |
| 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:05 |
| 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:08 |
| Saviq | AlbertA, manta seems especially vulnerable | 22:09 |
| AlbertA | Saviq: does it happen pretty fast in manta? | 22:10 |
| 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:11 |
| AlbertA | well I'm suspecting a deadlock in the timeout frame dropping policy... | 22:14 |
| 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:16 |
| Saviq | AlbertA, I couldn't really say, but between when I flashed and had it locked it must've been under an hour | 22:17 |
| AlbertA | oh yeah, deadlock... | 22:19 |
| 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:23 |
| 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:24 |
| Saviq | AlbertA, awesome | 22:35 |
| AlbertA | kgunn: should I target a fix against devel or mir/0.4? | 22:44 |
| kgunn | AlbertA: you can dual target i suppose | 22:45 |
| kgunn | that might be simplest | 22:45 |
| AlbertA | ok | 22:45 |
| 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 | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!