| racarr | *pant* | 01:06 |
|---|---|---|
| racarr | 2/3rds done! | 01:06 |
| racarr | unfortunately diff is already almost 5000 lines, wondering if I should try and propoe part of the branch even if it doesn't make sense on its own | 01:07 |
| racarr | Happy weekly meeting! | 05:57 |
| racarr | *streamers and loud horns* | 05:57 |
| thomi | anyone joining me in the weekly meeting? | 06:02 |
| thomi | racarr: ? | 06:03 |
| hikiko | thomi, in a sec | 06:03 |
| racarr | thomi: Link? | 06:04 |
| thomi | https://plus.google.com/hangouts/_/a9abbc8e84f85360faaab30196768ca2d9129d09?authuser=1 | 06:04 |
| thomi | kdub: ? | 06:07 |
| thomi | RAOF: ? | 06:07 |
| alf__ | thomi: https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211 | 06:24 |
| alf__ | thomi: https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/718/console | 06:24 |
| alan_g | alf__: @refactor-compositing-strategy - do you agree with me that the resource holding problem also applies to the "overlay rendering" we were discussing yesterday? | 09:09 |
| alf__ | alan_g: yes | 09:14 |
| alan_g | alf__: I'll roll that fix in too. ;) | 09:15 |
| alf__ | alan_g: although it's not probable (but it's possible) that the overlay render will actually need to do something that requires resource holding | 09:16 |
| alf__ | alan_g: Did you get a chance to talk to racarr about the utility of the OverlayRenderer? | 09:17 |
| alf__ | (vs just rolling a new CompositingStrategy) | 09:17 |
| alan_g | alf__: I didn't - there are more urgent questions. | 09:18 |
| alf__ | alan_g: I am asking because perhaps racarr will agree to that, so we can get rid of OverlayRenderer... | 09:18 |
| alf__ | alan_g: and save you the trouble of changing OverlayRenderer | 09:20 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| hikiko | the mir/examples are only for the gbm platform? | 10:45 |
| alf__ | hikiko: no | 10:58 |
| hikiko | alf__, I want to get 100% sure that there isn't something in my CMakeLists.txt that causes the render_to_fb example to compile with gbm | 11:00 |
| hikiko | it seems to compile with sdl | 11:00 |
| alan_g | alf__: when you have time could you look over https://code.launchpad.net/~alan-griffiths/mir/refactor-compositing-strategy/+merge/164945 | 11:01 |
| alf__ | alan_g: sure | 11:02 |
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === greyback is now known as greyback|lunch | ||
| === pete-woods-lunch is now known as pete-woods | ||
| === greyback|lunch is now known as greyback | ||
| === dpm is now known as dpm-laptop | ||
| === alan_g|lunch is now known as alan_g | ||
| === hikiko is now known as hikiko_lunch | ||
| greyback | kdub: hey, an progress with improving performance on Galaxy Nexus? | 13:23 |
| hikiko_lunch | alf__, render_to_fb is a standalone prog or i have to run something else before i start it? | 13:41 |
| === hikiko_lunch is now known as hikiko | ||
| hikiko | There are some brief guides describing how to run the Mir binaries once you have | 13:44 |
| hikiko | them built. <- where? | 13:44 |
| alan_g | hikiko: render_* are standalone programs | 13:47 |
| * alan_g thinks this is https://bugs.launchpad.net/mir/+bug/1108715 again | 13:48 | |
| ubot5 | Launchpad bug 1108715 in Mir "Inadequate documentation of binaries" [Medium,Triaged] | 13:48 |
| hikiko | cool, but where are instructions on how to run mir? I found build instructions in several places (eg doc, readme) but I can't find how to run clients etc | 13:49 |
| hikiko | yes :D alan_g that's exactly my question | 13:50 |
| alan_g | hikiko: The documentation that does exist is under http://unity.ubuntu.com/mir/ - e.g. "Using Mir on a PC" | 13:51 |
| hikiko | pfff blind :( so I just start the server and then I run the client :) thank you alan_g ! | 13:53 |
| alan_g | hikiko: np - BTW you're welcome to propose improvements to the documentation. (It needs improvement!) | 13:54 |
| hikiko | but for the render_* I don't need to run the server isn't it? | 13:55 |
| alan_g | hikiko: no, they use the mir library directly | 13:55 |
| hikiko | ok :) | 13:55 |
| hikiko | thank you! | 13:55 |
| * alan_g is always glad to help. | 13:57 | |
| hikiko | :D | 13:57 |
| === alan_g is now known as alan_g|tea | ||
| === francisco is now known as Guest25788 | ||
| === alan_g|tea is now known as alan_g | ||
| kdub | greyback, no, haven't looked further into that... maybe we should file a bug? | 15:00 |
| greyback | kdub: true, I'll make one | 15:00 |
| === dpm-laptop is now known as dpm | ||
| greyback | kdub: https://bugs.launchpad.net/mir/+bug/1182930 do you need more info? | 15:14 |
| ubot5 | Launchpad bug 1182930 in Mir "Unity8 low framerate running on Mir on Galaxy Nexus" [Undecided,New] | 15:14 |
| alf__ | status: more lttng work, started investigating mir stress test crashes | 15:15 |
| === mmrazik is now known as mmrazik|afk | ||
| kdub | greyback, looks like enough info to start | 15:17 |
| greyback | ok | 15:17 |
| kdub | status, cleanup branch, measured our client's start times in comparison to surfaceflinegr, working on the glmark2 numbers now | 15:20 |
| kgunn | greyback: just curious...is the perf drop on n10 & galaxynexus? or more noticeable on one than the other | 15:24 |
| greyback | kgunn: Mir not functioning on N10, so I cannot say. I only have 1 device | 15:25 |
| greyback | that's running Mir correctly right now | 15:25 |
| kgunn | greyback: ack | 15:25 |
| greyback | kgunn: probable perf is better. racarr has N4, he can probably say what perf is like | 15:26 |
| === Quintasan_ is now known as Quintasan | ||
| racarr | Morning | 16:54 |
| alan_g | Afternoon | 16:55 |
| === alan_g is now known as alan_g|life | ||
| racarr | today will still be working on this input branch I was on all day yesterday | 17:12 |
| racarr | should hopefully be wrapping it up around lunch time | 17:12 |
| kgunn | racarr: just curious....on nexus4, do you see the same drop for inprocess shell vs out of process (same as galaxynexus) | 17:37 |
| racarr | Not with | 17:41 |
| racarr | a cursory glance | 17:41 |
| racarr | thats interesting | 17:42 |
| racarr | I have had a speculation for a while | 17:43 |
| racarr | that perhaps a many threaded process | 17:43 |
| racarr | is more difficult to schedule | 17:43 |
| racarr | than multiple processes | 17:43 |
| racarr | i.e. the assumption has always been that inprocess shell would give us a performance boost | 17:43 |
| racarr | but there is no reason why that has to be true. | 17:43 |
| racarr | no reason obvious to me* | 17:45 |
| kgunn | racarr: mmm, guessing the theory is...its thread switching vs process (context) switching | 17:47 |
| kgunn | racarr: so you didn't see a visible drop on nexus4...hmm | 17:48 |
| kgunn | kdub: ^ | 17:48 |
| kdub | ohhh | 17:49 |
| kdub | yeah that could explain it :/ | 17:49 |
| kdub | well, rather, gpu context switching is more of a concern to me | 17:49 |
| kdub | because i'd guess the newer cores do that better than the older ones | 17:50 |
| kdub | like, i know the nexus4 gpu is 'hyperthreaded' (if i can overload that term :) ) | 17:50 |
| racarr | kgunn: thread swithcing is definitely cheaper | 17:53 |
| racarr | than process switching though... | 17:53 |
| racarr | but, maybe that overhead is small for us | 17:53 |
| racarr | I have two theories (if it is in fact the case) | 17:53 |
| kgunn | racarr: for sure | 17:53 |
| racarr | 1. I don't know how the kernel scheduler works anymore but | 17:54 |
| racarr | from a high level point of view if you are trying to interleave multiple processes | 17:54 |
| racarr | the fewer dependencies they have | 17:54 |
| racarr | i.e. threads have a shared memory dependency on eachother | 17:55 |
| racarr | whereas processes don't | 17:55 |
| racarr | you can be more clever | 17:55 |
| racarr | Or, perhaps the scheduler just fights us by default | 17:56 |
| racarr | because the desktop scheduler tries to ensure processes get low worst case latency | 17:56 |
| racarr | over thouroughput | 17:56 |
| racarr | so maybe there is some sort of timeslice that each process gets (I think this is a vast simplification of how the scheduler work now...I haven't known the details in > 2 years and there have been at least 2 rewrite) | 17:57 |
| racarr | and the shell is exhausting what would have gone to the compositor | 17:57 |
| racarr | if this is the case I bet we can fix it with affinities or priorities or something | 17:57 |
| kdub | racarr, i'm suspicious that what is happening is | 17:58 |
| racarr | 2. The input setup is different in the out of process case | 17:58 |
| kdub | the galaxy nexus gpu has to do a pipeline flush (or something funny like that) on a gpu context switch | 17:58 |
| kgunn | racarr: kind of makes sense, about mem dependencies too | 17:58 |
| racarr | i.e. it's using a seperate process for input reading and delivery too | 17:58 |
| kdub | and so in process thrashes the gpu caches and pipeline | 17:58 |
| kgunn | you can hose yourself w. overhead of locking/unlock | 17:58 |
| racarr | kdub: It's kind of the same story out of proces though right? | 17:59 |
| kdub | well, i guess | 17:59 |
| kdub | well | 17:59 |
| kdub | still thinking, thats a good point | 17:59 |
| racarr | kgunn: It could be an overhead of lock/unlock too | 18:00 |
| racarr | some sort of lock contention issue | 18:00 |
| racarr | another wild guess: Our surface stack has a single mutex | 18:00 |
| racarr | so input events (reading the surface stack/a surface) contend with the compositor (also reading the surface stack/a surface) | 18:02 |
| racarr | whereas in the out of process setup | 18:02 |
| racarr | where we are using surface flinger | 18:02 |
| racarr | there is no contention (granted there is also lot of races :p) | 18:02 |
| racarr | (using surface flinger for input that is) | 18:02 |
| racarr | A R/W lock would fix that. | 18:02 |
| tvoss | racarr, kgunn, kdub how about running it through callgrind? | 18:03 |
| racarr | Good idea, or if we had deeper lltng traces might be interesting. | 18:04 |
| racarr | I think first we should measure and confirm it XD | 18:05 |
| tvoss | racarr, exactly | 18:05 |
| racarr | im reading about | 18:10 |
| tvoss | racarr, I do not think that we should be slower in process. Why would we need to have more context switches in process? | 18:12 |
| racarr | tvoss: Not more context switches | 18:12 |
| racarr | I just mean the scheduling is less ideal | 18:12 |
| tvoss | racarr, can we try with renicing the the shell then? | 18:12 |
| racarr | pthread_setschedparam :) | 18:15 |
| tvoss | racarr, our good old friend :) | 18:16 |
| racarr | I think | 18:16 |
| racarr | something that would be interesting to try in general (even if not specifically in this problem) | 18:16 |
| racarr | would be scheduling the compositor thread with SCHED_FIFO | 18:17 |
| racarr | and all the other threads with SCHED_OTHER (the default, which is apparently round robin timeslices) | 18:17 |
| racarr | the whole theory of this being the source of the performance degredation seems improbable ;) | 18:22 |
| racarr | perhaps the surface flinger we use for input in out of process model | 18:22 |
| racarr | already has a higher priority | 18:22 |
| racarr | or higher priority threads somewhere | 18:22 |
| racarr | or something | 18:22 |
| racarr | that seems like the kind of thing they would do | 18:22 |
| racarr | Ok. Sorry I am rambling, this is just interesting to speculate about XD | 18:22 |
| racarr | tvoss: I am rebuilding the input stack to get rid of setInputWindows :) | 18:23 |
| tvoss | racarr, great :) | 18:23 |
| tvoss | racarr, surfaceflinger has a compositing thread priority of time_critical iirc | 18:24 |
| racarr | In the out of process mir demo though (which I think is what the performance degredation was observed relative to) | 18:24 |
| racarr | there is the surface flinger | 18:24 |
| racarr | input threads still running right | 18:24 |
| tvoss | racarr, yup | 18:24 |
| racarr | I bet they tweak those threads too.. | 18:25 |
| racarr | if you really trust what you are doing even, all your input receiving threads on the client (which have a chance to back up the server input processing) | 18:26 |
| racarr | should be scheduled FIFO as well, because all they should do is read from the socket, respond and block/yield on injecting the event in to the toolkit thread | 18:26 |
| racarr | XD | 18:27 |
| racarr | I wish there were a term... | 18:27 |
| racarr | I run across this concept a lot, I don't think we are | 18:27 |
| racarr | IO bound or CPU bound rather we are | 18:27 |
| racarr | "contention bound" | 18:27 |
| racarr | kdub: Hmm. About the GPU drivers too..I guess it' not for granted that the flushing etc is the same from threads/processes | 18:30 |
| racarr | switching between contexts in the same process | 18:31 |
| racarr | you have this instance of the driver, GL API, etc. | 18:31 |
| racarr | and a GL context switch require updating state in all of those. | 18:31 |
| racarr | in addition to the actual | 18:31 |
| racarr | GPU switch | 18:31 |
| racarr | whereas when it goes to another process... | 18:32 |
| racarr | <blank> | 18:32 |
| tvoss | you have to do that, too :) | 18:32 |
| racarr | tvoss: Do you? | 18:33 |
| tvoss | racarr, at least on a driver level | 18:33 |
| racarr | with two proceses though I think its hidden in the kernel layer? or at a lower part of the driver layer | 18:33 |
| racarr | whereas say in one process, you have some libglapi.so that has some static TheCurrentGLContextBlaBla data | 18:34 |
| racarr | then you have to tear it down and bring it back up when you switch contexts | 18:34 |
| tvoss | racarr, unless we use a per-thread context stored in thread-specific storage | 18:35 |
| tvoss | racarr, hold on ... | 18:35 |
| racarr | Yes. | 18:35 |
| racarr | I don't know how it works :) or what | 18:35 |
| racarr | all the data might be (context was just a guess) | 18:35 |
| kgunn | racarr: mild skim of scrollback...kinda depends on gpu | 18:36 |
| kgunn | but you'd take the hit generically in gl context | 18:36 |
| racarr | mm | 18:36 |
| racarr | what I am saying is some driver implementation models | 18:37 |
| kgunn | whether switching egl clients in diff thds or procs | 18:37 |
| racarr | might have a higher overhead for | 18:37 |
| tvoss | racarr, I *think* I have an idea, we patched parts of bionic for hybris, however, bionic has a pointer to gl stuff in a fixed place to speed up certain operations | 18:37 |
| racarr | context switches in the same process | 18:37 |
| racarr | espescially fucked up cross libc driver models apparently XD | 18:37 |
| racarr | tvoss: Interesting...wait what are the different | 18:37 |
| racarr | scenarios in multi process mir/single process though | 18:38 |
| tvoss | racarr, well, if you only have one context it might not matter, but assume you cache state in the fixed location ... | 18:39 |
| tvoss | state handwavingly wide | 18:40 |
| racarr | oh | 18:40 |
| racarr | yes | 18:40 |
| racarr | that sort of thing. | 18:40 |
| racarr | right, you can optimize one GL context per process | 18:40 |
| racarr | by penalizing multiple GL contexts per process | 18:40 |
| racarr | which is certainly something I would do on a phone | 18:40 |
| tvoss | racarr, how many gl contexts do we have for the shell? | 18:41 |
| racarr | tvoss: Oh so far just one because the shell is all one surface. | 18:41 |
| racarr | in the in process mir case. | 18:42 |
| tvoss | racarr, why would it be slower then? | 18:42 |
| racarr | then the compositor context | 18:42 |
| racarr | well | 18:42 |
| racarr | 2 total | 18:42 |
| tvoss | that really shouldn't matter | 18:42 |
| racarr | No. I agree espescially because | 18:42 |
| racarr | out of process, we are running multiple surfaces for launcher dah, etc | 18:42 |
| racarr | and its hard to believe | 18:43 |
| racarr | libgl state updating actually | 18:43 |
| racarr | outweighs | 18:43 |
| racarr | flushing the GPU pipeline. | 18:43 |
| tvoss | yup | 18:43 |
| tvoss | racarr, okay, time to actually measure things | 18:44 |
| racarr | Yeah XD I was just going to say I should | 18:44 |
| racarr | stop speculating as fascinating as this is... | 18:44 |
| racarr | I need to finish off this input branch. | 18:44 |
| racarr | tvoss: This branch is the first time we are really messing with the android-input bits much...(removing setInputWindows that is) | 18:45 |
| racarr | and I don't think anyone else except you has looked at InputDispatcher that much | 18:46 |
| racarr | so I will bug you for review on that part tomorrow or so | 18:46 |
| tvoss | racarr, can you send me the branch by mail please? | 18:46 |
| racarr | Yes. Will do so :) it's not quite done...I just got through all the mir refactoring that I need to actually make the InputDispatcher changes XD | 18:47 |
| racarr | but should finish it soon and will mail you | 18:47 |
| racarr | the...InputDispatcher while kind of this nasty object with like 30 responsibilities | 18:47 |
| racarr | has really careful threading and I am worried changing anything | 18:47 |
| racarr | I am going to break it all XD | 18:47 |
| racarr | in a way that the acceptance tests aren't rich enough to expose yet | 18:47 |
| racarr | Ok back to the input bubble | 18:51 |
| racarr | that was fascinating XD | 18:51 |
| racarr | greyback: Hey just wanted to update you...all this landing stuff has been delayed but should be resolved today | 18:57 |
| racarr | and in the meantime I have been working on the machinery in mir for doing the stacking (and then making input work with that) | 18:58 |
| racarr | so I am hoping we can switch to multi window shell soon | 18:58 |
| === marlinc is now known as Marlinc | ||
| tvoss | kdub, ping | 19:18 |
| === francisco is now known as Guest82484 | ||
| greyback | racarr: ok cool, good to know. Anything you need from me? | 19:23 |
| greyback | racarr: I recall you wondering about a mock shell, you think it'd be useful? I can get on that | 19:24 |
| racarr | greyback: No. Just wondering if that makes sense as a sort of shared target (multi window shell) | 19:24 |
| racarr | not sure how much effort it is from your end | 19:24 |
| racarr | greyback: Hmm what do you mean? | 19:24 |
| greyback | racarr: something to test the basics of window management, launch app, close app, switch between them, etc | 19:25 |
| racarr | Oh! Yeah. That's why im trying to get this surace ordering in place | 19:25 |
| racarr | so you can see the launcher on top of apps to switch between them XD | 19:25 |
| greyback | aha yes | 19:25 |
| greyback | ok, well I'll work on the simple QML mock shell for you. It'll be useful for automated testing too | 19:26 |
| racarr | I think getting the basic window management in place would be super useful (just this surface splitting has to happen before its useful, not sure how long that will take) | 19:26 |
| tvoss | greyback, +1 on the distilled shell | 19:26 |
| racarr | greyback: Awesome | 19:26 |
| racarr | super useful for automated testing. Need to get | 19:26 |
| racarr | qtubuntu auto tested in process | 19:27 |
| racarr | greyback: Another thing (sort of ties in) | 19:27 |
| greyback | agreed. Ok, adding to my list. I'm working on abstracting the existing WM code from unity8, and hopefully can get the 2 to meet in the middle | 19:27 |
| greyback | shot | 19:27 |
| greyback | shoot | 19:27 |
| racarr | I think we should kick off this, libunitymir or libmirunity codebase. | 19:28 |
| racarr | I was thinking about it because I wanted to write | 19:28 |
| greyback | tvoss: good god man, don't you ever go offline! | 19:28 |
| racarr | the cursor theme loading code | 19:28 |
| tvoss | greyback, I'm always around ;) | 19:28 |
| racarr | and it doesn't really belong in libmirserver | 19:28 |
| racarr | because really it's a utility for unity to use on top of mir | 19:29 |
| greyback | racarr: yep, we were thinking similarly. The WM code would best live in a libmirqt or something like that | 19:29 |
| tvoss | greyback, but fair point :) | 19:29 |
| racarr | or like...outside of mir or whatever | 19:29 |
| racarr | greyback: mm | 19:29 |
| racarr | so where does the code live? | 19:29 |
| greyback | separate project | 19:29 |
| tvoss | greyback, racarr how about libam, for libapplicationmanager? | 19:29 |
| tvoss | as it is not window but app mgmt | 19:29 |
| racarr | tvoss: Hmm. Maybe. | 19:30 |
| racarr | tvoss: The way I think of it is | 19:30 |
| greyback | cursor is something I'd not thought of. Hmm | 19:30 |
| racarr | Lib-utility-machinery--to-bridge-unity-and-mir | 19:30 |
| greyback | we need to give this a bit of thought, what belongs where | 19:30 |
| racarr | mm | 19:30 |
| racarr | Cursor loading isn't exactly part of "mirqt" definitely | 19:31 |
| greyback | yep | 19:31 |
| racarr | maybe there is a libmirutil and it's unrelated | 19:32 |
| racarr | maybe 90% of the code which is in this one file that everyone copies around | 19:32 |
| racarr | should really be libcursorthemeloader | 19:32 |
| racarr | and this is a red herring | 19:32 |
| racarr | XD | 19:32 |
| greyback | lol, now my head hurts | 19:32 |
| racarr | ignore cursors for now. We do need mirqt though | 19:32 |
| greyback | I keed forgetting the answer to this question. For desktop, what draws the window decoration? | 19:33 |
| racarr | depends on who you ask and the moon cycle | 19:33 |
| greyback | yayz | 19:33 |
| racarr | but I think | 19:34 |
| racarr | the client :) | 19:34 |
| racarr | and I feel rather strongly about it XD | 19:35 |
| greyback | okies. I'm not going to open this discussion :) | 19:35 |
| greyback | it's not my business! :D | 19:35 |
| racarr | haha | 19:35 |
| racarr | well, it sort of is, part of the theory behind client side decorations | 19:35 |
| greyback | well yes, that's true | 19:35 |
| racarr | is that it provides a more uniform model to the shell and mir (simplifying them) | 19:35 |
| greyback | yep | 19:36 |
| racarr | i.e. you have a surface, and it has x, y and w/h and you can treat them all the same | 19:36 |
| racarr | as opposed to like | 19:36 |
| racarr | x, y, w/h, border w/h, frame w/h | 19:36 |
| greyback | indeed. I see that PoV. | 19:37 |
| kgunn | greyback: but are you thinking there should be some common do-hicky that does common window decorations? | 19:37 |
| greyback | kgunn: for consistency yes. | 19:38 |
| kgunn | unity-mir layer going to be the bucket for everything shell & mir refuse to own :) | 19:38 |
| greyback | something has to draw them, I'm just curious as to what's the best place for it | 19:38 |
| racarr | greyback: It becomes difficult to model input, with server side decorations, without allowing the concept of embedded surfaces | 19:38 |
| greyback | racarr: now that is something I hadn't considered. hmm | 19:39 |
| racarr | not impossible, it's just complex, so I lean towards client side decorations, as the consistency bit | 19:39 |
| racarr | is solved fine by a libdrawthedecorations that all the toolkits use | 19:40 |
| racarr | and, of course applications/toolkits can misbehave | 19:40 |
| racarr | but we allow that anyway with "Freestyle" surface type | 19:40 |
| racarr | s | 19:40 |
| racarr | which are undecorated | 19:40 |
| racarr | i.e. chromium | 19:40 |
| greyback | yep, it's only a desktop issue. I see your technical point, that's a good one. | 19:42 |
| greyback | From user perspective, I definitely always want my close button drawn by something. So as long as we patch all the main toolkits, I'll be happy | 19:43 |
| racarr | greyback: I think we can enforce | 19:44 |
| greyback | I do like how easily you can draw window decorations with QML on kwin. But that's just a "nice to have" | 19:44 |
| racarr | no showing up on the screen unless you tell me where the close button on your decorations are | 19:44 |
| racarr | greyback: Couldn't it be the same client side though? | 19:44 |
| greyback | racarr: could be. But 1 QML engine in total, versus one per client - would be a lot more expensive | 19:45 |
| mlankhorst | is it hard to replace install mir and replace the GLES drivers on nexus4 with mesa? | 19:46 |
| mlankhorst | s/replace// | 19:46 |
| greyback | racarr: I did say: "I'm not going to open this discussion" :D Sorry, please get back to your work | 19:46 |
| racarr | ehe I understand | 19:46 |
| racarr | yes sorry! I am | 19:46 |
| racarr | ...a little hyperactive on discussions today it seems | 19:47 |
| greyback | nah, I don't want to trouble you with discussions that have happened a meellion times or more on the internets | 19:47 |
| kdub | tvoss, pong | 19:54 |
| kgunn | mlankhorst: http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html | 19:58 |
| kgunn | mlankhorst: and actually...you can see all the instrucations here http://unity.ubuntu.com/mir/ | 19:58 |
| kgunn | mlankhorst: and technically...you're using the android compile gles drivers | 19:58 |
| kgunn | on nexus4 | 19:59 |
| mlankhorst | yeah, but robclark's been working on freedreno, I wonder if I could make it work with mir | 19:59 |
| kdub | mlankhorst, in theory, it could | 19:59 |
| kgunn | mlankhorst: yeah...in theory | 19:59 |
| mlankhorst | that's fine, I don't expect it to completely work anyway | 20:00 |
| kgunn | mlankhorst: only worry might be egl-hwcomposer shenningans...but if rob got something working w vsynch likely it'll work | 20:00 |
| mlankhorst | I'm not even sure if scanout works at this point, might be worth investigating though :) | 20:03 |
| === racarr is now known as racarr|curry | ||
| === racarr|curry is now known as racarr | ||
| === francisco is now known as Guest56727 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!