[16:00] <tseliot> jcristau: any plans to include libdrm 2.4.14 in Debian soon?
[16:10] <jcristau> i haven't seen an announcement for that
[16:12] <jcristau> pointer?
[16:13] <tseliot> jcristau: http://cgit.freedesktop.org/mesa/drm/tag/?id=libdrm-2.4.12
[16:13] <jcristau> i was more looking for an announce mail
[16:16] <tseliot> I don't know why they haven't announced it yet
[18:39] <tormod> macv, did you find out more about your crash yesterday?
[18:58] <mac_v> tormod: i still get the crash , for now i'm using a workaround and not selecting the windows from cairo-dock
[18:58] <mac_v> btw i'm using the cairo dock weekly ppa , that has optimizations for OpenGL stuff.... maybe that is causing this :(
[18:58] <tormod> if Xorg is crashing you should get some backtrace in Xorg.0.log or the gdm logs
[18:59] <tormod> but Xorg should not crash anyway, ideally...
[19:00] <tormod> and since you know a good and a bad mesa version, it should not be too difficult to track down
[19:01] <tormod> but now is mesa 7.6 testing time, so try that first :) in x-updates PPA
[19:01] <mac_v> the edgers ppa has it or...?
[19:02] <mac_v> oh x-updates... /me checking
[19:06] <mac_v> tormod: will there be any conflicts with the x-updates and edgers ppa? , if i just disable the edgers and use x-updates , i should be good to go  ,right?
[19:07] <tormod> mac_v, would be nice if you revert xorg-edgers using ppa-purge since the mesa 7.6 is built against stock karmic. see my post on the ubuntu-x ML
[19:08] <mac_v> ah.. thought so... 
[19:16]  * tormod waves to bryce
[19:16] <tormod> what is exactly the mesa upload plan?
[19:38] <bryce> heya tormod, what's up?
[19:38] <bryce> tormod, btw been experimenting a tad with -ati+kms lately
[19:39] <bryce> seems still a touch too buggy to switch on imho
[19:39] <bryce> however quite a bit better than it used to be
[20:32] <tormod> bryce, sorry I was out
[20:32] <tormod> I have been running only ati w/kms for quite some time, I felt it was solid
[20:33] <tormod> now only on a "dogfood diet", I realized that it is not on by default :)
[20:34] <bryce> kees found an issue on r3xx where backlight does not work after doing suspend/resume
[20:34] <bryce> I found an issue where if you vt switch, it doesn't show the console, just a static image of the X display, until you go back to vt7
[20:34] <tormod> anyway, there is currently no huge advantage with dri2 (except all the redrawing fixes, and glxgears on the cube)
[20:35] <bryce> but we need to come to a decision soon about go/no-go for kms on -ati if we want it in beta
[20:35] <bryce> what are your thoughts?
[20:35] <tormod> the flickerfree experience is not so much better I feel, at least on my card, the mode switching is pretty smooth on non-kms
[20:36] <tormod> I am worried about suspend/resume as well. since this is broken anyway on my laptop, I haven't been able to test it
[20:37] <tormod> but it is quite ugly how the redrawing is failing with compiz and dri1, like for instance moving glxgears window around
[20:37] <tormod> I have to switch virtual desktop back and forth to redraw
[20:38] <tormod> but I would prefer working suspend over such cosmetics
[20:39] <tormod> I am not a gamer, so my testing is mostly compiz, gears :) and googleearth
[20:40]  * bryce nods
[20:40] <tormod> I have the feeling dri1 is smoother than dri2 on googleearth, but I have no metrics
[20:40] <bryce> I imagine most hard core gamers will want -fglrx, and probably r6xx/r7xx anyway
[20:41] <tormod> but again the flickering windows and failing redraws on dri1 looks really bad to anyone you'd ask on the street (who hasn't lived with mesa betas through the years)
[20:41] <tormod> so dri2 can really be seen as a bug fix
[20:42] <tormod> dri1 and compiz, that is (again)
[20:43] <tormod> the real plus for dri2 is that it is worked on :) like in actively maintained
[20:44] <bryce> does dri2 depend on kms though?  Can't we ship with dri2 with or without kms?
[20:44] <tormod> but since we are so careful with post-release updates in Ubuntu that does not help us
[20:44] <virtuald> tormod, do you know if they recompiled the radeon drivers yet? i don't want to run edgers until karmic is out
[20:44] <tormod> virtuald, yes this was fixed
[20:45] <virtuald> ok should i run ppa-purge something?
[20:45] <virtuald> ppa-purge drivers-only?
[20:45] <tormod> virtuald, thanks for reminding us of that bug, it is embarrassing how long radeon was partly broken
[20:46] <tormod> blame it on us running xorg-edgers instead of dogfood
[20:46] <virtuald> yeah
[20:46] <jcristau> bryce: for radeon kms and dri2 come together
[20:46] <tormod> ppa-purge <name of ppa> (rinse and repeat)
[20:47] <bryce> jcristau, ah
[20:49] <tormod> bryce, it will of course help us that we can cherrypick crititical dri2 fixes, whereas dri1 bugs will probably not get high priority upstream
[20:50] <bryce> true
[20:50] <bryce> tormod, will you be able to help with identifying patches we should pull?
[20:50] <bryce> if we go forward with kms+dri2?
[20:51] <tormod> there should have been a little applet where people can switch kms/not and it would update grub.cfg...
[20:51] <bryce> I just worry my own time is going to be insufficient to stay atop bugs
[20:51] <bryce> tormod, yeah that would have been sweet
[20:52] <virtuald> is the radeon ddx in kramic som kind of stable branch?
[20:52] <tormod> I do follow the git commits to a certain degree and hang out on the phoronix forum, so I guess I can help out some
[20:53] <tormod> but I have no ambitions on spending more time on bug triaging than I do
[20:53] <jcristau> virtuald: it seems to be a snapshot from master, so no.
[20:53] <virtuald> ok
[20:54] <bryce> hm
[20:54] <tormod> it's a pretty old snapshot yes
[20:55] <tormod> bryce, what about mesa?
[20:56] <tormod> for ~ upstream support, I guess fedora is all kms/dri2?
[20:56] <tormod> so we would not be alone going for dri2
[20:57] <virtuald> will it be changed to a newer snapshot or something else?
[20:57] <bryce> tormod, I liked your post you did a few days ago calling for testers.  I do think shooting for 7.6 is still in the cards
[20:58] <bryce> although so far things have been a touch rougher than expected when we've updated, so we may have to make some tough choices there
[20:58] <tormod> I am just vaguely insinuating that ati bugs in fedora get fixed faster than other stuff
[20:59] <tormod> bryce, IMO we should have updated the snapshots more regularly
[20:59] <bryce> tormod, yeah 
[20:59] <bryce> tormod, me being off for the month hasn't helped I guess
[20:59] <tormod> now we're in a situation of making a big change, or be stuck with a half-cooked non-release that upstream would hate us for
[21:00] <tormod> but I mostly heard good things from people running xorg-edgers and 7.6 should be more safe than that
[21:01] <tormod> so I don't see much risk with mesa 7.6
[21:02] <tormod> for -ati, we should also update, but maybe not to head
[21:03] <tormod> but if you look at the last month's git log, there is not much and nothing scary
[21:03] <tormod> except "Merge branch 'r6xx-cs'"
[21:04] <tormod> one tactic would be to take a snapshot just before that commit, and merge in the stable branch
[21:05] <tormod> OTOH this merge only covers r600 so if we do not enable r600 3D it would not matter so much for us
[21:06] <tormod> note that I have no experience/technical backing for calling it "scary", it is just one big change, and cs is in general scary :)
[21:08] <tormod> on the whole, ati trunk can be considered "stable" ATM, very few commits the last 14 days
[21:08] <diverse_izzue> my two cents on -ati with KMS and DRI2: i feel it's not ready for prime time. the issues i have is that resuming from standby is completely broken and that performance is quite a bit reduced. evolution for example is very sluggish with the new stack, so somehow 2D performance is quite affected.
[21:08] <tormod> diverse_izzue, what card?
[21:08] <diverse_izzue> radeon mobile x1400 on a thinkpad t60
[21:09] <tormod> hm evolution should not be GPU-intensive. not good
[21:10] <diverse_izzue> maybe i should run a gtkperf or something?
[21:10] <diverse_izzue> the whole system feels sluggisher. also gnome-do's docky for example
[21:10] <diverse_izzue> the suspend/resume thing has been filed as a bug on both launchpad and b.f.o but nothing happened so far
[21:11] <tormod> yes, if s/r issues are common that would be a no-go IMO
[21:12] <diverse_izzue> how much data do we have?
[21:12] <diverse_izzue> as in, for how many users it works and for how many it doesn't
[21:13] <tormod> I think we only have those "doesn't work" bug reports :)
[21:14] <diverse_izzue> in a way, the situation is similar to -intel in jaunty. going forward makes people angry, but increases the changes that  by the next release things will be really solid
[21:14] <tormod> if it was easy to switch it wouldn't be the biggest issue, just pick one and tell people they can try the other
[21:15] <tormod> for kms or not, we can ship exactly the same code - just one setting to do
[21:16] <tormod> so we're better off than in the -intel/jaunty case
[21:17] <diverse_izzue> good point, though switching should be as easy as possible
[21:18] <diverse_izzue> how responsive is upstream in fixing stuff and helping with debugging? if things bet bad during beta that might be an important point
[21:19] <bryce> upstream is quite helpful, but they're limited in manpower (compared with -intel)
[21:22] <diverse_izzue> also, how bit a part of the fixes would need patches to the kernel? i'm still confused about which parts of the stack are in the kernel and which are not...
[21:48]  * tormod quickly reboots to check some ubuntu-boot updates
[22:49] <tormod> from hanging out in #ubuntu+1, there seems to be a lot of -intel issues
[22:49] <tormod> another day, 3 guys at the same time had stability issues (freezes)
[22:50] <tormod> now there's one without drm loaded (known issue)?
[22:54] <diverse_izzue> tormod, around?
[22:59] <diverse_izzue> remember i said 2D performance with the KMS/DRI2 stack was much reduced for me? I have numbers for that now: gtkperf without kms takes 9 seconds for 100 tests, it's 30 seconds with the KMS stack.
[23:02] <tormod> diverse_izzue, interesting!
[23:02] <diverse_izzue> for the progress bar it's 20-fold
[23:02] <diverse_izzue> that's the worst one
[23:03] <diverse_izzue> text view scroll 10x
[23:03] <tormod> what about we make a wiki table with the numbers and the card id?
[23:03] <diverse_izzue> good idea, but not tonight - gotta sleep. i'll be around tomorrow and will happily contribute my numbers
[23:04] <tormod> bryce, thinking about the dri1/2 switch: this would probably fit nicely and easily in jockey. now if someone wants a little project...
[23:04] <tormod> diverse_izzue, what are the command lines you run?
[23:04] <diverse_izzue> just installed gtkperf from the repos
[23:05] <diverse_izzue> then it's all GUI
[23:05] <diverse_izzue> ran all tests 100 times, then it outputs numbers
[23:05] <diverse_izzue> see what it does for you
[23:05] <tormod> ok
[23:05] <tormod> how long does it take ca?
[23:05] <diverse_izzue> 30 seconds total for kms
[23:06] <diverse_izzue> 9 secs for non-kms
[23:06] <diverse_izzue> all right. guet nacht!
[23:06] <tormod> thanks, 12 second non-kms (M26). gn8
[23:12] <tormod> versus 16 seconds for kms
[23:14] <tormod> "/usr/lib/xscreensaver/glblur -fps" gives 0.7 fps, yay
[23:27] <tormod> https://wiki.ubuntu.com/X/RadeonKMS