| bryce | heya michaellarabel | 00:02 |
|---|---|---|
| michaellarabel | Hi bryce | 00:02 |
| bryce | michaellarabel: thanks again for those charts, I had *just* been lamenting the lack of solid results for changing migration code, before I noticed your charts in my inbox | 00:03 |
| bryce | michaellarabel: by chance have you done a comparison of EXA Greedy vs. Option "EXAOptimizeMigration" "off" ? | 00:04 |
| michaellarabel | Heh, that's actually what I have running at this very minute that will be appended to the other charts. | 00:04 |
| bryce | I'm wondering if they both provide equivalent performance benefits? It sounds like the latter may avoid some of the corruption issues that greedy carries. | 00:04 |
| michaellarabel | Then on another system, I am running it with 2.6.30-rc2, libdrm 2.4.9, and bisecting the Intel Git to try to narrow down the perf regressions some more. | 00:05 |
| bryce | sweet | 00:07 |
| michaellarabel | bryce: I think testing might just be about done with EXAOptimizeMigration off. | 01:20 |
| jbarnes | <jbarnes> for 945 there are really 3 big perf fixes: a17 swizzle, mchbar alloc, and execbuf fencing | 01:30 |
| jbarnes | michaellarabel: ^^ from before you joined | 01:30 |
| bryce | jbarnes: all three of those are in 2.6.30-rc2 right? | 01:30 |
| jbarnes | mchbar alloc isn't yet | 01:31 |
| bryce | ok | 01:31 |
| jbarnes | just refreshed that one yesterday... had to separate out some code for license reasons | 01:32 |
| michaellarabel | bryce: Just sent you the "XAOptimizeMigration off results. | 01:34 |
| michaellarabel | EXAOptimizeMigration* | 01:34 |
| bryce | cool, looking | 01:35 |
| bryce | so far I've heard only one problem with greedy in xorg.conf - firefox black screen corruption | 01:36 |
| bryce | unfortunately the person who found it is our release manager (i.e. the guy that decides whether any changes to jaunty can go in) | 01:36 |
| michaellarabel | and jbarnes: vol 4 of the new documentation is 404 on Intel site - http://intellinuxgraphics.org/Vol_4_G45_subsystem.pdf | 01:37 |
| jbarnes | michaellarabel: oops, I'll ping those involved | 01:38 |
| michaellarabel | and bryce would it help if you had the 2.6.30-rc2 results for all of those test runs or were just the few from the other one good enough? | 01:41 |
| bryce | I'd love to see the full set | 01:43 |
| michaellarabel | Okay, I'll run the full set on the new kernel. | 01:44 |
| bryce | if there's sufficient space to fit them all | 01:44 |
| michaellarabel | it will automatically make room on the graphs, just getting a bit scrunched but will scale to fit room. | 01:44 |
| bryce | I assume the kernel fixes will have across-the-board performance benefit by N%, but it's entirely possible the improvements help in some configurations but not in others. | 01:44 |
| michaellarabel | bryce: Just normal EXA would you like on 2.6.30-rc2 for the full set or which options? | 01:45 |
| bryce | e.g., the kernel performance improvements may not show up in EXA greedy, thus making that option less attractive. | 01:45 |
| bryce | I'd like to see the exa no migration the most I think | 01:47 |
| bryce | unless there is a big difference between that and exa greedy | 01:47 |
| michaellarabel | I can easily run both, but will start with EXA and no special options. | 01:47 |
| bryce | great | 01:48 |
| bryce | wow, EXAOptimizeMigration Off bites | 02:18 |
| bryce | seems to be little different than no change except on a couple tests | 02:19 |
| bryce | michaellarabel: that 'JXRenderMark Transformed Blit Bilinear' test looks wacked | 02:19 |
| michaellarabel | bryce: PTS usually runs each test three times or so depending upon the profile etc, so it should be accurate. though I can look into it further to see if something weird is going on in that test. | 02:21 |
| bryce | michaellarabel: it's just curious that nomigration gives such huge OPS. I don't know what that test is measuring exactly, but the difference between that and EXA Greedy is huge and seems a bit suspicious | 02:24 |
| bryce | like... I wonder if nomigration is bailing out and refusing to do the operation or something | 02:25 |
| bryce | in any case, this has convinced me to dust off the greedy patch and try to get it into shape for shipping. Dunno if we can convince slangasek to accept it, but looks like it's worth giving it a go. | 02:26 |
| michaellarabel | I know the developer of JXRenderMark and will ask him next time I see him in my forums or on IRC. | 02:26 |
| bryce | cool | 02:26 |
| bryce | I'd also be interested in hearing which JXRenderMark tests will most closely relate to real world user work (e.g. ones that would correlate to various compiz effects or whatnot) | 02:27 |
| michaellarabel | Okay | 02:29 |
| bryce | whoa, greedy migration is terrible on my laptop | 02:42 |
| bryce | also I am getting major corruption (black shadows). weird | 02:43 |
| michaellarabel | what chipset is your laptop using? I hadn't experienced any corruption on the 945 with the Atom netbook nor on another 945-based desktop. | 02:49 |
| cwillu | you're on 965 aren't you? | 03:09 |
| michaellarabel | bryce: Just sent with 2.6.30-rc2 kernel in there... It's looking good. | 03:10 |
| bryce | yes, I'm on i965 | 03:13 |
| bryce | dell 1420, pretty bog standard i965 | 03:13 |
| michaellarabel | I think I have system each of 915, 945, 963, 965, G35, G43, G45. Though I highly doubt I would have time to run all of the tests. | 03:16 |
| bryce | EXA vs. EXA Greedy seems like the two to test | 03:17 |
| bryce | later on, a UXA vs. EXA multi-chip rundown would be interesting, but UXA in jaunty just isn't stable enough to consider yet | 03:18 |
| bryce_ | sorted the black border issue I had. Was just an incomplete mesa upgrade | 05:52 |
| bryce_ | was just an incomplete upgrade. last time it froze was in the middle of an upgrade | 05:53 |
| bryce_ | running "greedy" now and there's no prob | 05:54 |
| Mirv | bryce_: no I didn't need 102/104 disabled, I just disabled those all three before it was certain it's the max texture patch. | 06:48 |
| Mirv | tjaalton: ok, without problems so far even without the vblank patch | 06:48 |
| Mirv | I could run another build with just 103 disabled and use that now | 06:49 |
| Mirv | though I guess for 965G it's quite clearish anyway that its problems go away by disabling that patch now | 06:55 |
| bryce_ | :-) | 06:56 |
| bryce_ | well, the more verification the better... we're going to have to SRU the fix, so that demands pretty thorough testing be done | 06:57 |
| Mirv | ok, going to do another build and use just with 103 disabled from now on | 07:01 |
| tjaalton | Mirv: so you've tried vt changes and suspending with vblank? | 07:04 |
| Mirv | tjaalton: well vt changes only now (seems to work multiple times), but suspending maybe 5 times now | 07:06 |
| tjaalton | ok, those used to mess things up, making it very slow | 07:07 |
| tjaalton | I guess mesa 7.4 fixed that | 07:07 |
| Mirv | cube is still purring | 07:07 |
| Mirv | maybe | 07:07 |
| maxb | window level all | 07:50 |
| bryce_ | feh. with 7.4 sans patch 103, I've gotten 3 freezes in as many hours | 09:04 |
| bryce_ | tjaalton: reverting 103 doesn't seem to solve it. | 09:05 |
| Mirv | hmm, I'm still running the one from two hours ago, but the day is young still. it couldn't be the vblank patch? | 09:20 |
| Mirv | it's so annoying things seem so random | 09:20 |
| tjaalton | bryce_: are you sure? | 09:27 |
| tjaalton | I've reverted both 103 and 104 and it's been as stable as before | 09:29 |
| Mirv | I've already completed stuff I wasn't able to do when 103 was active. I'd hope bryce would just have some old library in use or something ;) Or X not restarted completely so that libraries would be reloaded, or... | 09:29 |
| tjaalton | bryce_: double-check that libgl1-mesa-dri is the version without that patch.. | 09:30 |
| Mirv | or, running a build from the same source directory so that 103 was already applied before it was disabled | 09:30 |
| Mirv | (I always take a fresh apt-get source mesa before building a new one, and remove the patch in addition to removing it from series) | 09:31 |
| bryce_ | come now guys, give me some credit, I'm not a complete moron ;-) | 09:36 |
| bryce_ | half maybe... | 09:36 |
| tjaalton | hehe | 09:36 |
| bryce_ | yes, I triple checked that the mesa was correct, did a re-upgrade and reinstalled 3 times | 09:37 |
| bryce_ | all three freezes occurred when alt-tabbing | 09:38 |
| tjaalton | using greedy? | 09:38 |
| bryce_ | yes | 09:38 |
| tjaalton | I'm not :) | 09:38 |
| bryce_ | ok | 09:39 |
| tjaalton | maybe it has something to do with it | 09:39 |
| bryce_ | yes that could be | 09:39 |
| bryce_ | all 3 freezes occurred only since switching to greedy | 09:39 |
| bryce_ | mm | 09:40 |
| bryce_ | god how I hate -intel | 09:40 |
| tseliot | bryce_: do you want -psb instead? | 09:40 |
| tseliot | :-P | 09:40 |
| * bryce_ runs screaming | 09:40 | |
| tseliot | hehe | 09:40 |
| bryce_ | next you'll be offering me -nv or something ;-) | 09:40 |
| tseliot | yes, that would be my 2nd choice | 09:41 |
| bryce_ | ok, rebooting sans-greedy. brb | 09:41 |
| Mirv | not using greedy either | 09:44 |
| bryce_ | I suppose it's useful to know these two things intefere before we roll them out... | 09:46 |
| bryce | nope | 10:19 |
| bryce | still froze up, even with greedy removed | 10:19 |
| bryce | 4th time freezing with alt-tab | 10:20 |
| bryce | also, it seems to be reproduced reliably, freezing after 30-60 min use | 10:20 |
| bryce | alt-tab seems to grow slower over time leading up to the freeze | 10:21 |
| bryce | night. | 10:25 |
| Mirv | hmm, not seeing anything like that, weird | 10:31 |
| michaellarabel | bryce: Running 2.6.30 + 2.7 -intel with both EXA and UXA and will have those results soon | 12:21 |
| Mirv | michaellarabel: that's exciting! :) | 12:36 |
| michaellarabel | Mirv: I think these results might be surprising. Watching the screen, it looks like there are still some massive slowdowns. | 13:45 |
| cwillu | wirechief in #ubuntu+1 is reporting that mesa 7.4-0ubuntu2~bug359392~1 makes his crashes go away on 965 | 13:59 |
| Mirv | tjaalton/bryce: would it be wise to remove the max texture patch anyway if at least me and tjaalton are seeing much better stability? ie. was there any real, tangible benefit of the patch? | 14:06 |
| tjaalton | Mirv: I'm for it | 14:09 |
| tjaalton | it's only to allow compiz when the virtual size is above 2k*2k | 14:14 |
| tseliot | jcristau: any ideas as to why this happens (and including privates.h doesn't solve the problem)? http://pastebin.ubuntu.com/152082/ | 14:22 |
| jcristau | no | 14:23 |
| tseliot | ok, thanks anyway | 14:24 |
| michaellarabel | bryce and Mirv: results for 2.7 and 2.6.30 with EXA and UXA should be in your inbox | 15:14 |
| tseliot | tjaalton: if I wanted to use libdrm 2.3.0 in Jaunty (to use -psb) which part of the kernel should I modify? gpu/drm and include/drm? Is this documented somewhere? | 15:31 |
| tjaalton | tseliot: those should do.. and it's not documented, sounds rather crazy :) | 15:32 |
| tseliot | tjaalton: it *is* crazy ;) | 15:33 |
| jcristau | psb is such a freaking disaster.. | 15:33 |
| tjaalton | yeah.. | 15:33 |
| tseliot | getting it to work is the problem ;) | 15:34 |
| tjaalton | the recent thread on kernel-team@ depicts it perfectly | 15:34 |
| tseliot | hehe | 15:34 |
| tseliot | I read that | 15:34 |
| tjaalton | so they just threw a tarball of new code to be merged to the hardy kernel.. | 15:35 |
| tjaalton | limited audience, but still | 15:35 |
| Mirv | michaellarabel: thanks a lot, indeed interesting | 15:59 |
| tormod | is there any chance of getting radeonhd 1.2.5 as SRU? | 21:53 |
| bryce | tormod: not really; put it in through backports instead | 22:28 |
| bryce | if there are critical fixes, those might be sru-able | 22:28 |
| bryce | (individually) | 22:28 |
| tormod | bryce: bug 359082 is important for r6xx/r7xx so I wondered if one should bother SRU individual fixes | 22:31 |
| ubottu | Launchpad bug 359082 in xserver-xorg-video-radeonhd "radeonhd driver doesn't resume from suspend on r6xx/r7xx" [Undecided,Fix committed] https://launchpad.net/bugs/359082 | 22:31 |
| tormod | since we are not using radeonhd by default it should have more relaxed policy - it should be back in universe maybe | 22:32 |
| bryce | tormod: true, well we can move -radeonhd back there for karmic | 22:33 |
| bryce | tormod: anyway, slangasek is the one who you have to get approval from on sru's | 22:34 |
| bryce | tormod: it's been my experience when asking for version bumps that he tells you to cherrypick out the exact patches you need, rather than bump the whole version | 22:35 |
| bryce | but you're welcome to just ask him directly; maybe he'd make an exception in this case | 22:35 |
| tormod | yes that sounds like standard practice, but radeonhd is there just for testing anyway... | 22:36 |
| bryce | for radeonhd, I'll give my +1 to any solution you and he agree on | 22:36 |
| tormod | hmm a blank check :) | 22:40 |
| tormod | radeonhd is not on the cd right? | 22:42 |
| tormod | (it is not) | 22:44 |
| michaellarabel | bryce: Have you looked at the 2.7 + 2.6.30 performance? | 22:49 |
| bryce | michaellarabel: yeah I saw your article on that, is that what you mean? | 22:50 |
| bryce | sad that there's still problems, but I guess not unsurprising | 22:50 |
| michaellarabel | the link I sent on ubuntu-x this morning, http://global.phoronix-test-suite.com/?k=profile&u=phoronix-31974-10432-20657 | 22:51 |
| bryce | also I keep turning up more reports of regressions when using "greedy" | 22:51 |
| bryce | ah sweet | 22:51 |
| michaellarabel | So what are you looking at doing for Jaunty? | 22:51 |
| * bryce looks | 22:52 | |
| bryce | well, for the jaunty release itself, it is too late to make course corrections, unless we had 99.99% certainty that the option to change would improve performance without causing regressions | 22:55 |
| bryce | so what we've done for now is to at least document the options in the release notes | 22:55 |
| michaellarabel | okay | 22:56 |
| bryce | https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes | 22:57 |
| bryce | one disadvantage to greedy is that it could make it hard to get support from Intel on bugs in the future - see http://bugs.freedesktop.org/show_bug.cgi?id=16773 for example | 22:58 |
| ubottu | Freedesktop bug 16773 in Acceleration/EXA "Broken systray when using "MigrationHeuristic" "greedy"" [Normal,Reopened] | 22:58 |
| bryce | michaellarabel: at this point, my hopes rest mainly on the kernel team being able to sru the appropriate patches from 2.6.30 to jaunty. (But please don't quote me on this.) | 23:00 |
| michaellarabel | Okay. | 23:00 |
| tormod | I read somewhere that Intel will drop EXA soon anyway... I guess no support on EXA from them then. | 23:00 |
| bryce | your tests indicate that those kernel changes bring some relief, and upstream feels them to be the "right" solution, so it seems to me to be the right thing to do | 23:01 |
| bryce | gahh | 23:01 |
| bryce | Intel drops support for legacy stuff far too quickly. | 23:01 |
| tormod | there is not much left between legacy and experimental obviously ;) | 23:02 |
| bryce | I understand their motivations, but it boxes us distros into the corner not having options to work around problems | 23:02 |
| bryce | tormod: bingo | 23:02 |
| bryce | we still have users for whom XAA is the only thing that works ;-) | 23:03 |
| bryce | anyway | 23:03 |
| bryce | at least Intel puts it out as 100% open source | 23:04 |
| jbarnes | yeah it's double edged | 23:04 |
| jbarnes | we clearly can't support everything we have today (as shown by our huge bug count) | 23:04 |
| jbarnes | so unless we drop stuff, nothing will really improve since we'll have no focus | 23:05 |
| bryce | jbarnes: like I said, I understand the motivations, and it makes sense. It just is painful when the new stuff doesn't work yet, to see the current stuff going legacy already. | 23:06 |
| jbarnes | we'll continue to support 2.7 | 23:07 |
| jbarnes | and we'll work to make sure that by the time 2.8 comes out it won't suck | 23:07 |
| tormod | do you intend to clean up UXA and make it stable for everyone before the next *XA ;) | 23:07 |
| jbarnes | that's the intent | 23:09 |
| jbarnes | of course our track record leaves plenty of room for skepticism | 23:09 |
| jbarnes | (trust me I'm pretty frustrated by the current situation too) | 23:09 |
| bryce | sometimes it seems that upstream moves so quickly, that by the time something is stable enough for end users, it's already unsupported by upstream | 23:12 |
| bryce | anyway, now I'm just ranting ;-) | 23:13 |
| jbarnes | yeah, but most of these new features have been in development and planned for quite awhile | 23:13 |
| jbarnes | so hopefully we're not just making stuff up and dropping the old stuff cause it's not shiny anymore :) | 23:14 |
| jbarnes | e.g. gem, kms, dri2 have all been in the works for a long time now | 23:14 |
| superm1 | tjaalton, i'm still having a hard time pushing to git $ git push origin ubuntu | 23:16 |
| superm1 | fatal: The remote end hung up unexpectedly | 23:16 |
| superm1 | can i only push via ssh protocol, and git:// is only for pulling? | 23:17 |
| bryce | superm1: you can switch over to ssh for read/write | 23:17 |
| superm1 | how do I switch the branch over? | 23:17 |
| bryce | no clue | 23:17 |
| bryce | I just do a new checkout | 23:18 |
| superm1 | haha | 23:18 |
| bryce | I think you can fiddle with the config file in .git/ | 23:18 |
| superm1 | i swear some day it'll all just click and i'll understand git | 23:18 |
| bryce | optimist | 23:18 |
| bryce | jbarnes: you know, trying to think about this a little more holistically, it often seems that when upstream feels the new thing is "ready", what they mean is that they feel it is "ready for testers" and want to get bug feedback on any remaining issues | 23:23 |
| bryce | jbarnes: whereas at the distro level, "ready" would mean "ready for end users" with no bug reports needed | 23:24 |
| bryce | in theory, if the former is done sufficiently, the latter should just fall into place | 23:24 |
| bryce | but in practice it seems the two get muddled up | 23:24 |
| bryce | anyway, I dunno, maybe it'll go better in karmic. | 23:25 |
| jbarnes | bryce: yeah definitely | 23:25 |
| jbarnes | (about the two getting muddled up I mean) | 23:25 |
| jbarnes | I'm mainly unhappy with our bug count at this point, and I can only imagine how distros and users feel about it :) | 23:25 |
| jbarnes | my hope is that we'll be able to focus on making fewer code paths more robust | 23:26 |
| superm1 | bryce, yah .git/config has it in plain text. thanks for the pointer. so whenever alioth's cron job runs and gets my ssh key in there, i'll finally be able to push | 23:29 |
| bryce | jbarnes: yeah in fact I've spared you the brunt of our bug load; if I ever get a good solid chunk of time to upstream bugs, I will be bloating your numbers considerably (we're going on 300 bugs now) | 23:34 |
| bryce | (plus bunches more in mesa and xserver that probably should go to intel) | 23:34 |
| jbarnes | yeah I noticed... I troll launchpad and your pages sometimes and I'm a little frightened | 23:35 |
| jbarnes | our fdo bug count is way too high as it is... | 23:35 |
| bryce | part of the reason I've not upstreamed them already, is that the entry bar for -intel in fdo is higher than most of these bugs meet (e.g. needing to test a git version of the driver, needing to set debug flags, capture data from secondary tools, etc.) | 23:37 |
| bryce | in some respects I think having a high entry bar is good in keeping the bug load down | 23:38 |
| bryce | but in other respects, it doesn't mean the bugs don't exist, just that they don't reach you | 23:38 |
| bryce | anyway, what I've been doing on our end is to try and make it easier for users to file bugs that meet the upstream requirements. I hope that will end up helping. | 23:40 |
| jbarnes | yeah that helps a lot | 23:42 |
| bryce | jbarnes: fwiw, of the 280 or so bugs, 20% are upstream now (comparible with the proportion of xserver bugs upstream) | 23:42 |
| jbarnes | cool | 23:43 |
| jbarnes | there's a fairly high dup % upstream too | 23:43 |
| jbarnes | dunno how launchpad is | 23:43 |
| bryce | we tend to try keeping it pretty clean dupe-wise, but often it's hard to say for certain if a given bug is a dupe or not | 23:44 |
| bryce | since for upstreaming bugs there is sort of a "1-issue 1-person" rule, we tend to prefer people not get too aggressive at duping up bugs | 23:45 |
| jbarnes | yeah and when I say dupe I mean "caused by the same thing" not similar symptoms | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!