| === marcusto_ is now known as marcustomlinson | ||
| === mibofra is now known as Guest7724 | ||
| duflu | greyback__: I might be imagining things but my phones feel more laggy. Did we disable input resampling or something? | 08:32 |
|---|---|---|
| greyback__ | duflu: nope | 08:32 |
| duflu | Hmm, probably imagined | 08:32 |
| greyback__ | dednick working on getting numbers for that, using mir's new perf work | 08:33 |
| duflu | greyback__: Now is a very good time. We have incremental improvements that reduce latency in both 0.14 and 0.15 | 08:34 |
| duflu | And have more after that too. So it won't be sudden, but it is good solid progress | 08:37 |
| duflu | When the improvements actually make it into distro, then they will be announced. In the past we've announced things and then had to revert them before they entered distro | 08:39 |
| alf_ | duflu: greyback__: FWIW, after installing silo 4 (mir 0.14) on mako, scrolling the apps scope feels more laggy than before the update | 08:51 |
| greyback__ | :( | 08:52 |
| duflu | alf_: Is only Mir upgraded or other things too? | 08:52 |
| duflu | Because I've spent months verifying Mir is actually faster in 0.14 than 0.13 | 08:52 |
| duflu | s/is/was/ | 08:53 |
| alf_ | duflu: Here is the list of upgraded/installed packages: http://paste.ubuntu.com/11881589/ | 08:53 |
| duflu | alf_: OK then. Way too early to pin the blame on Mir 0.14 :) | 08:54 |
| duflu | alf_: Also, it's advisable to never use the dash for latency testing. Because the dash has never been fast enough to keep up with 60FPS it will skip frames, which is visually misleading. | 08:59 |
| duflu | ... you can't see subtle changes if your granularity is 33ms between frames to start with | 09:00 |
| anpok | .. one possible purely speculative conclusion could be that we should look for things that cause problems and optimize those.. | 09:04 |
| alf_ | duflu: I don't use it for latency testing. In the end it's the final visual impression that counts, however, and for some reason we have regressed on this in silo 4. | 09:04 |
| duflu | alf_: Sure, it's always possible to do worse. Just that if you're looking for very small improvements in future, don't use the dash for visual testing because its performance is too erratic and unreliable | 09:05 |
| anpok | i am really looking forward to see the perf test with the rest of the stack of the phone included | 09:05 |
| anpok | just making tests with mir demos isnt really interesting | 09:05 |
| duflu | Not fun and interesting, but really important. Because if you upgrade the whole stack (ie. that silo) then you have no chance of finding out which package made it slower | 09:06 |
| duflu | At least not easily | 09:07 |
| anpok | well the silo does not contain substantial changes in any of the other packages | 09:07 |
| duflu | If true, then that's intriguing | 09:09 |
| anpok | i mean .. take server changes.. qtmir plugs in new parts and has its own threading behavior and additional mutual exclusion (event vs render thread) .. so any measurements without that involved cannot be used to make statements about the new phone image | 09:12 |
| * duflu is only going on what he knows. That is the latency improvement in Mir 0.14 works in isolation (if that's the _only_ thin you change on the phone). That was also months ago. Many things could have changed to affect the performance of the phone or Mir specifically. | 09:13 | |
| anpok | we replaced input dispatcher which.. should have no effect on qtmir because it has its own .. so it may effect usc.. | 09:15 |
| anpok | *affect | 09:15 |
| === mibofra is now known as Guest86624 | ||
| === greyback__ is now known as greyback | ||
| === mibofra_ is now known as mibofra | ||
| === mibofra is now known as Guest71542 | ||
| === Guest71542 is now known as mibofra | ||
| === Mirv_ is now known as Mirv | ||
| kdub | streams having size and pixel formats makes little sense to me... buffers and surfaces have sizes, but streams are just a collection of buffers | 13:33 |
| anpok | could it be that because of the double buffering branch the swap took longer.. | 13:37 |
| anpok | hmm but still it happened even without.. so nm. | 13:37 |
| anpok | kdub: what would be the size of a surface? | 13:38 |
| anpok | or how is it defined.. | 13:38 |
| kdub | the size of the surface is the size that the surface is :) | 13:38 |
| kdub | surface size is the intended composition size | 13:39 |
| kdub | and buffer size is the actual size of the buffer | 13:39 |
| anpok | kdub: so the primary size used to compose the buffers.. | 13:43 |
| kdub | anpok, right, the surface size is the size that the compositor will have the surface appear on screen | 13:44 |
| kdub | and the buffer size is the same; its the size of the buffer | 13:45 |
| kdub | and if the two differ, thats what scaling is for | 13:45 |
| kdub | but differing should only be a transient scenario for resize | 13:45 |
| kdub | and an intentional one if there's a stubborn video decoder, perhaps | 13:45 |
| anpok | so if we report user input to the client... hmm | 13:47 |
| anpok | which buffer size do we use | 13:47 |
| kdub | surface size | 13:47 |
| anpok | or surface size | 13:47 |
| anpok | the size the client received as his last resize event.. | 13:48 |
| kdub | yes | 13:48 |
| anpok | or .. instead .. the last resize event sent out to the clien | 13:48 |
| anpok | t | 13:48 |
| anpok | that could be different from the surface size | 13:48 |
| kdub | well, no? | 13:49 |
| anpok | and also different from the buffer size | 13:49 |
| kdub | surface size is the important one... when that changes, we send out the resize event | 13:50 |
| anpok | right we do that instantly | 13:50 |
| kdub | right, and the input changes at that point too | 13:50 |
| kdub | and in the NewBufferSemantics, the client will arrange the transition of buffersize to match the surfacesize | 13:50 |
| === mibofra is now known as Guest83331 | ||
| === rakesh_ is now known as Guest16852 | ||
| Guest16852 | Hi All, I am a newbie, building the mir on ubuntu x86, 64 bit. | 14:23 |
| Guest16852 | But I am facing a problem, thanks in advance. | 14:23 |
| Guest16852 | Building CXX object src/platforms/mesa/server/common/CMakeFiles/mirsharedmesaservercommon-static.dir/buffer_allocator.cpp.o | 14:24 |
| Guest16852 | /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp: In member function ‘std::unique_ptr<mir::graphics::Buffer> mir::graphics::mesa::BufferAllocator::reconstruct_from(MirBufferPackage*, MirPixelFormat)’: | 14:24 |
| Guest16852 | /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp:240:5: error: ‘gbm_import_fd_data’ was not declared in this scope | 14:24 |
| Guest16852 | gbm_import_fd_data data; | 14:24 |
| Guest16852 | ^ | 14:24 |
| Guest16852 | /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp:241:5: error: ‘data’ was not declared in this scope | 14:24 |
| Guest16852 | data.fd = package->fd[0]; | 14:24 |
| Guest16852 | ^ | 14:24 |
| Guest16852 | /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp:248:31: error: ‘GBM_BO_IMPORT_FD’ was not declared in this scope | 14:24 |
| Guest16852 | gbm_bo_import(device, GBM_BO_IMPORT_FD, &data, package->flags), | 14:24 |
| Guest16852 | Can any one please help me, where to find out the definition for function gbm_import_fd_data and GBM_BO_IMPORT_FD | 14:25 |
| Guest16852 | Even I have successfuly installed the mesa library on my machine | 14:25 |
| anpok | Guest16852: do you have gbm.h? | 14:25 |
| anpok | installed.. | 14:25 |
| Guest16852 | let me check | 14:25 |
| anpok | oh you are on ubuntu.. | 14:26 |
| Guest16852 | [00:24 rakesh@param build] : locate gbm.h | 14:26 |
| Guest16852 | /home/rakesh/ubuntu_development/mir/tests/include/mir/test/doubles/mock_gbm.h | 14:26 |
| Guest16852 | /usr/include/gbm.h | 14:26 |
| Guest16852 | yeh it seems | 14:26 |
| anpok | go to your mir source dir and type 'dpkg-checkbuilddeps' | 14:26 |
| Guest16852 | [00:27 rakesh@param mir] : 'dpkg-checkbuilddeps' | 14:27 |
| Guest16852 | dpkg-checkbuilddeps: Unmet build dependencies: android-headers (>= 4.4.2) umockdev (>= 0.8.7) | 14:27 |
| anpok | could you check the mesa version or actually the libgbm-dev version installed | 14:29 |
| anpok | maybe we need to ensure that the gbm headers are new enough | 14:29 |
| anpok | as in the version shown in 'apt show libgbm-dev' | 14:29 |
| greyback_ | anyone give me some hints on debugging this: [1436970458.912329] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-UAyS26/mir-0.13.4+15.04.20150709.2/src/client/rpc/stream_socket_transport.cpp(168): Throw in function virtual void mir::client::rpc::StreamSocketTransport::send_message(const std::vector<unsigned char>&, const std::vector<mir::Fd>&) | 14:30 |
| greyback_ | Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorIN3mir25socket_disconnected_errorEEEEE | 14:30 |
| greyback_ | std::exception::what: Failed to send message to server: Broken pipe | 14:30 |
| greyback_ | 32, "Broken pipe" | 14:30 |
| greyback_ | happens sometimes when I have multimonitor setup and I unplug the second screen | 14:30 |
| Guest16852 | @anpok, this is my gbmlib version installed | 14:31 |
| Guest16852 | Version: 10.1.3-0ubuntu0.4 | 14:31 |
| anpok | so thats trusty.. | 14:34 |
| anpok | but it should have those structs defined | 14:34 |
| Guest16852 | Yup, I am using 14.04 | 14:35 |
| anpok | oh that was added in 10.2 | 14:36 |
| Guest16852 | @anpok, so do I need to upgrade the libgbm-dev ???? | 14:37 |
| anpok | yes.. mir can only build with mesa newer than 10.2 | 14:37 |
| Guest16852 | Thanks mate. | 14:38 |
| Guest16852 | let me try | 14:38 |
| Guest16852 | is there any apt-get install package? | 14:38 |
| Guest16852 | or do I need to build the source code again? | 14:38 |
| anpok | oh you could try picking a newer mesa release, but that might require you to also install a newer libdrm .. and might run into further troubles.. | 14:39 |
| anpok | install as in .. trying to build it locally.. | 14:40 |
| anpok | it might be simpler to just go to utopic or even vivid | 14:40 |
| Guest16852 | Thanks mate, I will install the 15.04 then | 14:41 |
| Guest16852 | that is the easiest way I reckon. | 14:41 |
| rakesh__ | Thanks anpok | 14:44 |
| anpok | welcome - happy hacking. | 14:45 |
| rakesh__ | Yoo too | 14:45 |
| greyback_ | unping - it's a symptom of the server dying | 14:54 |
| anpok | oh which server? .. i mean nested or host? | 14:54 |
| greyback_ | anpok: host | 14:55 |
| greyback_ | http://pastebin.ubuntu.com/11882995/ | 14:55 |
| anpok | oh | 14:55 |
| kdub | greyback_, did the server die? | 14:58 |
| greyback_ | kdub: yeah | 14:59 |
| greyback_ | https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1474891 | 14:59 |
| ubot5 | Ubuntu bug 1474891 in mir (Ubuntu) "USC crash on multimonitor unplug" [Undecided,New] | 14:59 |
| kdub | seems like a mir bug, can probably look this afternoon | 15:00 |
| kdub | or a hwc bug maybe :) | 15:00 |
| greyback_ | kdub: any info I can supply that might help? | 15:00 |
| greyback_ | while I've things set up | 15:00 |
| kdub | greyback_, maybe how often it occurs | 15:00 |
| greyback_ | kdub: it's not guaranteed, maybe 30% of the time | 15:01 |
| kdub | greyback_, alright, will let you know what I see | 15:02 |
| greyback_ | kdub: cool, thanks | 15:02 |
| greyback_ | kdub: I think it's easier to repro on the N4 | 15:03 |
| === dandrader is now known as dandrader|afk | ||
| greyback_ | C++ advice please: http://pastebin.ubuntu.com/11883287/ | 15:52 |
| greyback_ | that fails to compile, as DisplayConfigurationOutputType is an enum, not a class | 15:53 |
| greyback_ | anyone know any trick to avoid having to put :: qualifiers in from of the enum names in that switch? | 15:53 |
| greyback_ | i.e. I can do "typedef mg::DisplayConfigurationOutputType out" and then use out::lvds | 15:54 |
| greyback_ | but if I can avoid that, it would be nice | 15:54 |
| anpok | using out = DisplayConfigurationOutputType; | 15:54 |
| anpok | oops | 15:54 |
| anpok | using out = mg::DisplayConfigurationOutputType; | 15:54 |
| greyback_ | anpok: I'll still need to do out::lvds then yeah? | 15:55 |
| anpok | yes | 15:55 |
| greyback_ | ok, I guess that'll do | 15:55 |
| greyback_ | thanks! | 15:55 |
| === mibofra is now known as Guest96627 | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === davmor2_ is now known as davmor2 | ||
| kgunn | Chipaca: just checking in, i believe you got mir launching ok....and were just having issues with the qml part...is that right ? | 18:41 |
| kgunn | just in case you still needed some help | 18:41 |
| kgunn | Chipaca: also, did you end up having to have some sort of patched drm or mesa driver ? curious what that was, if any | 18:51 |
| Chipaca | kgunn: no, we patched libxkbcommon, but that's all for now | 18:52 |
| Chipaca | kgunn: however | 18:52 |
| Chipaca | HOWever | 18:52 |
| Chipaca | kgunn: anything other than the demo clients that ship with mir can't connect | 18:52 |
| Chipaca | kgunn: so rather puzzled by that | 18:53 |
| kgunn | weird... Chipaca so you couldn't build the qtclock snap like i did in the doc ? | 18:53 |
| kgunn | ...or well, build, instlal and run | 18:53 |
| Chipaca | kgunn: i don't know the doc you mean :-/ | 18:53 |
| === dandrader|afk is now known as dandrader | ||
| kgunn | Chipaca: this one... | 18:54 |
| kgunn | https://docs.google.com/document/d/14msTXe_cFulk9z4jFptEjFJzZx58b1mWU_r4VivLkfA/edit | 18:54 |
| kgunn | qt clock reference app (towards the bottom) | 18:54 |
| Chipaca | ah! | 18:54 |
| Chipaca | no, i haven't tried that, i will do so now | 18:55 |
| Chipaca | kgunn: are you around for a bit more? | 18:55 |
| kgunn | yes Chipaca, will be interesting | 18:55 |
| kgunn | Chipaca: the patch to libxkbcommon, is in wily itself already ? or something separate ? | 19:03 |
| Chipaca | kgunn: not in wily, no; it's http://pastebin.ubuntu.com/11882626/ | 19:03 |
| === Guest96627 is now known as mibofra | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!