[01:04] bryce: do you know of cases where glxinfo is extremely slow ? [01:04] like a few mins to run [01:04] stgraber: glxinfo? hmm [01:05] in general glx can be slow to run if software rendering is enabled, but even there glxinfo should be quick [01:05] yeah, it's making the session open time to go up to a few minutes because compiz is calling glxinfo a few times [01:05] no, this is not a bug I've run across so far [01:05] did you find any bugs about it in LP? [01:05] that sounds like something that might happen with a half installed -fglrx? [01:05] that's on an Intel classmate, I believe you're familiar with the hardware ? (a few person at Canonical got one at UDS-Boston) [01:05] oh nvm [01:05] that's with 100% intel hardware :) [01:06] stgraber: no I've not touched the classmate myself [01:10] hmm, I guess I just found the issue, not sure if it's a bug actually. [01:10] glxinfo doesn't work if the current vt isn't X [01:10] so having X start in background, glxinfo doesn't work until I switch to vt7 [01:23] * stgraber notices that the classmate doesn't have a pause/sysrq key ... [05:06] bryce: don't know if tseliot is working on it [05:12] but we're an "all-nvidia" shop :( so I'd be interested in seeing a new bugfix release.. [05:12] (we = HUT) [05:21] tjaalton: ok, well it's been quite a while since I did a -nvidia release. I'd be game to give it a go, though. [05:46] bryce_: yeah, I'm willing to try as well [05:46] got a 8600GT to try it on [05:47] but first the couple of input drivers.. [07:04] bryce_: acecad, aiptek, fpit are now in experimental, elographics, penmount, void pushed to git and waiting for an upload [07:04] excellent [07:16] uploaded mesa with the texture bump to my ppa [07:16] +size [07:21] nice [09:22] * bryce swats a couple more -intel bugs [10:33] bryce: re your ML post, I think "taking on tasks" scares everybody to silence :) [10:35] it's ok, if no one volunteers I have a fallback plan for 8xx. It's just pretty nasty. Want to give 8xx users a chance to help grind grain before I start taking the bread away from them. ;-) [10:38] tjaalton: maybe you can consider 324854 (uxa) for your mesa ppa [11:04] tormod: seems a bit invasive [11:04] and since uxa is not used by default.. [11:04] what's the commit-id? [11:05] nevermind, got it [11:06] ok. if it only would touch uxa code it wouldn't be so bad, but I am not able to judge from the patch [11:07] tormod: thanks for doing the xorg-edgers PPA, it's very handy :) [11:09] Ng: you're welcome :) hope I will get some co-uploaders some time [11:10] tormod: do you happen to know offhand how huge the difference is between -intel 2.6.3 and 2.6.99/git? [11:10] tormod: well, looks like it should affect only DRI2, which means EXA users are safe [11:11] tormod: I promised bryce I'd see if I could figure out what's changed between jaunty's package and yours that makes my 965 much nicer, but if it's going to be thousands of lines of diff then I'm probably going to fail ;) [11:11] Ng: git diff would tell you, but yes, it is quite a lot of code [11:11] git bisect is your friend [11:12] yes that should actually be efficient here [11:12] * Ng should read up about that [11:14] hi [11:16] ohhhh, nice, bisect does the middle-point searching thing [11:17] * Ng wonders if it'll be happy to go backwards though. the kernel.org docs are mostly about "current is broken, current-20 worked, find where it broke", where I need to work out where's it's fixed between 2.6.3 and 2.6.99 [11:18] sure will [11:18] win :) [11:29] so with my fresh checkout of git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel how would I figure out which commit corresponds to 2.6.3? [11:32] aha, there's a tag [11:33] ok, 18hrs of bug work is enough for one day. cya tomorrow. [11:33] %-P [11:34] heh :) [11:41] hi [11:41] so 2.6.3 seems to be about 3 months ago [11:42] which works out to 8k5 lines of diff ;) [11:43] yust tested the 2.6.99 on https://launchpad.net/~xorg-edgers with a g965 [11:43] all works well, but the 3dmark01 [11:43] still stable, but extrme, simialiar aartefacts on all tests (old objects which got moved are still there) [11:43] Im running9.04 [11:43] mifritscher: out of interest, is the jaunty intel driver working ok for you? [11:44] yes [11:44] but the 2.6.3 has a funny dependencie on pae [11:44] uxa runs only without pae, exa DOES need pea *G* [11:44] (with 4 GB ram) [11:45] didn't try that with 2.6.99 again, I've running it without pae + uxa [11:46] I only have 2GB of RAM, I'm just trying to work out why 3d stuff is a bit slow for me, but not for everyone :) [11:46] (works fine with the edgers PPA, but like you I see some artifacts, and I've had a couple of X hangs) [11:47] hmm, 3dmark01 gave me 1280 points on 2.6.3 and 1484 points on 2.6.99 [11:47] on VIsta I got 3783 [11:47] trac gets ca. 20 fps (and no artefacts) [11:48] trying 2003 *G* [11:48] is 3dmark available freely for linux? it might help my case if I can produce objective numbers rather than subjective workspace-flipping tests [11:49] killed X right after starting the program (not the acutal test) [11:51] would we expect 2.6.3 to work with a snapshot of libdrm? I just realised that both of those will have been replaced by the edgers PPA so the fix I need could be in either. I know it can't be mesa because I tried tjaalton's 2.4 packages and there was no change [11:51] backtrace: http://rafb.net/p/i3S8KQ46.html [11:55] now it starts, but it is missind DXT1 and DXT3 texture compression [11:55] (as with the old driver) [12:22] Ng: newer libdrm should be fine for intel 2.6.3 [12:25] tormod, you are one of the maintainers of https://launchpad.net/~xorg-edgers/+archive/ppa, right? [12:25] mifritscher: de facto the only one [12:25] is the artefacts problem already known or do you need more details? [12:25] ah ;) [12:26] you have to check upstream. that's the point of this PPA :) [12:27] #intel-gfx is sort of dead :-/ [12:28] it's the time of day [12:28] check the bug tracker as well [12:30] didn't found anything [12:30] ( http://bugs.freedesktop.org/buglist.cgi?quicksearch=Drivers%2FDRI%2Fi965 ) [12:32] and for the pae I found only http://bugs.freedesktop.org/show_bug.cgi?id=17993 [12:32] Freedesktop bug 17993 in Driver/intel "[GEM] kernel with PAE panics when starting X" [Normal,Assigned] [12:33] but for me it is the other way around: I actually need pae to use exa ;-) [12:33] (for uxa, I must not use pae) [15:37] bryce ping [15:38] what about intel 815? is there a master bug for it? [15:39] the i815 driver hasn't changed in years afaik [15:39] i hope someone might help me, i cant log into gnome, but only fluxbox [15:39] i have the i815 [15:39] thiebaude: wrong channel [15:39] hyperair: actually I asked him to come here [15:39] eh? [15:39] BUGabundo sent me over here [15:39] with all this intel probs on 8x5 [15:40] well yeah but fluxbox works [15:40] obviously X starts [15:40] BUGabundo: 810 is completely separate [15:40] i thought i had the bug 304871 [15:40] Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,Fix released] https://launchpad.net/bugs/304871 [15:40] its halfway fixed [15:40] thiebaude: can you try to logout and select Safe Gnome Session? [15:40] thiebaude: if your chip is a 810/815, then that bug is irrelevant [15:40] ok thanks again BUGabundo [15:41] * BUGabundo goes back to +1 [15:41] see you [15:58] guys sorry for the noise [15:58] but thiebaude is reproducing the bug [15:58] of X freezing a few secs after login [15:59] with a 815... it looks pretty much like all other 8x5 [15:59] what can he do to debug it? [15:59] BUGabundo: i already told you, 815 is not like all other 8xx... [16:00] but symptoms are very much the same [16:00] on gnome , at least [16:03] i can only get into fluxbox [17:51] will mesa 7.4 be included in time for the testday tomorrow? [18:30] bryce: how much will I be mocked if I suggest rolling jaunty back to Intrepid's intel driver? :D [18:30] is such a thing even possible? [18:30] I fully appreciate that my view of the driver is very small and I may be missing wider issues, but I've yet to encounter anyone with an improved experience, but I am encountering lots of regressed ones [18:31] where "lots" is an unquantified value [18:32] so I just thought I'd throw the idea out there [18:32] you'd probably have to revert the kernel, too... [18:33] jcristau: as in, patches we've applied to the kernel? or does intel's 2.4.x simply not work on a 2.6.28 kernel? [18:34] (I really wish they wouldn't have release numbers that are so confusingly similar to kernel ones ;) [18:36] as in, "it worked better in intrepid" is not only related to the intel ddx, that's only one component [18:38] so 2.4.x with 2.6.28 might work, but it might not work better than what you have right now, and it is probably not as tested [18:38] so i'm just saying it's hard to know beforehand what will work best :) [18:39] ok, these are good points :) [18:39] I have the impression that we are somewhat stuck between a rock and a hard place until we are fully in the land of UXA and KMS! [18:40] which can only really be Intel's fault, imho [18:40] i get the feeling we're between a rock and a hard place until we are until the next rock and the next hard place :/ [18:41] s/until/between/2 [18:43] heh [18:44] surely after we're all using DRI2 and UXA and KMS there's no more big architecture stuff and Intel will actually fix bugs? :) [18:44] they seem to have been bug fixing a lot recenlt [18:51] Ng: well, back when we were on XAA and Intel was pushing EXA I remember thinking, "Once we're fully in the land of EXA, Intel will fix all their bugs, and it will be all milk and honey after that." [18:52] so I disoptimistically have to agree with jcristau [18:52] Ng: also even if reverting to the Intrepid driver were feasible, it would also result in losing some hardware support for newer hardware [19:02] bryce: you're filling me with confidence here, man ;) [19:03] bryce: if you're on -platform you will shortly get a horrific braindump from me of what I'm seeing and trying to do about it. It's a mess of information which I apologise for, I just wanted to braindump everything I have about it in the hopes that something good can come from it! [19:04] I unsubbed from platform when I moved to the desktop team [19:05] so you might cc ubuntu-x@ if you think it's worth me reading [19:05] ah right, so everyone on platform won't care. go me ;) [19:08] sent to -x :) [19:08] ok, bating breath and waiting [19:09] I really should subscribe to -x [19:09] yep [19:11] hah, especially since that mailman reply was not "lala wait for moderation", but "go away" ;) [19:11] * Ng subscribes and resends [19:11] heh [19:43] Ng: the mesa version on my ppa is 7.4 ;) [19:43] not 4.3 [21:11] bryce, tjaalton: what is the mesa 7.4 ETA right now? also, I heard a rumor that EXA perf might be fixed by some patch that disables GEM, have you heard that as well? [21:46] tjaalton: doh, I fail ;) [21:57] ... [21:57] mnemo: tjaalton has put 7.4 in his ppa. I think he is awaiting sufficient tester feedback before putting it in [21:58] bryce. [21:58] i [21:59] i'm having trouble with my intel git compiles [21:59] i have all the deps and followed directions, but x breaks. [21:59] mnemo: switching of gem plus an additional patch on -intel indeed fixed performance with I945 for me. [21:59] mnemo: debdiff http://paste.ubuntu.com/142337/ [22:00] patch 203 was accepted upstream 2 days ago [22:01] LLStarks: sympathies [22:01] any advice? [22:01] albert23: bug# ? [22:02] bryce: freedesktop bug 20797 [22:02] Freedesktop bug 20797 in Driver/intel "[i945] Performance regression in 2.6.3 from 2.6.1 with non-gem kernel" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20797 [22:03] LLStarks: I recommend nuking from orbit, it's the only way to be sure [22:03] ...wut? [22:03] albert23: thanks [22:03] bryce: performance on 945 is 303011 [22:04] LLStarks: oh you mean advice on your build issue? you didn't show any details so I can't give any advice. I do advocate nuking from orbit as a general solution to random build problems though. It helps. [22:05] there's no problem with the actual build. [22:05] i just can't get the binaries to start x. [22:06] albert23: thanks for the performance bug; is there also a corresponding launchpad bug (so I can set up subscriptions and such) [22:07] LLStarks: you can't find the binaries? [22:07] bryce: no, I didn't consider it an Ubuntu bug, as jaunty does have gem [22:07] that patch only helps if you switch of gem [22:07] no. they just won't start x when i restart. [22:08] they are pathed to /usr [22:08] LLStarks: try http://wiki.ubuntu.com/X/Troubleshooting/. [22:10] albert23: give that we're not using uxa, I wonder if it hurts anything to turn off gem as well [22:11] bryce: see the debdiff. UXA still works :-) [22:11] hmm, I thought gem was a prerequisite for UXA [22:12] bryce if (pI830->accel == ACCEL_EXA is the trick [22:12] see the pastebin [22:12] does the debdiff work with the 2.6.99 ppa packages? [22:13] also, does the patch negate the need for anholt's pending a17 fix? [22:13] bryce: my concern would be that the fake bufmgr code hasn't been tested in jaunty [22:14] * bryce nods [22:16] LLStarks: the debdiff has two parts. 1 switch of gem, 2 the TILE_NONE fix [22:17] LLStarks: the a17 fix should fix gem, so you don't need the first part anymore [22:17] i see. [22:17] so the patch right now is just a stop gap? [22:17] for me it is [22:18] and I am really not sure if it would be good for jaunty, given where we are in the release cycle [22:24] i severely doubt a performance patch would be denied a freeze exemption [22:29] LLStarks: btw, latest intel from git needs libdrm 2.4.6 and kernel 2.6.29 [22:30] i knew about 2.4.6 [22:30] I needed a patch to build with kernel headers from 2.6.28 and it still only runs on 2.6.29 kernel [22:30] but not the kernel [22:34] i do have a few mainline and self-built 2.6.29 kernels. [22:34] i don't think i got intel to work with those either. [22:45] hi. [22:46] i just uploaded some photos for my lvds bug: freedesktop bug 20951 [22:46] Freedesktop bug 20951 in Driver/intel "[945GM] Fullscreen graphical corruption on LVDS" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20951 [22:46] hopefully they are helpful