| === Duke` is now known as je_suis_2 | ||
| === je_suis_2 is now known as Duke` | ||
| tseliot | jcristau: any plans to include libdrm 2.4.14 in Debian soon? | 16:00 |
|---|---|---|
| jcristau | i haven't seen an announcement for that | 16:10 |
| jcristau | pointer? | 16:12 |
| 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:13 |
| tseliot | I don't know why they haven't announced it yet | 16:16 |
| tormod | macv, did you find out more about your crash yesterday? | 18:39 |
| 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:58 |
| tormod | but Xorg should not crash anyway, ideally... | 18:59 |
| tormod | and since you know a good and a bad mesa version, it should not be too difficult to track down | 19:00 |
| 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:01 |
| mac_v | oh x-updates... /me checking | 19:02 |
| 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:06 |
| 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:07 |
| mac_v | ah.. thought so... | 19:08 |
| * tormod waves to bryce | 19:16 | |
| tormod | what is exactly the mesa upload plan? | 19:16 |
| bryce | heya tormod, what's up? | 19:38 |
| bryce | tormod, btw been experimenting a tad with -ati+kms lately | 19:38 |
| bryce | seems still a touch too buggy to switch on imho | 19:39 |
| bryce | however quite a bit better than it used to be | 19:39 |
| === Duke` is now known as je_suis_2 | ||
| 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:32 |
| tormod | now only on a "dogfood diet", I realized that it is not on by default :) | 20:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| tormod | but I would prefer working suspend over such cosmetics | 20:38 |
| tormod | I am not a gamer, so my testing is mostly compiz, gears :) and googleearth | 20:39 |
| * 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:40 |
| 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:41 |
| tormod | dri1 and compiz, that is (again) | 20:42 |
| tormod | the real plus for dri2 is that it is worked on :) like in actively maintained | 20:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| bryce | jcristau, ah | 20:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| bryce | hm | 20:54 |
| tormod | it's a pretty old snapshot yes | 20:54 |
| tormod | bryce, what about mesa? | 20:55 |
| tormod | for ~ upstream support, I guess fedora is all kms/dri2? | 20:56 |
| tormod | so we would not be alone going for dri2 | 20:56 |
| 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:57 |
| 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:58 |
| 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 | 20:59 |
| tormod | but I mostly heard good things from people running xorg-edgers and 7.6 should be more safe than that | 21:00 |
| tormod | so I don't see much risk with mesa 7.6 | 21:01 |
| tormod | for -ati, we should also update, but maybe not to head | 21:02 |
| 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:03 |
| tormod | one tactic would be to take a snapshot just before that commit, and merge in the stable branch | 21:04 |
| tormod | OTOH this merge only covers r600 so if we do not enable r600 3D it would not matter so much for us | 21:05 |
| 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:06 |
| 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:08 |
| tormod | hm evolution should not be GPU-intensive. not good | 21:09 |
| 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:10 |
| tormod | yes, if s/r issues are common that would be a no-go IMO | 21:11 |
| 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:12 |
| tormod | I think we only have those "doesn't work" bug reports :) | 21:13 |
| 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:14 |
| tormod | for kms or not, we can ship exactly the same code - just one setting to do | 21:15 |
| tormod | so we're better off than in the -intel/jaunty case | 21:16 |
| diverse_izzue | good point, though switching should be as easy as possible | 21:17 |
| === je_suis_2 is now known as Duke` | ||
| 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:18 |
| bryce | upstream is quite helpful, but they're limited in manpower (compared with -intel) | 21:19 |
| 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:22 |
| * tormod quickly reboots to check some ubuntu-boot updates | 21:48 | |
| 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:49 |
| tormod | now there's one without drm loaded (known issue)? | 22:50 |
| diverse_izzue | tormod, around? | 22:54 |
| 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. | 22:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| tormod | versus 16 seconds for kms | 23:12 |
| tormod | "/usr/lib/xscreensaver/glblur -fps" gives 0.7 fps, yay | 23:14 |
| tormod | https://wiki.ubuntu.com/X/RadeonKMS | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!