| RAOF | Ok. Now that I can boot again... | 00:50 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| olli | RAOF, ping | 03:43 |
| RAOF | olli: Pong | 03:43 |
| olli | hey | 03:43 |
| olli | I don't have the dial in information yet, but will send it via mail to you at the start of the meeting (which starts in 2h:16min) | 03:44 |
| olli | we won't have IRC at the partner side and (g)mail overall is flaky at best | 03:44 |
| olli | RAOF, do you want to give me a cell I can send the information to just in case? | 03:44 |
| olli_ | RAOF, we are starting a bit early | 05:48 |
| olli_ | mike should have sent you the dial in information | 05:48 |
| RAOF | olli_: Yes. | 05:50 |
| RAOF | Although without a country code. | 05:51 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | olli: http://lists.freedesktop.org/archives/mesa-dev/2013-August/044021.html | 07:21 |
| RAOF | olli: (Vendor-neutral OpenGL dispatch) | 07:22 |
| RAOF | olli: Are you likely to need me more on this call? | 08:17 |
| olli | RAOF, we are good | 08:27 |
| olli | thanks for joining! | 08:27 |
| RAOF | Thanks. | 08:28 |
| * RAOF heads Zoëwards | 08:28 | |
| mlankhorst | RAOF: hmz enough mir bugs filed against xserver :P | 11:13 |
| === hikiko is now known as hikiko|lunch | ||
| alf_ | mlankhorst: any thoughts on https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html ? | 12:07 |
| mlankhorst | alf_: yeah, not sure if it only affects the mir case, I've seen a bug like that before | 12:11 |
| === alan_g is now known as alan_g|lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| mlankhorst | alf_: by any chance can you compile intel-gpu-tools? | 12:14 |
| alf_ | mlankhorst: I can, do you need any specific version (e.g. not what's in the package right now)? | 12:16 |
| mlankhorst | git | 12:16 |
| alf_ | mlankhorst: ok, getting and compiling will ping you when I am done | 12:17 |
| mlankhorst | grab the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/ | 12:17 |
| mlankhorst | and then boot it, you don't need to install intel-gpu-tools, just compile it | 12:17 |
| alf_ | mlankhorst: ok | 12:17 |
| alf_ | mlankhorst: (I am already using drm-next kernel) | 12:18 |
| mlankhorst | test if the bug still occurs there, if so please run intel-gpu-tools/tests/gem_flink_race ? | 12:18 |
| mlankhorst | requires i915 | 12:19 |
| mlankhorst | and also prime_self_import | 12:24 |
| alf_ | mlankhorst: bug still occurs (gem objects "disappear" when using prime fds, work correctly when using GEM names) | 12:30 |
| alf_ | mlankhorst: result of tests: http://paste.ubuntu.com/6083268/ | 12:30 |
| mlankhorst | alf_: hm can you set pls_die = 0 before each pthread_create in those 2 tests? | 12:32 |
| alf_ | mlankhorst: ok | 12:32 |
| mlankhorst | alf_: hm and also run the commands without Xorg running :) | 12:32 |
| mlankhorst | alf_: hm, also seems that it requires RAOF's patch for determining dma-buf size | 12:34 |
| mlankhorst | but that one doesn't matter as much | 12:34 |
| mlankhorst | it's a separate test | 12:35 |
| alf_ | mlankhorst: I have added pls_die before the loops that pthread_create() in the tests | 12:36 |
| mlankhorst | yeah then just retry from console, -41 is suspect :P | 12:36 |
| alf_ | mlankhorst: gem_flink_race consistently succeeds without leaks but prime_self_import occasionally fails at export-vs-gem_close-race | 12:43 |
| mlankhorst | alf_: oops, lost connection | 12:57 |
| mlankhorst | did I miss anything? | 12:58 |
| alf_ | mlankhorst: gem_flink_race consistently succeeds without leaks but prime_self_import occasionally fails at export-vs-gem_close-race (http://paste.ubuntu.com/6083327/) | 12:59 |
| mlankhorst | alf_: is that with Xorg killed? | 13:00 |
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| alf_ | mlankhorst: ah, I thought you meant "not in Xorg" not with Xorg killed :) Will try... | 13:01 |
| thomi | morning | 13:04 |
| mlankhorst | alf_: considering it uses debugfs, the test is probably useless if xorg can do things behind it's back, but meh that seems to mean that there is no race in i915 at least.. | 13:07 |
| alf_ | mlankhorst: ok, without X running tests work consistently | 13:11 |
| === mzanetti is now known as mzanetti|otp | ||
| mlankhorst | alf_: hmz | 13:18 |
| mlankhorst | nasty stuff this lifetime thing.. | 13:27 |
| mlankhorst | alf_: you'd be my hero if you could come up with a testcase not involving mir, or some way for me to reproduce it, iirc radeon had some weird bug too? | 13:32 |
| mlankhorst | on non-nested mir with xorg-server | 13:32 |
| mlankhorst | oh.. hmz | 13:34 |
| alf_ | mlankhorst: Instructions to reproduce it with Mir are in the mailing list email. I am not sure how easy is going to be to reproduce this problem outside of Mir, given that we (at least I) have no idea what could be causing it internally :/ | 13:40 |
| mlankhorst | alf_: from what I can tell GEM internally uses no refcount.. eg if you import a bo twice and call close once, the handle will disappear.. | 13:41 |
| mlankhorst | or if you import to the same fd, and call close once | 13:41 |
| mlankhorst | close -> GEM_CLOSE | 13:41 |
| mlankhorst | flink also doesn't seem to survive if GEM_CLOSE is called though.. meh wtf | 13:56 |
| === mzanetti|otp is now known as mzanetti | ||
| mlankhorst | what's the mir ml? | 14:02 |
| mlankhorst | nm got it | 14:03 |
| mhall119 | RAOF: ping | 14:07 |
| mlankhorst | alf_: I'm guessing it's a bug in mesa, specifically the calls like intel_process_dri2_buffer | 14:13 |
| mlankhorst | it assumes that the same fd can be opened multiple times without consequences | 14:13 |
| mlankhorst | the solution is to compare against the internal gem handle instead | 14:14 |
| mlankhorst | which is drm_intel_bo->handle, or w/e equivalent is returned from drmPrimeFDToHandle :P | 14:16 |
| mlankhorst | guaranteed to be unique to the fd, I'll try to cook up some patch | 14:16 |
| alf_ | mlankhorst: That would be great! Ping me if you want me to try out anything. Another related question: My initial implementation of eglcreateimagekhr used image->dupImage() (#if-ed out in the mesa patch) but that doesn't work at all (the creation succeeds)... Any quick ideas why? Does the imag need to be used on the same DRIScreen (the original image is created in the GBM provided DRIScreen)? | 14:20 |
| mlankhorst | alf_: mixing things is probably a recipe for disaster :P though I guess they might be identical | 14:22 |
| mlankhorst | dno tbh | 14:22 |
| mlankhorst | radeon_winsys_bo_from_handle seems to handle it correctly | 14:25 |
| alf_ | mlankhorst: (@dupImage, thanks, at least we have a way to create the image that works) | 14:25 |
| === mzanetti is now known as mzanetti|food | ||
| === alan_g is now known as alan_g|tea | ||
| === mzanetti|food is now known as mzanetti | ||
| mlankhorst | alf_: http://paste.debian.net/37451/ | 14:34 |
| mlankhorst | no idea if that works or not | 14:34 |
| mlankhorst | oops needs refresh :P | 14:34 |
| mlankhorst | http://paste.debian.net/37452/ | 14:35 |
| mlankhorst | that one probably compiles | 14:35 |
| mlankhorst | alf_: let me know if it fixes your issue | 14:36 |
| alf_ | mlankhorst: will do thanks | 14:37 |
| === alan_g|tea is now known as alan_g | ||
| mlankhorst | oops :p | 14:41 |
| dandrader | racarr, ping | 14:42 |
| mlankhorst | plan b for fixing, this one didn't work.. | 14:44 |
| mlankhorst | alf_: http://paste.debian.net/37460/ that one should compile correctly | 14:52 |
| alf_ | mlankhorst: ok, I will try in a bit | 15:00 |
| mlankhorst | alf_: ugh it's missing a chunk | 15:08 |
| alf_ | mlankhorst: ? | 15:17 |
| mlankhorst | alf_: because I suck at making packages, try mesa 9.2-1ubuntu2~ppa1 from https://launchpad.net/~canonical-x/+archive/x-staging/+packages | 15:52 |
| alf_ | mlankhorst: @populating region.name, if we are dealing with prime fd buffers, won't all incoming buffer only have the .fd field populated? Setting the region flink name, won't help us avoid recreating the region. Am I missing something? | 15:59 |
| kdub | alf_, going to try nested mir on android today... alan_g mentioned there might be some branches that could help with that? | 16:02 |
| alan_g | alf_: I meant the cleanup to the "nested" code that you pointed out last week | 16:03 |
| alf_ | kdub: alan_g: the changes are here, although there is also a lot of debug code lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack/ | 16:06 |
| kdub | alf_, cool, thanks | 16:06 |
| alf_ | kdub: the relevant changes are in nested/* files in revision 1054 | 16:09 |
| alan_g | alf_: kdub - if there's no objections I'll wrap them in an MP to get them onto trunk | 16:11 |
| alf_ | alan_g: no objections, although they may need some design love... they were made as a quick POC | 16:12 |
| alan_g | alf_: Understood, was planning that | 16:13 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | alan_g: alf_ kdub ...thanks for all the focus, i'm gonna head to lunch/gym...any questions for me before i head out? | 16:21 |
| alf_ | mlankhorst: tried the patches (I applied the intel changes to a local clean branch of RAOF's git to be exact), no change :/ | 16:38 |
| * kdub thinks NativePlatform and Platform should be the same interface | 17:15 | |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader|lunch is now known as dandrader | ||
| racarr | dandrader: Pong? | 18:02 |
| dandrader | racarr, check private messages | 18:04 |
| kdub | alf_, (if you're still around) would you mind me removing the NativePlatform interface? | 18:59 |
| alan_g|EOD | kdub: why would you want to do that?! | 19:13 |
| kdub | its the same as the Platform interface | 19:13 |
| alan_g|EOD | It is there because we haven't yet proved that they need to be the same. | 19:14 |
| alan_g|EOD | I was keeping it separate with the intention of refactoring to remove duplication later | 19:15 |
| kdub | alan_g|EOD, okay, i'll leave it for now... but with android it is the same | 19:16 |
| alan_g|EOD | kdub: It will probably be the same or a subset | 19:20 |
| racarr | Cool to se enested mir on android come together | 19:46 |
| racarr | and nested in general :) | 19:46 |
| racarr | spinning in circles on this DPMS IPC conundrum though :( | 19:50 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| kdub | racarr, conundrum? | 20:19 |
| ricmm | racarr: ping | 20:23 |
| racarr | ricmm: Pong | 20:26 |
| racarr | kdub: The thing where you turn off the screen via IPC then call next buffer so your server side socket session is blocked | 20:27 |
| racarr | and you can never turn the screen back on | 20:27 |
| kdub | racarr, ah, yes, that one | 20:31 |
| kdub | i guess my thoughts are about the same... swap buffers already has blocking as part of the semantics | 20:33 |
| kdub | well, to put it more clearly | 20:35 |
| kdub | i'm okay with a client getting stuck in that scenario, would seem like its up to them to avoid | 20:35 |
| racarr | ugh sorry internet outage. | 20:56 |
| racarr | kdub: The problem isn't exactly the client getting stuck | 20:56 |
| racarr | the thing is even if you use async next buffers | 20:56 |
| racarr | your server side processor gets stuck too | 20:56 |
| kdub | racarr, yeah, might take some reworking of the message processor then | 21:00 |
| kdub | good morning robert_ancell | 21:01 |
| kgunn | racarr: thinking aloud...is it that you need to like "drain the render queue+ take no more new render submissions" | 21:01 |
| robert_ancell | kdub, hello | 21:02 |
| racarr | kgunn: The thing is it will never drain because it wont finish until you turn the display back on | 21:03 |
| racarr | which wont happen until your last message (this buffer swap is finished) | 21:03 |
| racarr | the buffer swap shouldnt really be an error though | 21:03 |
| racarr | it should just be pending and eventually it runs | 21:03 |
| kdub | racarr, also though, say that the user pushes the power button on the phone or something like that | 21:04 |
| kdub | do we send an event over the wire, the client processes it, and then invokes the 'screen on' command? | 21:05 |
| kgunn | racarr: oh, i was saying as a precondition to blanking....so user hits button, then you stop new requests...but let any pending renders complete | 21:05 |
| kgunn | racarr: that would be weird to be blanked...then allow a render of a frame or 2 of something ancient | 21:06 |
| kgunn | mornin robert_ancell | 21:06 |
| racarr | the thing is if you are processing a pending render from the client that asks to turn off the display | 21:08 |
| racarr | and in the xmir case it is a client | 21:08 |
| racarr | then you never process that message | 21:08 |
| racarr | so you never know like "let pending renders complete" etc | 21:08 |
| kgunn | robert_ancell: is the last mp to kill to the vt input security bug ? https://code.launchpad.net/~robert-ancell/mir/drop-focus-on-vt-switch/+merge/183059 | 21:08 |
| racarr | kdub: On the phone its all in the shell | 21:09 |
| racarr | and clients are just told screen on/off via display configuration and can do their things | 21:09 |
| kdub | racarr, right | 21:09 |
| racarr | swap buffers will block, everyone is happy | 21:09 |
| racarr | xmir is the onlyproblem I thin | 21:09 |
| racarr | and mir demo client display config :p | 21:09 |
| kgunn | racarr: got it...i was thinking of draining renders more from the hw side of things | 21:09 |
| robert_ancell | kgunn, yes, but it's not working. And after talking to RAOF we think it might work better to use the app lifecycle events instead | 21:11 |
| robert_ancell | racarr, How are you supposed to access ApplicationSession? The container just has Session so you'd have to cast it - why doesn't the container contain ApplicationSession? | 21:15 |
| racarr | kgunn: mm | 21:25 |
| racarr | robert_ancell: It's just a matter of where you have to cast | 21:25 |
| racarr | if the container contains ApplicationSession then you have to cast to frontend session in some places | 21:25 |
| racarr | iirc, or some nonsense like that | 21:25 |
| racarr | it's flipped at least once since we started XD | 21:26 |
| racarr | You just have to cast sometimes | 21:26 |
| racarr | because msh::SessionManager API is from mf::Shell so it deals in frontend::Session | 21:26 |
| robert_ancell | racarr, but the container always contains ApplicationSession - so shouldn't we just change the container? | 21:26 |
| robert_ancell | Otherwise what do I do if I can't cast? | 21:26 |
| racarr | robert_ancell: Throw an exception or assert | 21:39 |
| racarr | changing the container is reasonable | 21:39 |
| racarr | there is a bit of problem with testing because ApplicationSession isnt an interface | 21:39 |
| robert_ancell | racarr, why do we need ApplicationSession - why can't this just be part of Session? | 21:39 |
| racarr | robert_ancell: Well we want at least some interface, i.e. the frontend shouldn't use the shell implementation class | 21:47 |
| racarr | perhaps it should be just like surface, mf::Session and msh::Session | 21:47 |
| robert_ancell | ricmm, Should MirLifecycleState contain more states? | 22:52 |
| ricmm | no | 22:59 |
| ricmm | it could contain more information for the application to do more stuff, but the only state exposed to the application is focused(running)/unfocused(not-running) | 23:00 |
| RAOF | mhall119: Yo! | 23:40 |
| RAOF | mlankhorst: You sent a midnighht ping? | 23:40 |
| RAOF | ricmm, robert_ancell: But the lifecycle state callback needs more information, doesn't it? | 23:41 |
| RAOF | ricmm, robert_ancell: Specifically, it needs a cookie so the client can call back to call back to Mir when it's done saving its state. | 23:41 |
| robert_ancell | ricmm, I see mir_lifecycle_state_will_suspend, mir_lifecycle_state_resumed - does that map to focused / unfocused? | 23:43 |
| robert_ancell | also what RAOF said | 23:44 |
| RAOF | Oooh. | 23:49 |
| RAOF | Do we still have time to roll up some more ABI breakage into libmirclient3? | 23:49 |
| robert_ancell | RAOF, not really | 23:54 |
| RAOF | robert_ancell: It doesn't look like it has been built into a package yet? | 23:54 |
| robert_ancell | RAOF, well, right | 23:54 |
| robert_ancell | RAOF, I guess you could make a libmirclient4 without any more work | 23:54 |
| RAOF | Can be *stop* it being built into a package? | 23:54 |
| robert_ancell | RAOF, the numbers cost nothing, it's just the migration. So 2-3 costs the same as 2-99 | 23:55 |
| RAOF | Eh, ok. | 23:55 |
| RAOF | Two more ABI breaks coming right up! | 23:55 |
| RAOF | Ah, no. We changed how get_current_buffer works; this won't be an ABI break. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!