| duflu | RAOF: I tried to make a little progress on Mir's support for i915 but the issue appears to be lower level any idea? https://bugs.launchpad.net/mir/+bug/1275398 | 01:22 |
|---|---|---|
| ubot5 | Launchpad bug 1275398 in Mir "i945: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,Triaged] | 01:22 |
| duflu | (i915 driver, i945 chip) | 01:22 |
| RAOF | duflu: Do you know if it's black buffers, or transparent buffers? | 01:45 |
| duflu | RAOF: Varies between clients :) | 01:45 |
| duflu | Possibly varies between clients on RGBX/RGBA | 01:45 |
| RAOF | Ah, so the buffers would just be uninitialised, then. | 01:46 |
| RAOF | Almost. | 01:46 |
| RAOF | I guess our buffer initialiser gets to them, but they never get _new_ content. | 01:46 |
| RAOF | duflu: Does in-process rendering work? | 01:46 |
| RAOF | In-process client, I mean. | 01:46 |
| duflu | RAOF: I need to test more I guess but render_surfaces is perfect | 01:47 |
| RAOF | duflu: mir_demo_standalone_inprocess_egl ? | 01:48 |
| duflu | RAOF: I'll have to boot up the noise machine again | 01:48 |
| duflu | afk | 01:48 |
| xnox | * libmirclient7 [amd64 armhf i386] (for libboost-system1.54.0) | 01:57 |
| xnox | * libmirplatformgraphics-mesa [amd64 armhf i386] (for libboost-program-options1.54.0) | 01:57 |
| xnox | * libmirserver18 [amd64 armhf i386] (for libboost-program-options1.54.0) | 01:57 |
| xnox | * libmirserver18 [amd64 armhf i386] (for libboost-system1.54.0) | 01:57 |
| xnox | Above packages are the last few that are in main and use boost1.54 in utopic, is a daily release (even if no-change one) planned soon into the utopic archive? | 01:58 |
| duflu | RAOF: inprocess_egl fails too -- black screen just the cursor | 01:58 |
| xnox | or should i upload no change rebuild into utopic? | 01:58 |
| RAOF | xnox: Feel free to no-change rebuild. | 01:59 |
| xnox | RAOF: thanks. | 01:59 |
| RAOF | xnox: We don't daily-release into utopic, thanks to our current embarrassing lack of ABI. | 01:59 |
| duflu | New competition: Who can make Mir work on something older than this '06 Pentium D? :) | 02:00 |
| duflu | Although I think we're most limited by DRI2/Mesa support :( | 02:00 |
| xnox | RAOF: and are boost-templates known to leak to ABIs of things that build against lib*mir*-dev ? i don't think there are any abi/api changes to system&program-options, but still would be interesting to know. | 02:01 |
| RAOF | xnox: It would not surprise me if boost templates leaked into the ABI (such as it is), but I'm not sure. | 02:02 |
| xnox | RAOF: ok, thanks. | 02:02 |
| RAOF | Hm. Actually, I'm pretty sure that boost::asio is a part of our current ABI. | 02:02 |
| duflu | Really? | 02:03 |
| xnox | RAOF: i wish boost had stable abi =( | 02:04 |
| RAOF | duflu: Well, it's hard to say, isn't it. There's certainly a bunch of boost::asio in include/server/*.h, which is ostensibly public. | 02:04 |
| * RAOF wonders what contortions boost would need to go through in order to ensure a stable ABI. | 02:05 | |
| xnox | RAOF: well, stdlib and stl manage it =) the piles of diff in asio alone from boost1.54 -> boost1.55 do not make me happy... | 02:11 |
| xnox | RAOF: i think i'll wait until we have some images of utopic before rebuilding those and/or wait for a release to utopic. | 02:11 |
| RAOF | xnox: That seems sensible; we've got a process that'll rebuild all our reverse-depends when that happens, anyway. | 02:12 |
| xnox | RAOF: excellent! | 02:12 |
| === chihchun is now known as chihchun_afk | ||
| duflu | RAOF: If your hacking journeys have you retained any system that uses the i915 driver? | 02:41 |
| duflu | -If +In | 02:41 |
| RAOF | duflu: I've got an Atom netbook; I forget whether or not that uses i915_dri.so | 02:42 |
| duflu | RAOF: Yeah it should | 02:42 |
| duflu | Mine does | 02:42 |
| duflu | As long as it predates PowerVR | 02:42 |
| RAOF | It does :) | 02:42 |
| duflu | RAOF: It's fun to try even if you just install trusty plus mir-demos. Suddenly the old system has super-smooth graphics and some new potential :) | 02:43 |
| duflu | Although unity7 is also less of a hog in trusty than previous releases too. Somewhere in the last 12 months it's gone from 60 seconds opening the dash to almost instant. \o/ | 02:47 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| duflu | RAOF: What is DRM_API_HANDLE_TYPE_SHARED? | 06:15 |
| duflu | I can see some logic in Mesa's i915 changed for that type in the Mir patch | 06:15 |
| RAOF | That would be for flink, IIRC. | 06:16 |
| duflu | Oops, actually the change affects != DRM_API_HANDLE_TYPE_SHARED | 06:16 |
| RAOF | Hm. It's entirely possible that I just haven't done the necessary hookup bit for i915? | 06:16 |
| RAOF | At one point it was sharing files with i965, then that got split and they got copies of identical files that then diverged... | 06:17 |
| duflu | + if (whandle->type != DRM_API_HANDLE_TYPE_SHARED) | 06:17 |
| duflu | + return NULL; | 06:17 |
| duflu | That's new. Did it ever work? | 06:17 |
| RAOF | Oh! | 06:17 |
| RAOF | You're looking at the wrong i915 | 06:17 |
| RAOF | :) | 06:17 |
| duflu | RAOF: Looking at my Ubuntu Mesa source :) | 06:17 |
| RAOF | That's the Gallium driver, which we don't use. | 06:17 |
| RAOF | You want src/mesa/drivers/dri/i915. | 06:18 |
| RAOF | Confusingly, there are two separate i915 drivers in the mesa source. | 06:18 |
| duflu | I'm confused by most of the Mesa source so that's OK | 06:19 |
| RAOF | Hm. Is there some way to add a target to each compiled target in cmake? | 06:55 |
| duflu | RAOF: Umm, rephrase that? | 06:57 |
| duflu | Add a dependency? | 06:58 |
| duflu | RAOF: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:add_dependencies | 06:58 |
| RAOF | duflu: Specifically, I want to grab a total list of sources (to run them through clang-check -analyze) | 07:10 |
| anpok | RAOF: last time I did that by replacing the add_executable and add_library alls with homegrown macros that behave same | 07:16 |
| RAOF | anpok: Yay? Ok, I'll stop trying to make a branch that'll automatically run the static analyser :/ | 07:16 |
| duflu | RAOF: cmake usually has an existing answer if you can wade through the docs | 07:19 |
| anpok | back then I also wanted to acchieve something like virtual library target, since the project could be build all static libs or as shared libraries or static exectuables.. and avoid fpic where possible.. | 07:20 |
| duflu | anpok, RAOF: I hear GNU Make is still awesome | 07:52 |
| duflu | Just that CMake dumbs it down too much, sometimes | 07:52 |
| duflu | Whee, all the (review) things. | 08:25 |
| duflu | alf_: I spent a while looking at the screencasting stuff on the weekend. What was the motivation for recompositing to screencast? is ReadPixels truly infeasible? | 09:12 |
| duflu | I mean the whole thing relies on the assumption that it's faster to GL render twice than to render one and then glReadPixels... ? | 09:13 |
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf_, anpok: are you OK with this? https://code.launchpad.net/~alan-griffiths/mir/purge-some-sessions/+merge/217252 | 12:32 |
| alf_ | alan_g: looking | 12:34 |
| alan_g | thanks | 12:39 |
| kgunn | AlbertA: is this bug a dup really of the stale socket cleanup ? | 13:44 |
| kgunn | https://bugs.launchpad.net/mir/+bug/1189770 | 13:44 |
| ubot5 | Launchpad bug 1189770 in Mir "[DRM/GBM] Killing (or crashing) Mir often leaves the screen blank and difficult to recover" [Medium,Triaged] | 13:44 |
| kgunn | kinda feels like it is | 13:44 |
| alan_g | kgunn: no - that's about locking up the VT (e.g. input doesn't work) | 13:48 |
| alf_ | kgunn: alan_g: Have you seen that recently? | 13:52 |
| alan_g | no | 13:53 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| AlbertA | kgunn: no that's different it still happens actually | 14:27 |
| AlbertA | kgunn: alf: alan_g: I see that all the time when I kill (not sigkill) mir on my intel laptop | 14:27 |
| AlbertA | well maybe not all the time | 14:27 |
| AlbertA | actually I think when mir dies | 14:28 |
| AlbertA | with an exception | 14:28 |
| AlbertA | I usually get a blank screen that I can only switch out of with sudo chvt 7 | 14:28 |
| alan_g | AlbertA: is that a consequence of bug 1285084? | 14:29 |
| ubot5 | bug 1285084 in Mir "Exceptions are raised in a compositing thread and not handled" [Undecided,New] https://launchpad.net/bugs/1285084 | 14:29 |
| alan_g | Because exceptions in most threads are handled sanely | 14:30 |
| AlbertA | alan_g: could be, I haven't investigated it | 14:30 |
| alf_ | AlbertA: kill => inadverently kill by doing something wrong that leads to exception? | 14:31 |
| AlbertA | alan_g: the last time I saw it was when i investigated the power off display bug which was throwing an exception | 14:31 |
| AlbertA | alf_: Sorry not by killing that works fine. I mis-remembered | 14:32 |
| alf_ | AlbertA: interesting, do you remember from which thread it was thrown from? We can force an exception there to reproduce consistently... | 14:32 |
| alf_ | AlbertA: s/from// | 14:33 |
| AlbertA | alf_: Yeah it was the bug daniel fixed, so the DisplayConfiguration valid check | 14:33 |
| alf_ | AlbertA: thanks | 14:33 |
| AlbertA | alf_: which was I suppose the demo shell responding to a power key event | 14:33 |
| AlbertA | alf_ : whatever that thread is | 14:34 |
| sil2100 | kgunn: hi! | 14:35 |
| sil2100 | kgunn: so, we would need to re-assign your Mir silo for utopic, as it's currently still building stuff for trusty | 14:36 |
| sil2100 | kgunn: are you guys using the silo right now? Since my re-assignment will require a rebuild of all packages | 14:36 |
| mterry | greyback, welcome back! I'm sure you have a backlog of stuff, but when you have a few minutes, I wanted to pick your brain on lifecycle events & nested servers | 14:39 |
| greyback | mterry: am happy to talk whenever you'd like | 14:40 |
| mterry | greyback, OK. So I have USC sending lifecycle events like will_suspend and resumed to the greeter (which is a glorified unity8 session -- nested mirserver etc). It never seems to see them... I went down the stack to platform-api on the greeter side, and it never seems to get the event | 14:42 |
| sil2100 | kgunn: tell me when you think I could do that | 14:42 |
| mterry | greyback, does the nested server hide such events or not listen for them in the first place? | 14:42 |
| kgunn | sil2100: hmmm....letme just grab the packages real quick and then you can have it, i'll ping you.... | 14:43 |
| sil2100 | kgunn: ok, thanks! | 14:43 |
| greyback | mterry: I don't know. I'm not aware of any reason why a nested server would hide those events or ignore them. Have you any sample code I could test with? | 14:45 |
| kgunn | sil2100: ok, go for it | 14:46 |
| sil2100 | kgunn: thanks, doing o/ | 14:47 |
| kgunn | sil2100: yeah...we'll want to target utopic | 14:47 |
| mterry | greyback, sorry, got distracted. Sample code... no just some local edits to my various split branches. I could try to reproduce using mir demo code | 15:00 |
| greyback | mterry: ok. well on idea is that platform-api only has lifecycle listenening code in its client library, not its server lib (lp:platform-api:src/ubuntu/mirclient) | 15:03 |
| mterry | greyback, nested servers don't run both code? | 15:03 |
| mterry | I figured they would be clients on one side and servers on the other | 15:03 |
| greyback | mterry: I don't see how one process can use platform-api client & server simultaneously tho | 15:05 |
| greyback | maybe they can, but I expected symbol collisions | 15:06 |
| mterry | Yeah, I don't know how the code fits together. I just assumed that a nested mirserver was re-using the client code somehow. But if it isn't, that would explain some of what I'm seeing | 15:06 |
| greyback | mterry: the nested server is a Mir server itself, it is run with QT_QPA_PLATFORM=ubuntumirserver right? | 15:07 |
| mterry | greyback, right, which would pick up the side of platform-api without the listening it seems | 15:07 |
| greyback | if so, then the platform-api server plugin is being used, and that doesn't have lifecycle event listening code build in | 15:07 |
| greyback | indeed | 15:07 |
| greyback | that's my best theory at the moment | 15:07 |
| mterry | greyback, alright. I'll test that out, thanks | 15:07 |
| greyback | mterry: let me know if I can help more | 15:08 |
| alf_ | AlbertA: How do you support a buffer queue of one in the new implementation? Won't that lead to the compositor blocking? | 15:36 |
| AlbertA | alf_: I add the only buffer to the free queue | 15:37 |
| AlbertA | alf_: so then the compositor and clients end up sharing the same buffer | 15:37 |
| AlbertA | alf_: all the time | 15:37 |
| AlbertA | alf_: then after I added to the free queue at the very beginning the | 15:38 |
| AlbertA | operations are all the same as in the other cases | 15:38 |
| AlbertA | alf_: i.e. a client's next request (after release) will block until compositor composites that buffer | 15:39 |
| === alan_g is now known as alan_g|afk | ||
| alf_ | AlbertA: but what if a buffer is held by the client when the compositor acquires it? It will just get it? | 15:40 |
| AlbertA | alf_: yes because it wil fall under the "use current buffer" condition | 15:41 |
| alf_ | AlbertA: ok, I am not sure how well SwitchingBundle handles this scenario... | 15:42 |
| AlbertA | alf_: hence why I wrote the unit test :) | 15:42 |
| alf_ | AlbertA: it's conceivable that it doesn't handle it well (since we don't have users of this use case) | 15:42 |
| AlbertA | alf_: some of the unit tests in SwitchingBundle do exercise constructing a SwitchingBundle of 1 buffer | 15:43 |
| AlbertA | alf_: but there wasn't any specifically testing the behavior of 1 buffer scenario. | 15:44 |
| greyback | mterry: question for you: what launches unity-system-compositor? I can't see a system upstart job for it | 15:45 |
| mterry | greyback, lightdm manages it | 15:46 |
| greyback | mterry: ah ok | 15:46 |
| === alan_g|afk is now known as alan_g | ||
| alf_ | AlbertA: I wonder if the logic around buffer_to_release in compositor_acquire() could be problematic for the single buffer scenario. For example, we pop() the buffer from the ready_to_composite_queue and set the current_compositor_buffer with it. Then we release() it and in give_buffer_to_client() we need to resize, so the buffer pointer in current_compositor_buffer is now invalid. | 15:54 |
| AlbertA | alf_: yes you are right | 15:55 |
| AlbertA | alf_: I need to add that to the unit test | 15:55 |
| alf_ | AlbertA: ahhh, the beautiful land of the component formerly known as SwitchingBundle :) | 15:58 |
| alf_ | AlbertA: at least in the new version we can *read* the code and *find* the problems | 15:59 |
| AlbertA | alf_: :) | 15:59 |
| AlbertA | alf_: it kinda mirrors government | 15:59 |
| AlbertA | alf_: because it shows the danger of centralizing many things in one | 16:00 |
| AlbertA | alf_: :) | 16:00 |
| kdub | lol | 16:01 |
| === chihchun_afk is now known as chihchun | ||
| === dandrader is now known as dandrader|lunch | ||
| mterry | Mir folks -- why is there no version of mir_connection_set_lifecycle_event_callback for mirservers that are nested? Surely nested servers want to hear about such events too. I'll file a feature request bug unless ya'll tell me it doesn't make sense | 17:03 |
| mterry | Hmm, the mirserver library links to mirclient. Maybe I can use that API after all | 17:11 |
| josharenson | Question: I have a thread that calls "run_mir" (which blocks). Is there a graceful way to stop mir? | 17:28 |
| kdub | that function is more of a helper | 17:37 |
| kdub | mir::DisplayServer has run() and stop() | 17:37 |
| kdub | josharenson, ^^ | 17:38 |
| josharenson | kdub, ack | 17:55 |
| kdub | mterry, don't know the specific problem, but if something in the mir client api is useful to the things the custom nested server is doing, then no reason not to use the client api | 18:32 |
| kdub | and, if its a thing that should be universally done, then we should pull it into the nested code | 18:32 |
| mterry | kdub, yeah... but MirConnection isn't exposed to mirserver users. You can get the HostConnection, but that class isn't defined externally | 18:32 |
| mterry | kdub, I ended up filing bug 1313832 | 18:33 |
| ubot5 | bug 1313832 in mir (Ubuntu) "[enhancement] Allow nested mirservers to listen for lifecycle events" [Undecided,New] https://launchpad.net/bugs/1313832 | 18:33 |
| === dandrader|lunch is now known as dandrader | ||
| josharenson | kdub, when I start the display server via display_server.run() and join the thread, the client application says it cannot connect to the display server... After looking at the example basic server, I can't figure out what I'm missing (client app runs under example server just fine) | 18:58 |
| kdub | how do you join the thread if the display server is still running? o.O | 19:05 |
| josharenson | I'm kicking off a thread that calls a function that calls run... joining my thread back to the main thread.... is the server supposed to block after calling run? | 19:06 |
| kdub | iirc, it is running until stop() | 19:07 |
| josharenson | so is the best way to call run_mir with the command to start the client as the lambda arg? | 19:08 |
| josharenson | punctuation would have made that more clear... is the best way, to run a client without manually starting a server beforehand, ^^ | 19:09 |
| kdub | josharenson, it depends on what you're trying to do really | 19:13 |
| josharenson | kdub, start mir server -> run glmark2 -> stop server | 19:14 |
| kdub | run_mir is helpful code if you're starting an executable that you'd expect to respond to ctrl-c | 19:14 |
| kdub | so with that, I'd come up with an executable that fires off the mir server, forks out the client, waits for the child to end | 19:14 |
| kdub | then DisplayServer::stop() | 19:15 |
| kdub | something like that | 19:15 |
| kdub | i think the acceptance tests do something similar | 19:15 |
| josharenson | kdub, ok thanks.. I just got something that _kind of_ works.. ill reference the acceptance tests | 19:16 |
| kdub | josharenson, yw | 19:18 |
| kdub | camako, have some time to chat about https://code.launchpad.net/~kdub/mir/overlay-gl-program/+merge/217153/comments/517227 ? | 19:56 |
| camako | kdub, can I ping you in a bit? | 19:57 |
| kdub | camako, sure, no rush | 19:57 |
| === dandrader is now known as dandrader|afk | ||
| camako | kdub, sorry that took a while | 21:01 |
| kgunn | AlbertA: might give a look over this | 21:16 |
| kgunn | https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity-ui-power | 21:16 |
| kgunn | i just added a potential policy idea... | 21:16 |
| AlbertA | kgunn: yes it's being discussed over e-mail, I have to change the mir tasks | 21:16 |
| AlbertA | kgunn: as that changed a while back during previous IRC discussions | 21:17 |
| kgunn | AlbertA: we need to land things faster i can tell :) before they change on irc | 21:17 |
| AlbertA | kgunn: :) | 21:17 |
| AlbertA | kgunn: well what I implemented is in sync with the IRC discussions | 21:18 |
| kgunn | thats god news | 21:18 |
| kgunn | or good news even | 21:18 |
| AlbertA | kgunn: the missing parts so far | 21:18 |
| AlbertA | kgunn: is long-press power button (new to me) | 21:18 |
| kgunn | ah | 21:19 |
| AlbertA | kgunn: and who will communicate the per session timer settings/backlight value preferences | 21:19 |
| AlbertA | kgunn: to USC | 21:19 |
| kgunn | AlbertA: so kinda feels like either usc reads them direct ?...or...relies on shell & we make in interface to keep it all agnostic... | 21:20 |
| kgunn | but...u of u-s-c is unity... | 21:20 |
| kgunn | so... | 21:20 |
| kgunn | what are your thoughts | 21:21 |
| AlbertA | kgunn: right...currently it's built in defaults, overridable through the command line | 21:21 |
| AlbertA | kgunn: but we do need an interface, just don't know if DBus, or resuing the mir socket | 21:21 |
| AlbertA | kgunn: depends on who will communicate the info | 21:21 |
| AlbertA | kgunn: could be the lightdm socket as well... | 21:22 |
| kgunn | mmm...right, it is per user session | 21:22 |
| AlbertA | Saviq: ^ | 21:24 |
| AlbertA | probably too late | 21:25 |
| kdub | camako, pong, np | 21:25 |
| kgunn | AlbertA: actually...he doesn't sleep...i'm convince | 21:25 |
| kgunn | d | 21:25 |
| camako | kdub, I see your points and am updating my comments... | 21:25 |
| kdub | camako, cool, thanks | 21:26 |
| * kgunn loves that camako is going to help on sticky subjects | 21:26 | |
| camako | kdub, I 'm good... Just the naming bothers me a bit... | 21:26 |
| kdub | yeah, I have to address some of daniel's naming comments too | 21:26 |
| kdub | i think that overlay vs optimized-surface is a good distinction to make in the naming | 21:27 |
| kdub | with overlay being the android concept | 21:27 |
| camako | kdub, I like :-) | 21:27 |
| kgunn | AlbertA: and would u-s-c really be involved for brightness/ALS ? | 21:27 |
| AlbertA | kgunn: only as a proxy to powerd | 21:27 |
| kgunn | ah | 21:27 |
| kgunn | pass thrug | 21:27 |
| AlbertA | kgunn: yeah | 21:28 |
| kgunn | damn i can't type today | 21:28 |
| camako | kdub, on second thought, they'd be "optimized" if hwc wouldn't reject them.. | 21:29 |
| camako | kdub, perhaps "fallback" or smth like that | 21:29 |
| camako | kdub, but if nothing works, "optimized" is better than "overlay" | 21:30 |
| camako | kdub, also this means that by falling back to gl, we are requiring gl capable gpu on the SoC.. should we worry about that? | 21:31 |
| kdub | camako, i don't think so, we won't hit an opengles-less android device soon | 21:39 |
| kdub | camako, 'optimized' was from the perspective of the DisplayBufferCompositor | 21:40 |
| kdub | within the android platform, 'overlay' vs 'fallback' is a good distinction | 21:42 |
| kdub | the pot o gold at the end of the rainbow for me is like... wobbly windows, and then when the animation stops, the hwc overlay stuff seamlessly kicks in | 21:44 |
| camako | kdub, I'm not worried abt Android-capable devices.... But there are devices coming out with only a 2D gpu e.g... Those devices could replace GLRenderer... but now we *require* GL for the "overlays" | 21:45 |
| kdub | well, we don't though, they can just give a stub gl program factory | 21:45 |
| kdub | and then that would be another platform without gl | 21:45 |
| kdub | s/stub/null | 21:46 |
| camako | kdub, how will they render overlays? | 21:46 |
| kdub | well, thats for that platform to figure out, like say its the omap dss | 21:46 |
| kdub | and there is made an explicit opengl-less platform for that... they can just reject the optimization function, or under the hood, they can do what they want | 21:47 |
| kdub | like, I sent out this line on the ML | 21:47 |
| kdub | http://bazaar.launchpad.net/~kdub/mir/future-default-display-buffer-compositor/view/head:/src/server/compositor/default_display_buffer_compositor.cpp#L49 | 21:47 |
| kdub | and at that line, if the platform returns true for line 64, then the platform gets the RenderableList to the screen however it wants | 21:48 |
| kdub | or, for mesa, mesa can accept a renderlist that has a 64x64 image + a fullscreen image | 21:49 |
| kdub | and under the hood, it figures out 'hey, this is a hardware cursor, and this is a bypass' | 21:50 |
| kdub | and that same line would work for android, where under the hood, it does the whole HWC dance | 21:50 |
| camako | kdub, the term "overlay" is already confusing us.... I mean how will they render overlay-rejects? The only method we provide for layers rejected by hwc, which is not replaceable, is gl... Or am I misunderstanding... | 21:51 |
| kdub | camako, like, a hwc extension would have to come out, I think | 21:53 |
| kdub | that is like OpenGL-less HWC | 21:53 |
| camako | kdub, I'm not worried what happens under the hwc hood (it's SoC specific... 2D, DSS are all fair game)... But the fallback path is the common denominator and minimum requirement assumption | 21:53 |
| kdub | camako, taking a step back... what are you anticipating happening? | 21:54 |
| camako | kdub, when we have taken much pain to make things replaceable, are we okay with having this assumption which ties us to opengl | 21:55 |
| AlbertA | camako: but that's a requirement of opengl hinted strongly by the hwc headers | 21:55 |
| kdub | well, it ties us to opengl only for a platform which has a hard opengl requirement anyways | 21:55 |
| camako | kdub, yes as long as we are in the Android world we are good | 21:56 |
| camako | kdub just wanted to make clear that just because GLRenderer can be replaced doesn't mean we can do without GL | 21:56 |
| AlbertA | camako: isn't that the point of having a separate GL program as fallback for android? | 21:57 |
| camako | kdub, I'm ok with this assumption... Just want to make sure it's explicit | 21:57 |
| kdub | right | 21:59 |
| camako | AlbertA: yes | 21:59 |
| kdub | the other thing though is post_update() on mg::DisplayBuffer assumes OpenGL too | 21:59 |
| camako | Ok so we basically require opengl... which is ok... | 22:00 |
| AlbertA | camako: oh I think I see your point...why put an extra program if we require GL implicitly anyway | 22:01 |
| AlbertA | camako: is that it? | 22:01 |
| camako | AlbertA: Yes part of it... | 22:01 |
| camako | AlbertA: But that means factoring the heck out of GLREnderer and making things difficult | 22:02 |
| kdub | but, my big point is that the HWC program has strict requirements, GLRenderer will grow and flex | 22:02 |
| kdub | and I don't want the HWC to break as GLRenderer grows and flexes to support like... window decorations or animations | 22:03 |
| camako | Sure, I basically don't have a problem with what we are doing... | 22:03 |
| camako | But was under the impression that, with GLRenderer being replaceable | 22:03 |
| camako | we could do away with GL and support GL-less platforms eventually (of course not possible now with hwc etc) | 22:04 |
| AlbertA | camako: yeah, I would think it would be another folder under platform :) | 22:04 |
| camako | but I understand now that GLRenderer being replaceable is not necesarily to get rid of gl-capable gpu | 22:04 |
| kdub | perhaps, although there is other plumbing that would have to be done | 22:04 |
| kdub | and a lot of that plumbing would be rooting the GL concepts out of the platform interfaces | 22:05 |
| kdub | but, overall, yes :) | 22:05 |
| camako | Before that we'd have to break the Android dependency... Android require gles2 capable gpu now | 22:05 |
| AlbertA | camako: yeah no doubt more changes would be needed to support it | 22:06 |
| AlbertA | camako: but your gpu-less platform would basically provide a rendererfactory that creates | 22:06 |
| AlbertA | camako: the gl less renderer | 22:06 |
| kdub | right | 22:06 |
| kdub | and really, the GLRenderer and DefaultDisplayBufferCompositor are just split between "this one doesn't have GL and this one does lines" | 22:07 |
| kdub | I think the more important interface is DisplayBufferCompositor | 22:07 |
| kdub | esp because GLRenderer's interface is kinda weird | 22:07 |
| kdub | like, 'begin()' just does a glClear, and end() does a texture cache flush, and if you don't call it, you leak and explode | 22:08 |
| kdub | and, if you call end() before the eglSwapBuffers, you get tears | 22:08 |
| kdub | things like that :) | 22:08 |
| AlbertA | kdub: yeah it's tricky to wrap state machines | 22:09 |
| camako | Won't be long before compositors run on ucontrollers... Some gpu companies working on it... Mostly 2D at first... | 22:10 |
| camako | Anyways... would be a good problem to have for ubuntu | 22:10 |
| kdub | right, like maybe raspberry pi or something.. maybe some of our intrepid lurkers could look at that :) | 22:11 |
| kdub | 'there's only 2 things hard in computer science, cache invalidation and naming things' | 22:30 |
| * kdub thinks of that quote often when trying to come up with class names | 22:31 | |
| === dandrader|afk is now known as dandrader | ||
| Saviq | kgunn, AlbertA, :P | 23:42 |
| RAOF | kdub: That quote's incorrect; the correct one is “There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors” ☺ | 23:46 |
| kdub | RAOF, haha, clever | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!