[00:01] racarr, yeah i mean, there are some good things, but our renderer just does the simple stuff at the moment [00:01] wobbly windows would benefit [00:01] haha right [00:02] it has the [00:02] map buffer object stuff which is kind of cool [00:02] from opengl 4 [00:04] yeah, its a cool improvement [00:05] sometimes i forget that opengl can do animations, and its not just an api for passing buffers into [00:05] I read some paper once about some technique with using like two mapped vbo arrays and fences [00:05] in order to do animations in this zero copy fashion (I mean, it still ahs to make it to the GPU depending on your architecture) [00:06] but it was basically double buffering the vertex data, so neither the animator, or the GPU ever has to block [00:06] and then I think using some nvidia fence extension [00:06] I don't remember the details :p [00:06] racarr: opengles3 has uniform buffer objects and transform feedback [00:06] mm [00:06] which is just great [00:07] I don't think transform feedback is super interesting to mir though really [00:07] racarr: actually the even cooler one [00:07] racarr: its interesting if you want to like [00:07] do wobbly windows [00:07] in hardware [00:07] ubu could be useful for some kind of optimizations [00:07] well [00:07] right [00:07] lol [00:07] racarr: whats more interesting is opengl 4.4 [00:07] with stuff like [00:07] bindless textures [00:07] and [00:08] haha [00:08] thats what I was going to say [00:08] (bindless textures) [00:08] thats some cool stuff [00:08] bind groups [00:08] Grr. [00:08] or whatever it was called [00:08] RAOF: y u mad [00:08] racarr: What's the least I can do to get stderr from mir_demo_server_shell to display? [00:11] RAOF: 2>&1 > foo.txt [00:11] racarr: any progress on the mir_stress bug thingy? [00:12] racarr: No, I mean "what's the least I can do to make mir_demo_server_shell not eat stderr?" Because I'm running it from ssh, so I can totally see anything that actually makes it to the tty. [00:13] thomi: No, I haven't found the second bug yet [00:14] I forgot it and let it escape my todo though so thanks :) [00:14] RAOF: err [00:14] I didnt know it ate stderr [00:14] I redirect stderr to a file all the time [00:14] at least I think Id o [00:14] RAOF: gdb breakpoint on close () and see where it calls close(2) ? :p [00:15] I really dont think its [00:15] supposed to do that [00:16] Hm. Ok. [00:17] RAOF: OH HEY! While I remember I keep on meaning to ask you about something that I am meaning to take on friday/next week [00:17] DPMS support [00:17] racarr: Oh, cool. [00:17] my understanding, is: expose turning CRTC on /off from mir::graphics, expose over IPC, expose component that lets shell approve/dissaprove these requests [00:18] add component in U-S-C to be friends with X [00:18] then implement a bunch of hooks on [00:18] XMirDisplay [00:18] or whatever [00:18] it's called [00:18] by a bunch of hooks I mean like 2 [00:18] Do we want to expose it over IPC? [00:18] does that make sense? What is up with backlight, I looked aroudn xf86-video-intel a little bit and the backlight code seemed a little strange at first glance using [00:18] /sys files or something [00:18] RAOF: Hmm, well how else will X request it of USC [00:19] you mean USC should provide a [00:19] non mir interface perhaps [00:19] ? [00:19] By USC implementing its own interface. [00:19] This, incidentally, is a reason why having the protocol being extensible would be really useful. :) [00:19] the_frontend_communicator() override [00:19] ;) [00:20] ok I understand [00:20] hmm [00:20] Oh, and backlight is indeed a twisty maze of vendor hate. [00:20] I'm not sure in regards to over IPC / USC has it's own protocol [00:21] I...remember I leaned towards the mir protocol when Iw as thinking last week [00:21] but I think thats just because it wasnt clear to me what the protocol should be otherwise (DBus to X) [00:21] it's also. not entirely absurd that maybe this is reasonable client API. [00:22] It should be over the mir socket, but it shouldn't be in the Mir protocol that we expose to clients. [00:22] Hm. Under what circumstances is it reasonable for a client to ask the display server to turn off the displays? [00:22] Maybe it makes sense for certain kinds of presentation or media apps [00:23] You mean to ask the display server to *not* turn off the display, right? [00:23] or a coniguration app [00:25] RAOF: Well maybe not! I dunno i.e. a video player which has a distraction free setting can automatically turn off your displays when you are streaming to your TV [00:25] Eh, maybe? [00:25] or like, when you present, you want your laptop display off, on, or in presentation mode, so presentation apps on other platforms often include what basically amounts to a monitor configuration panel [00:25] yeah I dunno, maybe :p [00:26] I think both of these are kind of borderline absurd, but I was just trying to generate [00:26] ideas [00:27] thomi: thanks for the response - so, if i want to quick glance at all the unity tests reported on for mir.....what do i look at ? [00:27] prep'ing for iom sprint [00:27] kgunn: without runing he tests yourself you mean? like, on a dashboard somewhere? [00:27] RAOF: I thought about you last night because one of my friends is studying to be an actuary so he started talking to me about a series of probability problems he was doing [00:28] Oh? [00:28] so then, he started explaining how to solve them with multidimensional integrals, etc, and my thought was that like, from a constructive perspective [00:28] integrals seem to be the wrong abstraction to build [00:28] probability on top of [00:28] because why do you even need [00:28] infinite sets? [00:29] a few minutes in to arguing this point I feel as if I had a flash of empathy with your previous advisor XD [00:29] kgunn: that's the correct job, but for some reason older builds reported waaaay too many tests. Newer builds look good though, for e.g.: http://10.97.2.10:8080/job/mir-saucy-amd64-ci/336/testReport/ [00:31] RAOF: Anyway that's how I invented my new theory of probability and started to wonder if the whole aesthetic of mathematical philosophy was misgrounded. [00:31] but...lol...back to DPMS, um, so...not the mir protocol? [00:31] :) [00:31] not the mir protocol but over the mir socket sounds difficult [00:31] kgunn: not sure if that answers your question or not [00:31] Yeah, needing uncomputable numbers sounds like a silly thing for probability :) [00:32] racarr: It can probably be in the protocol. [00:32] racarr: I'd quite like it to be less difficult for protocol extensions to exist, though. [00:32] I'll think about that [00:32] I am trying to think about something inbetween [00:32] non extensible protocol [00:32] and everything is a ClientMessage [00:33] and yeah thats exactly what I mean! You don't need all that for probability, so maybe by dealing with it in the continuum and then using limits to reduce it back to a finite state system you are actually [00:33] developing a less...'reusable' theory of probability [00:33] haha [00:33] I think we could actually manage it by making the frontend replacable. [00:34] http://en.wikipedia.org/wiki/Circle-ellipse_problem [00:34] I wonder if mathematicians had understood ideas from software engineering if math would have been architected differently ;) [00:34] Hmm well [00:34] the frontend is replaceable right? [00:34] It's ust all or nothing [00:34] Hm, *or* passing in a ProtocolExtension to the frontend, so when it discovers a message it doesn't know about it delegates. [00:35] its probably possible to use [00:35] template trickery, so that adding a new message is as easy as putting it in the wire protocol [00:35] and providing an impl on SessionMediator [00:35] or something [00:35] um [00:36] Yeah, something like that would be good. [00:36] thomi: excellent!....that does answer it [00:36] It worries me a little at first response [00:37] It's insane that the first thing that anyone does when trying to solve discrete problems is go "hm, is this sufficiently well approximated by an uncountably infinite set full of uncomputable numbers?" [00:37] does it complicate our wire versioning situation, etc... [00:37] weird about those repeated reportings [00:37] yeah [00:37] RAOF: Haha, right, and that's what I mean by the misguided aesthetic [00:37] because before incompleteness results, people thought mathematics was just one single [00:37] totally complete and consistent system [00:37] so why not do that [00:37] so that was seen as like [00:37] elegant [00:38] Protocol versioning: hm, maybe? [00:38] The problem would come in when calls migrate from extension to core or visa-versa, right? [00:39] We'd also need extensions to be versioned. [00:39] whatever you do [00:39] don't autogenerate [00:39] bindings from the protocol [00:40] hah :) [00:40] at least, don't make them inline [00:40] the crap I had to do in order to dlopen wayland-client and use it [00:40] was not fun [00:41] RAOF: Well, or just when, one mir supports protocol version 7 with unity extension version 8 that was backported to ubuntu 15.04 but the version in 15.10 supports protocol version 7 with unity version 9 + unity fixes version 2 and the 16.04 daily... [00:41] haha :p [00:41] we want to avoid that I think [00:42] the way wayland does it is ok [00:42] basically, if the client doesnt support some protocol [00:42] then the server doesnt send it events that match that protocl [00:42] and ignores requests from that protocol [00:42] (version) [00:43] Mm [00:43] the thing is, these methods aren't in the client library I guess or they would be int he real protocol [00:43] our client library doesn't present an abstraction of like [00:43] message [00:43] in the same way wayland does [00:43] maybe it should *shrug* [00:46] You just need similar extension support in the client library. [00:46] "just" ☺ [00:49] right but I think to model that extension support [00:49] the client library first has to like [00:49] talk in terms of messages/protocol or something [00:49] which it entirely hides now [00:52] Right. It could, however, export some of that, without exposing it to the C layer. [00:52] mir_extension_register(mir_my_extension) [00:53] mir_extension_foo_get() returns an opaque pointer to the C++ implementation bits needed to do the dispatch? [00:57] are all the combinations [00:57] of extensions sorted in to [00:57] 1 set of extensions used by USC [00:57] cients [00:57] 2. 1 set of extensions used by unity clients [00:58] in this case maybe its just libmirclient-system libmirclient-client, or its just libmiclient that has all of 1 but there are permissions and [00:58] platform-api exposes the rest [00:58] or.... [00:58] why do I use "or...." in place of "." [01:07] Off to berkeley! [01:07] You can follow live (with 168 hour delay) at http://archive.org/details/StuAllenAndMarsHotel2013-07-17.flac16 [01:07] :p [01:12] With 168 hour delay? [01:12] That's some serious "live" :) [01:12] Have fun in Berkeley! [01:19] have fun racarr :) [02:10] Yes! [02:10] * RAOF wins. [02:10] Nothing wrong with xmir, Mir really is displaying frame N-1. [02:13] RAOF: \o/ [02:14] /o\ [02:14] RAOF: If the surface has swapinterval=0 then Mir will use triple buffering on it [02:15] It's not; this is simple double buffering. [02:15] Oh [02:15] RAOF: So the client says here's one new frame and the compositor still could delay indefinitely? [02:16] The client says "here's one new frame" and the compositor says "thanks, I'll composite frame N-1 for you" [02:16] RAOF: Heh. Actually that's something I just rewrote and we're arguing in email. More work to come [02:17] ... [02:17] Client sub buffer{3} [02:17] Client acquired buffer{4} [02:17] Compositor acquired buffer{3} [02:17] Compositing buffer{3} [02:17] Client sub buffer{4} [02:17] Compositor released buffer{3} [02:17] ... [02:17] * duflu admires typing speed ;) [02:17] ... [02:17] Client acquired buffer{3} [02:17] Client sub buffer{3} [02:17] Compositor acquired buffer{4} [02:17] Compositing buffer{4} [02:17] Compositor released buffer{4} [02:17] Client acquired buffer{4} [02:17] Client sub buffer{4} [02:17] Compositor acquired buffer{3} [02:17] Compositing buffer{3} [02:17] Compositor released buffer{3} [02:17] ... [02:18] At some point in this log we start compositing the N-1'th buffer submitted by the client, rather than the last one. [02:18] RAOF: Yes, it's cos the compositor chooses the front of the queue (oldest frame) even when there might be newer ones ready behind it [02:18] That's related to my current work [02:19] This is actually a bit worse than that; the compositor is compositing using the buffer that the client currently owns. [02:19] Oh, no it's not. Carry on. [02:19] RAOF: Also related. I now make that impossible [02:19] Sweet. [02:20] Although there's a risk that you block the compositor, which needs to be eliminated [02:20] Yes [02:21] RAOF: That's why I was confused. The lag should be impossible if nbuffers=2, unless the compositor is showing a buffer currently held by the client [02:22] Hmm, maybe there's a third possibility [02:23] RAOF: I will reconsider the issues you describe today and maybe give you a branch to try... ? [02:24] That would be excellent. [02:38] RAOF, we need a way to counter u-s-c being installed, but X not supporting Mir. LightDM can't easily tell this without trying to run X with -mir and reading the stderr error messages, so perhaps we can do it better. Can we make the patched X package provide something like xorg-server-xmir and then have u-s-c depend on that? [02:38] robert_ancell: Yes. [02:39] robert_ancell: We could even go so far as to split libxmir.so into xserver-xorg-xmir, so the core server doesn't gain Mir dependencies. [02:39] RAOF, that would be even better! [02:40] RAOF, but the core package still needs the patch to have -mir etc right? Do we assume if you have xserver-xorg-xmir then the core package matches that? [02:40] This is a Universe blocker (apparently) so we need to get it fixed asap [02:40] Ah, ok. [02:40] Good. That's what I'll do after lunch, then! [02:41] cool [02:54] robert_ancell: Skype? Hangout? [02:54] duflu, hangout is best [02:55] Not for my earphone comfort :) [03:48] Woo, a day of fixing conflicts :/ [03:48] RAOF, does the N-1 you mention in bug 1199450 accumulate over time? i.e. so you end up with N-M [03:48] bug 1199450 in XMir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Triaged] https://launchpad.net/bugs/1199450 [03:49] robert_ancell: No, because there are only 2 buffers. [03:49] ok, that's better :) [03:49] Possibly if we were triple-buffering then you could get 2 buffers behind? [03:49] Not really. [03:49] That's weird. bzr is giving lots of conflicts that really are not [03:49] Although I guess that *most* people have something change on the screen reasonably frequently. [03:50] RAOF: Keep glxgears running in the corner :) [03:50] But if you have just an xterm on the screen you'll forever be one-character behind. [03:52] Alternatively, keep a browser open with lots of ads. That's always a big contributor [04:46] RAOF, any update on the X packaging? [04:46] robert_ancell: Is now in mir-team/staging. [04:47] RAOF, cool, what depends should I add to u-s-c, or have you already done that ;) [04:47] Not yet. [04:48] ok, I'll leave it with you then [04:48] K. [04:49] Ah. New xserver upload in saucy-proposed :/ [05:07] robert_ancell: https://code.launchpad.net/~raof/unity-system-compositor/debconfify/+merge/176858 enjoy. [05:08] RAOF, odd branch name :) [05:08] It accidentaly got pushed to the last branch I proposed ;) [05:09] RAOF, I just realised strictly we don't need XMir to use the system compositor, but for current practical use case the dependency solves a bigger problem than this might cause [05:09] Indeed, that was my thought too. [05:10] Since there's currently nothing *but* XMir that can run in unity-system-compositor… ☺ [05:10] yep [05:11] we'll blow that bridge up when we come to it [05:11] Eh, when we get there we'll just drop the dep. [05:13] good morning :) [05:14] Hey ho. [05:16] RAOF, hey there, how goes? [05:20] RAOF, hey, did you see that the intel driver failed compiling in the staging ppa? [05:20] Hm, no I didn't. [05:20] I need to fix unrelated things in it anyway :) [05:20] RAOF, ack [05:28] tvoss: So, duflu was going to ping me with a branch that probably doesn't exhibit this behaviour. [05:30] RAOF, okay, could you point me to the places in the code where you put the terminal outputs? [05:31] tvoss: http://paste.ubuntu.com/5910065/ enjoy. [05:32] RAOF: robert_ancell: excellent! this will be in today's build (I just rerun u-s-c) [05:33] RAOF: robert_ancell: on a longer term, we can have a virtual package as well [05:33] didrocks: On a longer term we'll want to just drop it; the system compositor doesn't really depend on anything being run inside it, any more than the Xserver depends on Unity. [05:34] RAOF: hum, but something run X -mir, right? [05:34] lightdm does, yes. [05:34] but u-s-c add the -mir parameter? :) [05:34] Actually, that's probably where the dependency should be, now that you mention it :) [05:34] or it's lightdm? [05:34] It's lightdm. [05:34] ah… [05:35] yeah, would be logical, not sure robert will be thrilled about it though :p [05:35] anyway, we can figure about it later, the urgent part is covered [05:56] greyback, ping [06:02] RAOF, didrocks, but the problem is lightdm doesn't depend on u-s-c, because it runs fine without it [06:03] it only depends on it when it's configured to use it, and that configuration is in the u-s-c package [06:03] if we move that out to somewhere else, e.g. ubuntu-desktop then that would be the right place for the dependency [06:48] alf__, ping [06:48] tvoss: pong [06:58] good morning [06:59] RAOF: Try this out. Let me know if the lag is now fixed; lp:~vanvugt/mir/switch [07:02] Morning dholbach [07:03] duflu: Ta. [07:04] hey duflu [07:04] how are you all doing? [07:04] * dholbach hugs duflu, RAOF and the rest of the gang [07:04] Hey duflu! [07:05] Or even - hey dholbach! [07:07] :) [07:11] dholbach, berlin calling @fb? [07:24] tvoss, yep :) [07:37] tvoss: pong === dholbach_ is now known as dholbach [08:01] didrocks, ping [08:01] tvoss: pong [08:02] on 3G [08:02] didrocks, ack [08:12] hikiko, can you do an earlier 1-1? [08:13] sure robert_ancell [08:13] do you want me to join now? [08:27] duflu: Looks like that doesn't have the delay problem. [08:28] duflu: It looks like it's triple buffering, though? [08:28] tvoss: ^^^ [08:28] RAOF: Good start, but can you be sure? And yes, I default to triple because bypass will need it [08:29] Also, frame-dropping is suboptimal without triple [08:30] duflu: Well, no I can't be sure. [08:30] Alright, but still, good [08:30] But the workload which reliably caused the problem no longer causes the problem. [08:44] RAOF, could you quickly run phoronix-test-suite run pts/gaming-free with duflu's branch? [08:45] tvoss: It's just buffering changes. Bypass is not in that branch. You know that? [08:45] tvoss: I've been using the openarena timedemo to test; I can do phoronix-test-suite too, if you like. [08:45] RAOF, would be cool, that was my test-case [08:47] RAOF, also: pbuilder create complains about W: Failure trying to run: chroot /var/cache/pbuilder/build/28791/. mount -t proc proc /proc [08:47] W: See /var/cache/pbuilder/build/28791/./debootstrap/debootstrap.log for details [08:47] E: debootstrap failed [08:47] W: Aborting with an error [08:47] I have had that issue a million times, but never remember how to solve it [08:48] * RAOF uses sbuild [08:48] Sorry! [08:59] duflu, yup, know that. Just want to make sure that we put heavy load onto the system [08:59] OK. It's a little unusual for other people to load test a branch that's not even ready to propose :) [09:06] RAOF: Can you test the input delay with the current trunk with triple buffer enabled (change 2->3 src/server/compositor/swapper_factory.cpp line 47). It would be good to know if this is solved by triple buffering, or some other change in duflu's branch. [09:06] alf__: Sure. [09:06] alf__: I expect triple will make it worse. I did an explicit fix for the lag bug today [09:10] duflu, on the current design? [09:11] tvoss: Either. The higher the number of buffers, the worse the lag will be. The fix was not the number of buffers, but was to drop frames when more than one was queued for composition [09:11] duflu, ack, mind pinging me the branch? [09:12] tvoss: r937 onward: https://code.launchpad.net/~vanvugt/mir/switch [09:12] duflu, can we backport that to trunk right now? [09:13] tvoss: Possibly. Alf should have the know-how [09:13] alf__, ^? [09:14] It's easy to drop excess frames. But you just have to remember to change how you throttle synchronous clients at the same time [09:18] duflu: tvoss: RAOF: ...but this changes our compositor to drop frames always. Is XMir sending frames that it then wants to cancel/override with new ones instead of having a steady sequential stream? [09:19] alf__, duflu sounds like that should be controllable with a policy [09:19] xmir doesn't expect frame dropping. [09:21] If we're *getting* frame dropping then Mir's behaving unexpectedly. [09:28] Man, pts/gaming-free takes *some time* to download. [09:30] RAOF: We are not dropping frames normally. However the proposed solution involves dropping all frames but the latest, if understood it correctly. So if the compositor's queue contains CBA with C being the latest, with the proposed change mir drops B,A and gets directly to C. I don't know what's causing the problem really, but this feels like dealing with the symptom. [09:32] alf__, the trigger is this bug: https://bugs.launchpad.net/mir/+bug/1199450 [09:32] Launchpad bug 1199450 in XMir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Triaged] [09:33] alf__: I'm not sure how the compositor's queue ever gets more than one buffer in it? [09:33] alf__: Because we're double buffering by default, and the client always has a buffer... [09:34] And a buffer that the client has can't be in the compositor's queue. [09:34] So, by my understanding, there can be at most one buffer in the compositor queue. [09:37] RAOF: Yeah like I said yesterday - the bug should be impossible with nbuffers=2 in theory [09:37] But in practise it's quite easy to trigger :) [09:37] Oh universe, how you deceive us all [09:38] RAOF: Impossible if nbuffers=2 and they're being alternated fairly/evenly ;) [09:39] I wonder if I will get to cook real food or spend another evening hacking :/ [09:40] * duflu finds middle ground and makes evening coffee [09:40] * RAOF finishes dinner and goes to clean up. [09:40] Night all! [09:41] RAOF, night all :) talk to you tomorrow [09:41] RAOF: duflu: I think there can be two buffers if the client is slow. Good night :) [09:42] alf__, can we easily switch to triple buffering on current trunk? [09:42] Last I checked, it was a trivial 1 character change [09:42] Night RAOF [09:42] tvoss: yes, but we need to prove that this will help [09:43] alf__, happy to do so ... just show me where [09:43] I think it would/should make it worse [09:43] duflu, alf__ I'm happy to be the guinea pig here [09:43] tvoss: alf__ did... scroll back [09:43] tvoss: change 2->3 src/server/compositor/swapper_factory.cpp line 47 [09:43] alf__, thanks [09:44] duflu, alf__ the good thing is: it is not subtle, but totally visible ;) [09:46] * tvoss is in love with sbuild [10:27] alf__, ping! [10:57] hikiko: pong [10:58] tvoss: kgunn: FYI, I'm recopying the latest changes from RAOF to the daily-build-next ppa, we really need to be in distro ASAP… [10:58] hi alf__ I was wondering about the internal clients [10:59] and the internal display [10:59] tvoss: kgunn: argh, his build failed on i386 [10:59] didrocks, ack, you referring to the xorg driver? [11:00] (one test) [11:00] tvoss: yeah, he changed the dep for mir [11:00] I guess these should be initialized and live in the native platform, correct? [11:00] but didn't copy in daily-build-next [11:00] so we can't install mir anymore now in it [11:00] tvoss: but anyway, one test failed from his xorg upload [11:00] didrocks, hold on, cannot follow [11:01] didrocks, did you just restart the build? [11:01] tvoss: yeah [11:01] didrocks, why is that? do you suspect a flaky builder? [11:01]