| === chihchun_afk is now known as chihchun | ||
| RAOF | Why, hello there lldb. | 05:23 |
|---|---|---|
| RAOF | You would appear to have a *substantially* more featureful curses UI than gdb. | 05:23 |
| RAOF | Also, you don't crash when trying to read debugging symbols from mir_unit_tests, so +1 there, too. | 05:24 |
| * alan_g wonders if it should be concerning that he, alf_ and duflu are *all* abstaining on the same large MP. | 08:46 | |
| duflu | alan_g: I'm just clearing my plate. Already too full to finish everything before July ;) | 08:46 |
| alan_g | Ah yes, the familiar whoosh of deadlines going past. ;) | 08:48 |
| alf_ | alan_g: RAOF: perhaps discussing this in a hangout would help? | 08:50 |
| RAOF | alf_: Possibly, but not today; it's dinner time here. | 08:50 |
| alf_ | RAOF: ok | 08:51 |
| alan_g | alf_: Probably not. Perhaps we should land it and see if anything bad happens. | 08:52 |
| alan_g | alf_: do you have anything to add to the review? Or a desire to look again? | 09:04 |
| alf_ | alan_g: Not really. As mentioned I am OK one way or the other. | 09:07 |
| duflu | alan_g: If you mean 1hz then land it. That will get us much closer to resolving enough regressions to roll 0.2.0 | 09:08 |
| duflu | Although, not close enough | 09:08 |
| alan_g | duflu: that was my thinking. | 09:09 |
| Saviq | greyback, so... I managed to get past eglBindAPI, but now I can't get past eglGetDisplay - I rebuilt qtubuntu with that commented out, but something else must be calling it :| | 09:22 |
| greyback | Saviq: hmmm, this definitely used to work | 09:24 |
| Saviq | :/ | 09:26 |
| greyback | Saviq: did you build qtubuntu with debugging on? eglGetDisplay is only a check in an assert call, should not be called in release | 09:27 |
| Saviq | greyback, nope, dpkg-buildpackage | 09:27 |
| greyback | weird | 09:27 |
| Saviq | greyback, that's why I mean something else must be calling it | 09:27 |
| Saviq | greyback, Qt, even... | 09:27 |
| greyback | now i get you | 09:28 |
| * Saviq tries with 5.2 | 09:28 | |
| Saviq | but have to reboot first, phone mount-loop again... | 09:28 |
| Saviq | brb | 09:28 |
| greyback | Saviq: LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/apitrace/wrappers/egltrace.so:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libGLESv2.so.2 qmlscene redBox.qml --desktop_file_hint=/usr/share/applications/dialer-app.desktop | 09:38 |
| greyback | ^^ try that. Seems the order of loading the libraries important for symbol resolving | 09:39 |
| greyback | and qtubuntu doesn't link directly to egl, which is suspect | 09:40 |
| greyback | (well I don't expect it to cause this fail) | 09:40 |
| Saviq | greyback, ok will do in a sec | 09:41 |
| greyback | Saviq: here's hte Qt5.2 output anyway: http://pastebin.ubuntu.com/7496692/ | 09:41 |
| alf_ | alan_g: Any reason we are explicitly calling delete_endpoint() in atexit() and SIGINT/SIGTERM? The server should clean up properly on normal shutdown. | 09:51 |
| alan_g | alf_: I don't remember a specific reason. Probably from overlapping attempts to avoid stale endpoints. | 09:53 |
| alf_ | alan_g: ok | 09:57 |
| === jono is now known as Guest41797 | ||
| === alan_g is now known as alan_g|lunch | ||
| Saviq | hey guys, we'll need your help on https://bugs.launchpad.net/unity8/+bug/1321189 | 12:30 |
| ubot5 | Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged] | 12:30 |
| Saviq | we gathered as much info as we knew how to | 12:31 |
| Saviq | and will need help going forward | 12:31 |
| alf_ | Saviq: how can we help? | 12:39 |
| Saviq | alf_, between Qt 5.2 and 5.3 QML ShaderEffect component stopped working | 12:40 |
| Saviq | alf_, but only on Mir+android | 12:40 |
| Saviq | alf_, Mir+desktop and X11 are fine | 12:40 |
| Saviq | not sure about SF+android, but I doubt it | 12:40 |
| davmor2 | sil2100: what image do you want testing and when? | 12:44 |
| alf_ | Saviq: ok, I will look at the gl traces to see if I can find a hint there. How can I try Qt 5.3? | 12:44 |
| Saviq | alf_, see the description | 12:44 |
| Saviq | alf_, it's all in ppa:canonical-qt5-edgers/qt5-beta2 | 12:44 |
| Saviq | alf_, just dist-upgrade from there and you'll see what's happening | 12:45 |
| Saviq | alf_, thanks, please let me know if you need any more data from us | 12:45 |
| === sil2100_ is now known as sil2100 | ||
| alf_ | Saviq: should I use latest devel-proposed image? | 12:49 |
| Saviq | alf_, yes | 12:49 |
| === alan_g|lunch is now known as alan_g | ||
| alf_ | Saviq: greyback: Can we in any way change the shaders used by Qt internally? | 12:56 |
| Saviq | alf_, for these cases, yes | 12:56 |
| Saviq | alf_, http://qt-project.org/doc/qt-5/qml-qtquick-shadereffect.html | 12:57 |
| Saviq | alf_, and http://qt-project.org/doc/qt-5/qml-qtquick-shadereffectsource.html | 12:57 |
| alf_ | Saviq: thanks, I want to try a couple of things to see if it makes a difference | 12:58 |
| Saviq | alf_, yeah, just qmlscene http://paste.ubuntu.com/7492386/ and you can change the shader props as you please | 12:59 |
| Saviq | alf_, do you need to see the default shaders used? | 12:59 |
| alf_ | Saviq: I want to change some bits in the default shaders so I guess I need to override them completely | 13:01 |
| Saviq | alf_, yeah, but you can see the default shaders in the trace or something? | 13:01 |
| Saviq | alf_, if not, you could probably print them: | 13:01 |
| greyback | alf_: yeah the shaders that Qt has internally are hardcoded in, but they can be overridden with some work (without patching qt itself) | 13:02 |
| Saviq | Console.onCompleted: console.log(vertexShader) | 13:02 |
| Saviq | or so | 13:02 |
| Saviq | greyback, in our case we're using ShaderEffect anyway | 13:02 |
| alf_ | Saviq: greyback: I can see them in the apitrace logs, I will print them out to be sure and then override them to try some things | 13:03 |
| Saviq | alf_, thanks! | 13:03 |
| greyback | Saviq: right, but other shaders are being generated & used by the scenegraph too. Those are harder to change | 13:03 |
| Saviq | kgunn, ↑ we stole alf_ to help with https://bugs.launchpad.net/unity8/+bug/1321189 | 13:03 |
| ubot5 | Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged] | 13:03 |
| Saviq | greyback, yeah, but we're not seeing problems with those actually | 13:03 |
| kgunn | Saviq: perfect! | 13:03 |
| Saviq | greyback, i.e. the only place where we identified an issue are ShaderEffects atm | 13:04 |
| Saviq | although now I just saw system settings pages are empty, too, not sure where that comes from | 13:05 |
| anpok | Saviq: why is the ubuntu icon visible? | 13:22 |
| anpok | it is also part of the launcher? | 13:23 |
| anpok | is there are subtle difference like - it has no alpha channel? | 13:23 |
| === pete-woods is now known as pete-woods-lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === ValicekB_ is now known as ValicekB | ||
| === dandrader|afk is now known as dandrader | ||
| Saviq | anpok, it's not shaded | 14:31 |
| Saviq | anpok, the ubuntu icon is just displayed, the other ones are put through a shader | 14:32 |
| anpok | ok | 14:34 |
| mterry | anpok, poke! Do you have some minutes to help me profile Mir CPU usage in the split greeter? | 14:40 |
| * mterry is unfamiliar with profiling mir like that | 14:40 | |
| anpok | do you want to come up with some numbers.. or figure out what mir is doing/spending time on? | 14:44 |
| === pete-woods-lunch is now known as pete-woods | ||
| mterry | anpok, figure out what mir is spending time on. I see about 9% idling | 15:13 |
| === ted is now known as tedg | ||
| alf_ | tsdgeos: Hi! Any hints about building qt components easily for phone debugging? e.g. I want to rebuild lib5QtOpenGL with debug info and custom debugging code to investigate the transition to Qt 5.3 issue | 15:41 |
| tsdgeos | alf_: not much hint, i'd say get the qtbase package and then qmake += DEBUG in the opengl folder | 15:43 |
| tsdgeos | and make | 15:43 |
| tsdgeos | wait a bit | 15:43 |
| tsdgeos | and then some LD_LIBRARY_PATH magic | 15:43 |
| tsdgeos | and hope it all works :D | 15:43 |
| tsdgeos | it's what i usually do so it should work | 15:44 |
| alf_ | tsdgeos: can I select to build only e.g. lib5QtOpenGL to gain some time? | 15:44 |
| alf_ | tsdgeos: ah, sorry missed the "in the opengl folder" | 15:44 |
| tsdgeos | alf_: that should work yes | 15:44 |
| alf_ | tsdgeos: thanks | 15:44 |
| tsdgeos | if not | 15:44 |
| tsdgeos | just configure on the toplevel | 15:45 |
| tsdgeos | make for a bit so that qmake and stuff is build | 15:45 |
| tsdgeos | and then do enter the opengl dir and make there | 15:45 |
| tsdgeos | it's a bit more manual | 15:45 |
| tsdgeos | but should also work | 15:45 |
| alf_ | Saviq: greyback: I am going to investigate the Qt5.3 issue deeper tomorrow, there have been some important changes in the way Qt5.3 handles gl contexts | 15:57 |
| alf_ | Saviq: greyback: I will keep you posted | 15:57 |
| anpok | mterry: have you already just tried enabling logs/lttng traces | 16:13 |
| anpok | if they dont show up things we need to add further reports/traces | 16:13 |
| mterry | anpok, I haven't yet no | 16:14 |
| mterry | anpok, I'll re-acquaint myself with how ;) | 16:14 |
| anpok | bbiab, whats the silo again? I think I still have it configured | 16:14 |
| mterry | anpok, 002 | 16:14 |
| anpok | ok | 16:14 |
| mterry | anpok, yeah if you have time, would love a more knowledgeable look (I think it's Mir-related, but not 100% on that -- I took out everything interesting the greeter was doing and we still spun 10% of cpu) | 16:15 |
| greyback | alf_: thanks! | 16:16 |
| === dandrader is now known as dandrader|lunch | ||
| === alan_g is now known as alan_g|EOD | ||
| anpok | mterry: re, grabbing some food now then will have a look too.. | 17:19 |
| anpok | alf_: hm im seem to be confused by how asio uses timers | 17:19 |
| anpok | i tried to reduce timing related problems with the advanceable fake clock - so i run the main loop in a separate thread, schedule timers, then advance the clock, poke on the main loop by enqueing an action | 17:20 |
| anpok | but it seems like the timers are handled independent of any posts on the asio io_service | 17:21 |
| anpok | i assumed that after a post it would check the amount of time passd since last call and recalc sleep time / execute expired timers.. | 17:21 |
| anpok | maybe I need to look into a different file for some time | 17:22 |
| === dandrader|lunch is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| anpok | mterry: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002/ <- this one? | 18:17 |
| anpok | the spinner is gone? | 18:19 |
| mterry | anpok, yeah, it'll land separately | 18:19 |
| mterry | anpok, you should see almost no visible differences (indicators in greeter will be a little different though) | 18:19 |
| anpok | which process is spinning too much? | 18:20 |
| mterry | anpok, unity8-greeter | 18:20 |
| mterry | anpok, I'm not sure why. Both it and unity8 have the same basic code. They are both nested Mir servers | 18:21 |
| mterry | anpok, but only the greeter executable has this problem | 18:21 |
| mterry | anpok, I tried removing all the qml it loads, same problem | 18:21 |
| anpok | ah now i see what you mean it seems to stay with 9% cpu | 18:24 |
| anpok | together siwth sensors .. and Binder_2 | 18:24 |
| mterry | anpok, yeah. Bounces between 7-10 usually | 18:24 |
| mterry | anpok, I assumed those were unrelated, but maybe they aren't... | 18:24 |
| anpok | but it did not happen when i first looked .. i mean it started after a few logins | 18:26 |
| anpok | ok still behaves like that after reboot | 18:29 |
| AlbertA | we need a plan to deal with stale frame content | 19:00 |
| AlbertA | during display off/on scenarios | 19:00 |
| AlbertA | now that the 1Hz branch has landed | 19:01 |
| AlbertA | the old flash of old content issue is back | 19:01 |
| kgunn | AlbertA: this proves i didn't understand what its doing | 19:05 |
| AlbertA | kgunn: well now the "rendering" rate of a client will be 1Hz after power off | 19:05 |
| AlbertA | kgunn: and since the lifecycle kicks in at around 3s | 19:05 |
| AlbertA | kgunn: there's only around 3 frames drawn | 19:06 |
| AlbertA | kgunn: not enough to show the greeter | 19:06 |
| kgunn | but can't we grow the hz to be something more like 10 hz ? | 19:06 |
| AlbertA | kgunn: we could yes, but I think we need a plan to properly address the issue | 19:06 |
| kgunn | i never understood why we were picking 1 hz | 19:07 |
| AlbertA | kgunn: I'm not sure if you can get more granularity out of the timer | 19:07 |
| kgunn | its not _that_ much power savings | 19:07 |
| AlbertA | kgunn: maybe we can...not sure | 19:07 |
| kgunn | AlbertA: we should...i remember whining about this to alf & RAOF | 19:08 |
| AlbertA | kgunn: wait we should, 1HZ is a second | 19:08 |
| kgunn | e.g. i thot you'd potentially see glitches | 19:08 |
| kgunn | for things that are rendering off a clock | 19:08 |
| kgunn | or animated | 19:08 |
| AlbertA | kgunn: also the volume key during music playback will be a bit laggy | 19:09 |
| kgunn | in occluded cases, getting revealed quickly | 19:09 |
| kgunn | yes | 19:09 |
| AlbertA | kgunn: but I don't know if it was like that before | 19:09 |
| kgunn | that was the other thing | 19:09 |
| kgunn | no | 19:09 |
| kgunn | well | 19:09 |
| kgunn | it was totally blocked before :) | 19:09 |
| AlbertA | kgunn: I mean with the old solution | 19:09 |
| kgunn | AlbertA: no, not laggy at all...e.g. its runnnig off the 60 hz panel vsync effectively | 19:10 |
| kgunn | imho, our time should be as close to panel vsynch as possible | 19:10 |
| kgunn | AlbertA: and we need to fix that before we promote...that regresses a definite improvement | 19:11 |
| AlbertA | kgunn: well the policy is overridable | 19:11 |
| kgunn | i'll file a bug | 19:11 |
| AlbertA | kgunn: so usc can implement a different timeout | 19:11 |
| AlbertA | kgunn: but the right thing is to consider the lowest display refresh rate we are connected to | 19:11 |
| AlbertA | kgunn: and only enable the policy during display off/occlusion | 19:12 |
| kgunn | yes | 19:12 |
| AlbertA | kgunn: unless we want to drop frames due to compositor taking longer than usual (gpu load or whatever) | 19:12 |
| AlbertA | kgunn: which we probably don't want | 19:13 |
| anpok | mterry: it does not seem to render - still investigating (non invasively) | 19:14 |
| mterry | anpok, ok good | 19:14 |
| mterry | anpok, I caught it via gdb, which wasn't very helpful backtrace wise, but did show more threads than I expected | 19:15 |
| mterry | by caught I just mean I attached to it with gdb | 19:15 |
| kgunn | AlbertA: if you wanted to add anymore color | 19:17 |
| kgunn | https://bugs.launchpad.net/mir/+bug/1321886 | 19:17 |
| ubot5 | Ubuntu bug 1321886 in Mir "[regression] stale frame on seen on greeter when screen is unblanked" [Critical,New] | 19:17 |
| AlbertA | mterry: when you get a chance weigh in in this enhancement: | 19:22 |
| AlbertA | mterry: https://bugs.launchpad.net/mir/+bug/1318852 | 19:22 |
| ubot5 | Ubuntu bug 1318852 in Mir "[enhancement] support proper per-pixel alpha for alpha-enabled display framebuffers" [Medium,New] | 19:22 |
| mterry | AlbertA, noted | 19:22 |
| AlbertA | mterry: have you checked the alpha values you currently get? Because from what anpok and I discussed | 19:22 |
| AlbertA | mterry: with the prev version of mir you will get alpha^2 behavior | 19:23 |
| mterry | AlbertA, all I've tried to so far is alpha=0 | 19:23 |
| AlbertA | mterry: I see... | 19:23 |
| === cyphermox_ is now known as cyphermox | ||
| anpok | AlbertA: i right now only look for load.. | 19:35 |
| AlbertA | anpok: ? | 19:36 |
| anpok | ah ... didnt see your premultiplied alpha MP | 19:37 |
| AlbertA | anpok: mterry: did you already check top with the per thread statistics? | 19:38 |
| mterry | AlbertA, 'H' mode? It doesn't seem to provide much insight | 19:41 |
| mterry | anpok, memory use seems high too | 19:41 |
| === dandrader is now known as dandrader|afk | ||
| mterry | I'm trying to set MIR_SERVER_INPUT_REPORT=log for the greeter, but it doesn't output anything. Setting it for unity8 woks, but not for the greeter executable. Does anyone have any idea why that might be? | 20:43 |
| mterry | anpok, you still around / any success? | 20:51 |
| josharenson | kgunn, if you checkout the glmark spreadsheet (https://docs.google.com/a/canonical.com/spreadsheets/d/1aYbyh3BTVzjcxE1dO2IBEEtFbEDLeaEY-sqopkyM-uQ/edit?usp=sharing) you will see the last tab is graphs of performance over time.. currently filled with sample data | 20:52 |
| josharenson | kgunn, I have a script that will run as a cronjob on some ubuntu cloud instance that will pull artifacts from jenkins, parse them, and update those graphs daily (or however often you want) | 20:52 |
| josharenson | kgunn, to hold us over till there is a proper website of course.... | 20:53 |
| anpok | mterry: you have to pipe stdout somewhere .. | 21:04 |
| mterry | anpok, it gets saved in /var/log/lightdm/mir-greeter.log | 21:04 |
| anpok | mterry: thats what I thought too.. | 21:08 |
| mterry | anpok, if I choose lttng, where does that logging go? | 21:09 |
| anpok | but writing it to a different file worked.. | 21:09 |
| mterry | anpok, really? | 21:10 |
| anpok | yeah | 21:10 |
| mterry | anpok, yup.. odd | 21:12 |
| anpok | wrt lttng you can create traces with eclipse and it will be stored somewhere in tmp or you create a session using the lttng tools.. | 21:12 |
| mterry | anpok, "android-input: [InputDispatcher]Dropping event because there is no focused window or focused application." | 21:13 |
| mterry | anpok, does android have its own idea of where input should be focused vs mir's idea? | 21:14 |
| racarr__ | mterry: Sort of, see: the_input_target_selector | 21:19 |
| racarr__ | the default focus mechanism, makes the default surface of the focused sessio | 21:19 |
| racarr__ | n | 21:19 |
| racarr__ | the input target | 21:19 |
| racarr__ | (whom then receives all key events) | 21:19 |
| * mterry takes a dinner break | 21:27 | |
| kgunn | josharenson: awesome! | 21:42 |
| kgunn | seriously... | 21:42 |
| josharenson | kgunn, the data is obviously fake for now... but should be a solid band-aid | 21:42 |
| kgunn | josharenson: hey, so for the data you did run...is it right to compare ubuntu-offscreen to the android-onscreen run ? | 21:43 |
| josharenson | kgunn, with the frame dropping enabled, it seems fare | 21:44 |
| josharenson | fair* | 21:44 |
| kgunn | josharenson: so ubuntu-frame-drop vs android-onscreen ? | 21:45 |
| kgunn | i mean...yeah | 21:45 |
| kgunn | i see that it technically would be the closest thing | 21:45 |
| josharenson | kgunn, yes | 21:45 |
| kgunn | but wow... | 21:45 |
| kgunn | we kick the shit out of surface flinger | 21:45 |
| josharenson | I think alberta had a good explination for that... | 21:45 |
| kgunn | binder ? | 21:45 |
| josharenson | kgunn thats 1 part | 21:45 |
| kgunn | wow...binder really creates that much traffic jam? | 21:46 |
| kgunn | stil | 21:46 |
| josharenson | kgunn, if we are just a few ms faster, it could help substantially | 21:46 |
| josharenson | kgunn also | 21:46 |
| josharenson | kgunn the compositor | 21:46 |
| josharenson | kgunn, thinking.. I know there is something there... the numbers might not actually be so far | 21:47 |
| josharenson | fair* | 21:47 |
| * josharenson can't spell fair, need more coffee | 21:47 | |
| kgunn | fare | 21:47 |
| kgunn | fair | 21:47 |
| kgunn | :) | 21:48 |
| kgunn | fart | 21:48 |
| kgunn | josharenson: yeah...ok, it does make those tests where SF is "better" then mir come much more into line in terms of comparison | 21:48 |
| josharenson | kgunn, I have a good explination logged in my chats somewhere... I'm looking for it | 21:49 |
| AlbertA | josharenson: kgunn: right, take 393 vs 292 = 2.54 ms vs 3.42 ms | 21:50 |
| AlbertA | josharenson: kgunn: I totally buy that being binder overhead | 21:50 |
| josharenson | ^^that | 21:50 |
| kgunn | yeah...true... | 21:52 |
| kgunn | i forget the massive numbers have an illusion | 21:52 |
| kgunn | converting into ms...not so bad | 21:52 |
| josharenson | kgunn, I guess the best test is mir vs mir.... 2nd best test is mir vs sf with frame dropping enabled | 21:53 |
| josharenson | kgunn, linaro _could_ make android offscreen happen, but, as we've discussed, its not really of value.. just let me know what you want to see in that spreadsheet.. its not so hard to change things... | 21:54 |
| kgunn | so i'm in column R & S for you looky loos | 21:54 |
| kgunn | josharenson: yeah...i guess the mir w/ frame drop vs SF is as close as we're gonna get | 21:54 |
| kgunn | its interesting, they still beat us on a handful | 21:55 |
| AlbertA | I'd wager that's our hybris overhead...they are probably gl call heavy | 21:55 |
| josharenson | kgunn, also, the current test only shows overall score.... getting all the info from the actual mir test is easy, but putting it all in the spreadsheet would take a little work (hours, not days) | 21:56 |
| kgunn | AlbertA: eh, not so sure... | 21:58 |
| kgunn | i mean, they beat us on kind of "lower frame rate" | 21:58 |
| kgunn | granted gl calling might be higher | 21:58 |
| * camako thinks the differences are too big... | 21:58 | |
| kgunn | but gpu load itself is higher | 21:58 |
| camako | things should be gpu bound, no? | 21:58 |
| kgunn | camako: some are | 21:59 |
| kgunn | i suspect | 21:59 |
| kgunn | like jellyfish, terrain | 21:59 |
| camako | so we should get more or less the same framerate | 21:59 |
| camako | but CPU, and mem bw should differ by a lot | 21:59 |
| kgunn | camako: right...in about 1/2 the cases...the other 1/2 they're beating us by 20% | 21:59 |
| AlbertA | kgunn: camako: I suppose it depends on the gl call rate | 21:59 |
| kgunn | AlbertA: would hybris really add overhead perse ? isn't it just a function redirect? | 22:00 |
| AlbertA | kgunn: camako: could be a combination of decreasing gpu load with hwc + hybris overhead | 22:00 |
| kgunn | agreed on the hwc | 22:00 |
| kgunn | that could be it | 22:00 |
| kgunn | or a portion | 22:00 |
| AlbertA | kgunn: right if we had a sense of the gl call rate we could speculate better | 22:01 |
| camako | So we don't have hwc fully enabled? | 22:01 |
| * kgunn wishes we had something like pvrtune for adreno | 22:01 | |
| AlbertA | kgunn: that would be higher fps I guess where it would show up | 22:01 |
| kgunn | kdub_: ^ anything like that exist? adreno-load-inspector ? | 22:02 |
| AlbertA | camako: not currently no | 22:02 |
| kdub_ | there's a bunch of /sys stuff | 22:02 |
| camako | isn't this all going through hwc on Android? | 22:02 |
| camako | I mean overlays? | 22:02 |
| kgunn | AlbertA: @higher framerate where it would show up...you mean hybris ? | 22:02 |
| AlbertA | kgunn: right | 22:02 |
| kgunn | AlbertA: right...so its counter the theory :) | 22:03 |
| kgunn | we kick the crap out of them | 22:03 |
| camako | kgunn, doesn't make sense to me | 22:03 |
| camako | they should be beating us by a large margin | 22:03 |
| camako | with overlays | 22:03 |
| AlbertA | kgunn: heheh.... have you looked at percentages in millisecs? | 22:03 |
| AlbertA | camako: well....it's only one surface though... | 22:04 |
| AlbertA | camako: so I suppose the recomposite overhead? | 22:04 |
| josharenson | camako, yeah I've only ran fullscreen tests | 22:04 |
| AlbertA | camako: which surface flinger wouldn't have since it would just send the surface straight to hwc | 22:04 |
| AlbertA | camako: we don't do that yet...kdub is working on it :) | 22:05 |
| kdub_ | camako, right :) | 22:06 |
| kdub_ | we can see in malta though | 22:06 |
| * camako thinks something is not right | 22:07 | |
| camako | their system is much better optimized.. | 22:07 |
| kdub_ | eh, also like hwc is sometimes power optimized | 22:07 |
| AlbertA | oh yeah.... | 22:07 |
| AlbertA | josharenson: did you fix up the cpu governor for this tests? | 22:08 |
| camako | so again why are we seeing higher numbers? | 22:08 |
| AlbertA | we could be seeing a case where the cpu was bumped to a higher Hz due to higher load :) and we end up better | 22:08 |
| kdub_ | well, sometimes its even more than the governor | 22:08 |
| camako | AlbertA, cpu shouldn't matter, it's a lot of gpu and mem bw | 22:09 |
| camako | or rather, it should be.. | 22:09 |
| AlbertA | camako: for the high fps it would | 22:09 |
| josharenson | alberta, no.... | 22:09 |
| AlbertA | camako: since they don't seeem particularly gpu bound | 22:09 |
| josharenson | alberta, like force max? | 22:10 |
| AlbertA | josharenson: usually we set it to performance | 22:10 |
| josharenson | albera, that will only help our results | 22:10 |
| AlbertA | josharenson: not necessarily, I mean if you have root access on android, | 22:10 |
| AlbertA | josharenson: you do the same there | 22:10 |
| camako | AlbertA: dunno specifics of these tests but generating gl commands is not CPU intensive... But it could be mem intensive... | 22:11 |
| josharenson | alberta, ok I'll rerun at some point... How does out power management policy compare to android? | 22:11 |
| AlbertA | josharenson: should be the same kernel | 22:11 |
| AlbertA | josharenson: so same governors | 22:12 |
| josharenson | cak | 22:12 |
| josharenson | ack* | 22:12 |
| AlbertA | camako: but it could be in the threshold of switching cpu modes | 22:12 |
| AlbertA | camako: i.e. if android has lower cpu usage it could have switching to a lower mode therefore spending more cpu % | 22:12 |
| kgunn | AlbertA: thanks for bringing up cpu goveners...totally forgot | 22:13 |
| camako | AlbertA: does it make mem bw? | 22:13 |
| kdub_ | there's a lot of fun switches to push :) | 22:13 |
| camako | AlbertA: does it make mem bw higher?? | 22:13 |
| kgunn | camako: no | 22:13 |
| AlbertA | camako: it could there's complex interplay there with the cores | 22:13 |
| kgunn | camako: well at least at ti, those were seperate | 22:13 |
| AlbertA | camako: not higher | 22:13 |
| AlbertA | camako: lower | 22:13 |
| kgunn | ok guys...i'm gonna run | 22:14 |
| kgunn | family calling...back after a while | 22:14 |
| AlbertA | camako: the scenario would be lower clock in android leading to lower total fps | 22:14 |
| camako | AlbertA: yes, I meant for us... | 22:14 |
| AlbertA | camako: and mir could have higher cpu load leading to slightly higher fps since it's running at a higher clock rate | 22:14 |
| AlbertA | camako: we won't know for sure unless we fixed the clock rate on both scenarios | 22:15 |
| josharenson | ill run at performance | 22:15 |
| camako | AlbertA, cpu is not doing the heavy lifting... so lower/higher doesn't matter... | 22:16 |
| AlbertA | camako: I'm not so sure in the cases where we are getting high fps | 22:16 |
| camako | cpu can saturate mem and/or gpu very easily at low cpu % | 22:16 |
| AlbertA | camako: we are talking about 1ms differences there | 22:16 |
| AlbertA | camako: very well could be cpu clock rates | 22:16 |
| AlbertA | camako: in the low fps cases...that could be mir's compositor overhead over SF | 22:17 |
| camako | AlbertA, I guess I am having a hard time believeing cpu is the bottleneck here | 22:18 |
| AlbertA | camako: not a bottleneck but a load low enough that in android it kicked the cpu to a lower state | 22:18 |
| camako | AlbertA, now we don't have full hwc, I guess things'll make more sense when it's more apples-to-apples | 22:20 |
| camako | AlbertA, to me Android is operating at a much lower mem bandwidth (interconnect freq) than mir | 22:21 |
| AlbertA | camako: right we can't make accurate comparison with a dynamic clock rate basically | 22:21 |
| camako | A simple mem test should discover any discrepancy | 22:21 |
| AlbertA | camako: I mean we saw that all the time in OMAP | 22:21 |
| AlbertA | camako: the data doesn't end up making a lot of sense...and sometimes cpu governors are also tied | 22:22 |
| AlbertA | to other ip blocks | 22:22 |
| camako | I guess it'd make more sense to me if cpu governor does affect mem bw | 22:23 |
| kdub_ | yeah, it sounds like something I would have seen in the adreno world too | 22:23 |
| kdub_ | and also, I thought it could hold the mem bw high if its set to performance | 22:23 |
| racarr__ | kgunn: Hey...so...the deeper I get the more things I find I have to disentangle for glamor....its relatively coupled to GBM/DRM+Client buffer allocation+Mesa EGL... | 22:24 |
| racarr__ | im developing a plan but I think I would be pretty lucky to get anything working in the next few days | 22:24 |
| racarr__ | so maybe I should reprioritize? | 22:24 |
| kgunn | racarr__: is glamor a hard requirement for libreoffice? | 22:25 |
| racarr__ | kgunn: No. only for it to not be slow on mobile devices. | 22:25 |
| kgunn | racarr__: mmm...i'm being summoned again by the wife...so is doing a demo of libreoffice w/o glamor cheap in terms of effort? | 22:27 |
| racarr__ | on the desktop yes...unless we want menus to work in hich case it grows in to a bit of | 22:27 |
| racarr__ | a project | 22:27 |
| kgunn | racarr__: might have a chat with RAOF when he's on...i gotta run...i kind of feel like yeah...i mean desktop is the target w/ | 22:28 |
| kgunn | menus of course | 22:28 |
| kgunn | ok...back later | 22:28 |
| racarr__ | ttyl! | 22:28 |
| racarr__ | thanks | 22:28 |
| racarr__ | RAOF: Ping? | 22:28 |
| === Trevinho_ is now known as Trevinho | ||
| === Sarvatt_ is now known as Sarvatt | ||
| RAOF | racarr__: Yo! | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!