| Sarvatt | alf__: thanks again for packaging up cairo-perf, I've been meaning to do that for a long time now :) we probably should have a package with a few traces in it and change the default search patch to somewhere in /usr/share/ | 03:55 |
|---|---|---|
| Sarvatt | oh it already does look in cairo-traces:/usr/src/cairo-traces:/usr/share/cairo-traces | 03:56 |
| RAOF | alf__: Rocking! Thanks! | 03:57 |
| Sarvatt | i've got it in here if you want to try it, he changed it so the trace stuff was suggested instead of a hard dependency on -dev and -dbg after but i haven't rebuilt it with the update - https://edge.launchpad.net/~sarvatt/+archive/ppa | 04:01 |
| Sarvatt | man desktop interactivity has been complete crap for the past few months | 04:05 |
| Sarvatt | extracting archives or updating your system = unusable desktop till its done | 04:05 |
| Sarvatt | benchmark/ (the small directory) from cairo traces is 548MB extracted | 04:08 |
| Sarvatt | 208mb of that is firefox-talos-svg though | 04:08 |
| RAOF | Sarvatt: And you aren't even burdened with a btrfs partition that suffered a ~10x regression in write-heavy loads! | 04:11 |
| Sarvatt | oh man | 04:11 |
| Sarvatt | yeah this is ext4 | 04:11 |
| Sarvatt | takes a good 30 seconds for docky to unhide while extracting a lmza archive on this atom nows | 04:12 |
| Sarvatt | been wanting to try the fixes in 2.6.36 but its failed every day on the mainline kernel site | 04:13 |
| RAOF | Oh, those desktop-interactivity patches? | 04:16 |
| RAOF | AFAIK there aren't patches to fix btrfs yet, sadly. | 04:16 |
| Sarvatt | yeah pretty sure i saw them pulled upstream | 04:16 |
| RAOF | Funkay | 04:18 |
| Sarvatt | hah! | 04:18 |
| Sarvatt | [ 0] xlib swfdec-giant-steps 14.209 14.209 0.00% 1/1 | 04:18 |
| Sarvatt | [ # ] image: pixman 0.19.1 | 04:18 |
| Sarvatt | [ 0] image swfdec-giant-steps 12.166 12.166 0.00% 1/1 | 04:18 |
| Sarvatt | [ 0] xlib swfdec-giant-steps 194.422 194.602 0.05% 6 | 04:19 |
| Sarvatt | last one was what it was a year ago | 04:19 |
| Sarvatt | well last june | 04:19 |
| RAOF | Well, it's not a regression then :) | 04:20 |
| Sarvatt | pixman sped up a crapload too | 04:22 |
| Sarvatt | it was 45 seconds back in 0.16.x | 04:22 |
| RAOF | Pretty good! | 04:22 |
| Sarvatt | go figure gnome-do is segfaulting when i try to record a trace to see whats going on making it suck on nouveau | 04:33 |
| Sarvatt | http://paste.ubuntu.com/477267/ | 04:37 |
| Sarvatt | oh wow, we've actually got security locked down so we can't even attach to a process in gdb by default now? | 04:41 |
| RAOF | Yes. | 04:48 |
| RAOF | Sarvatt: Isn't that fixed by the new libcairo, which doesn't hugely penalise drivers which don't support server-side gradients? | 04:48 |
| Sarvatt | and also removes server side gradient support for the drivers that do slowing them down? like my intel :) | 04:49 |
| Sarvatt | the slow docky was a gradient problem? | 04:49 |
| RAOF | I didn't look at the patch, but I thought it just set “buggy-gradients” on more drivers. | 04:49 |
| Sarvatt | i dont know, haven't been able to pry my nouveau laptop away from the wife to test it :) | 04:49 |
| Sarvatt | it set it unconditionally unlike what the changelog said | 04:50 |
| * RAOF restarts X on Ein. | 04:50 | |
| Sarvatt | but its a necessary evil apparently, fedora is doing it too | 04:50 |
| Sarvatt | the nvidia blob people weren't happy about it either because they accelerate it even though server side gradients were causing all kinds of rendering errors there | 04:52 |
| RAOF | :) | 04:52 |
| RAOF | Yup. Do is now snappy again on Ein. | 04:52 |
| Sarvatt | oh woohoo! | 04:53 |
| Sarvatt | didn't know that fixed it | 04:53 |
| RAOF | mutter doesn't like nouveau very much. | 04:53 |
| RAOF | (Although much, much more than it likes radeon) | 04:53 |
| Sarvatt | fedora has a crapload of patches for mutter/gnome-shell on ati | 04:54 |
| Sarvatt | at least they did when i was looking at f13 before that released | 04:54 |
| Sarvatt | spread across mesa mutter gnome-shell and clutter | 04:55 |
| Sarvatt | http://pkgs.fedoraproject.org/gitweb/?p=clutter.git;a=blob;f=Use-a-native-format-for-atlas-textures.patch;h=ebceb86f0d4083cd1c4b9edcfb3b383bf5e1829f;hb=HEAD | 04:59 |
| Sarvatt | http://pkgs.fedoraproject.org/gitweb/?p=mesa.git;a=blob;f=radeon-fix-glCopyTex-Sub-Image-if-user-FBO-is-bound.patch;h=0a7ef6047ec349c5726bb6170c1ae8316330c755;hb=refs/heads/f13/master | 05:01 |
| Sarvatt | http://pkgs.fedoraproject.org/gitweb/?p=mesa.git;a=commit;h=7870febc63af10f89beb276bc68160c47dd845f0 | 05:02 |
| * bryceh waves | 07:21 | |
| * RAOF shores | 07:40 | |
| * tjaalton drowns | 07:42 | |
| tseliot | any survivors? :-P | 07:45 |
| tjaalton | after working some time on X? heck no... | 07:50 |
| tseliot | :-D | 07:53 |
| tjaalton | btw, do you know if the nvidia-current module in lucid compiles against backported 2.6.35 from maverick? | 08:00 |
| Sarvatt | pretty sure i remember having to add a dkms patch for 2.6.34 but its been a long time | 08:01 |
| tjaalton | alright. I could always just backport the nvidia as well | 08:01 |
| tjaalton | for local use | 08:02 |
| Sarvatt | the one in x-updates/lucid isn't any different than maverick's except with 256.44, no packaging changes | 08:03 |
| tjaalton | k, thanks | 08:04 |
| === yofel_ is now known as yofel | ||
| alf__ | Sarvatt: Hi! I started packaging the traces from upstream some time ago, but it seems they have no licensing (https://bugs.freedesktop.org/show_bug.cgi?id=28914). | 08:32 |
| ubot4` | Freedesktop bug 28914 in general "Missing licensing information for cairo-traces prevents redistribution" [Normal,New] | 08:32 |
| Sarvatt | ugh good point, no way thats going to happen.. | 08:33 |
| Sarvatt | so maybe a little script that downloads it from cairographics.org and extracts it? :D | 08:34 |
| RAOF | Yeah. | 08:34 |
| RAOF | That's what I was expecting we'd do, given (a) they're nicely available in git, (b) they're huge, and (c) they're of quite limited audience. There doesn't seem to be a huge amount of point in distributing huge source packages on all the mirrors. | 08:35 |
| Sarvatt | some snapshots here - http://cairographics.org/snapshots/ | 08:35 |
| Sarvatt | nice, the 38mb snapshot has all of /benchmark in it that was 548mb extracted | 08:36 |
| Sarvatt | need to download, extract, un-lzma everything in benchmark/ into /usr/share/cairo-traces in a script | 08:37 |
| RAOF | Can't it go in ~ somewhere? | 08:37 |
| Sarvatt | gotta be in cairo-traces:/usr/src/cairo-traces:/usr/share/cairo-traces | 08:38 |
| RAOF | And this isn't trivially patchable? | 08:39 |
| Sarvatt | yeah it is, whats wrong with /usr/share/cairo-trace/ though? | 08:39 |
| RAOF | Nothing, I guess. | 08:40 |
| Sarvatt | that newest snapshot is missing a few of the tests that show off the more recent pixman arm improvements :( | 08:42 |
| Sarvatt | oh they dont work with our cairo either | 08:44 |
| Sarvatt | http://cgit.freedesktop.org/cairo-traces/commit/?id=2812a7131d21e77939de856092dc807e069266fe | 08:44 |
| Sarvatt | http://cgit.freedesktop.org/cairo-traces/commit/?id=4c51a0e0c868586c506df7242215479134790b30 -- those were the arm ones | 08:45 |
| RAOF | Hm. | 08:46 |
| === maxb_ is now known as maxb | ||
| mvo | RAOF: the upgrade is currently a bit unhappy: http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ubuntu/apt.log (from lucid to maverick). I think if you change "breaks: xserver-xorg-video-6" to a "conflicts: xserver-xorg-video-6", that should help apt deal better with that | 12:09 |
| mvo | it seems to be partly because xserver-xorg-video-v4l is not available for -video-8 afaics | 12:10 |
| RAOF | mvo: It is available, at least on amd64. | 12:46 |
| RAOF | It looks to me like it's complaining about -tseng? | 12:55 |
| RAOF | But AFAIK there are only 4 things in the archive which are broken by -video-8: nvidia, nvidia-173, nvidia-96 and virtualbox-ose | 12:56 |
| RAOF | And, you know what? 10pm on a Friday evening. | 13:03 |
| tseliot | hehe | 13:10 |
| tseliot | I'll fix nvidia-current today | 13:10 |
| tseliot | 173 and 96 will remain broken | 13:10 |
| tseliot | (for now, at least) | 13:10 |
| mvo | RAOF: I think tseng is a red herring, its just the first thing that it encouters | 13:20 |
| asac | RAOF: do you think there is any chance we get good gallium for GM965/GL960 this cycle? | 13:27 |
| asac | would really love to be able to use that :( | 13:27 |
| asac | or is nouveau the only thing that has chances to work for now? | 13:27 |
| * tseliot is uploading nvidia... | 13:52 | |
| Sarvatt | asac: no way regarding 965g | 15:48 |
| asac | :( | 15:48 |
| === cndougla is now known as cnd | ||
| jcristau | Sarvatt: mv softpipe i965g, nobody will notice | 17:19 |
| Sarvatt | i dont even install it in xorg-edgers | 17:20 |
| Sarvatt | Dr_Jakob even split it to 2 configure options now too, enable-gallium-i915 (working) and enable-gallium-i965 (aka broken) | 17:21 |
| seb128 | bryceh, hey, are you there? | 17:22 |
| bryceh | seb128, yes | 17:22 |
| seb128 | bryceh, how is https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-extract-failsafex going for maverick? | 17:23 |
| seb128 | is that something concerning the default installation? | 17:23 |
| seb128 | shouldn't that be landing around now for the feature freeze? | 17:23 |
| bryceh | seb128, yeah it should; I uploaded it to universe but it got rejected. I've not had a chance to get back and fix it up though | 17:24 |
| bryceh | seb128, probably not a good thing to change post-FF though | 17:25 |
| bryceh | seb128, but your call | 17:25 |
| seb128 | bryceh, I would say it's late now and you seem to not have lot of time to debug it etc | 17:29 |
| seb128 | bryceh, I would say let's defer to next cycle | 17:29 |
| seb128 | bryceh, what do you think? | 17:29 |
| bryceh | seb128, sounds good | 17:29 |
| bryceh | seb128, I'm of similar mind | 17:30 |
| seb128 | ok | 17:30 |
| seb128 | thanks | 17:30 |
| * seb128 defer it | 17:30 | |
| === JMS is now known as JoeMaverickSett | ||
| Sarvatt | hmm Mesa 7.9-devel implementation error: Bad renderbuffer format: 21 on i915 with mesa git when launching unity | 17:54 |
| Sarvatt | oh might be related to the failed upgrade because of the poppler stuff | 18:03 |
| vish_ | Sarvatt: how do i do this "break on ctk_render_target_resize and check out the dimensions" ? | 19:44 |
| * vish_ thought here was better than -desktop | 19:44 | |
| Sarvatt | gdb unity, then break ctk_render_target_resize then run | 20:01 |
| Sarvatt | vish_: ^ | 20:01 |
| Sarvatt | it'll print the dimensions | 20:01 |
| Sarvatt | i havent looked at this clutk before, i'm guessing it just assumes NPOT works if the extension is advertised when earlier radeons have some restrictions on its use and its breaking | 20:02 |
| vish_ | oh ok , /me tries | 20:03 |
| Sarvatt | you'll probably need to cont a bunch of times until you get to the error | 20:06 |
| Sarvatt | just found some discussion on it in #radeon - http://webcache.googleusercontent.com/search?q=cache:rN3nzrCKJhEJ:www.radeonhd.org/%3Fpage%3Darchive_display%26c%3Dradeon%26m%3D6%26y%3D2010%26d%3D2010-6-13+radeon+NPOT&cd=5&hl=en&ct=clnk&gl=us | 20:07 |
| Sarvatt | looks like its something r300g does much better :( | 20:09 |
| Sarvatt | actually theres a bunch of fixes for r300 classic NPOT in mesa 7.9 | 20:10 |
| Sarvatt | could try xorg-edgers and see if it works there, *hopefully* 7.9 will make it into maverick | 20:11 |
| vish | yeah , will try the -edgers too | 20:11 |
| Sarvatt | dunno if you missed these messages but - | 20:12 |
| Sarvatt | <Sarvatt> you'll probably need to cont a bunch of times until you get to the error | 20:12 |
| Sarvatt | <Sarvatt> just found some discussion on it in #radeon - http://webcache.googleusercontent.com/search?q=cache:rN3nzrCKJhEJ:www.radeonhd.org/%3Fpage%3Darchive_display%26c%3Dradeon%26m%3D6%26y%3D2010%26d%3D2010-6-13+radeon+NPOT&cd=5&hl=en&ct=clnk&gl=us | 20:12 |
| Sarvatt | before you came on as vish | 20:12 |
| vish | yeah , it crashed :) | 20:12 |
| Sarvatt | if edgers works thats a really good justification for a 7.9 FFE so it'd be interesting to know :) | 20:12 |
| vish | Sarvatt: if i run gdb mutter --replace --mutter-pligings=libuinty-mutter and then give the break ..., it just frooze and i could do nothing.. | 20:13 |
| vish | ohh! thats tempting ! | 20:13 |
| Sarvatt | if you just want it to work you can add Option "Gallium" "True" to a driver section with radeon in it in an xorg.conf | 20:14 |
| Sarvatt | (with edgers) | 20:14 |
| Sarvatt | after seeing if r300 classic works | 20:14 |
| Sarvatt | you couldn't run gdb unity and break on that function? | 20:15 |
| Sarvatt | you'd have to run mutter over ssh from another machine if you want to do it in gdb | 20:16 |
| vish | Sarvatt: hmm , if i give only the break option it runs , but if i set the "handle SIG33 pass nostop noprint" , it seems to freeze | 20:16 |
| vish | btw , i'm running the gdb on a daily cd | 20:16 |
| Sarvatt | gotta have a *lot* of ram to upgrade to edgers on a livecd :D | 20:17 |
| Sarvatt | oh maybe not, its the kernel upgrades that are killer | 20:17 |
| vish | hehe if it doesnt work out, i guess i'll try that from my install , i only have 2gb ram ;) | 20:18 |
| Sarvatt | if you have a large persistant storage on a usb stick and aren't using a real cd it'll work at least | 20:25 |
| vish_ | Sarvatt: it says: Breakpoint 1, ctk_render_target_resize (self=0x8939f08, width=1280, height=800) , but the system frooze , so not really sure if its right : http://pastebin.com/rKMmP4wh | 20:28 |
| Sarvatt | vish_: I can reproduce that crash with MESA_EXTENSION_OVERRIDE=-GL_ARB_texture_non_power_of_two unity | 20:36 |
| vish_ | Sarvatt: cool! , so i can add an xorg-*-ati task to bug #616997 ? | 20:38 |
| ubot4` | Launchpad bug 616997 in unity (Ubuntu) "Unity keeps reloading with a white background (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/616997 | 20:38 |
| Sarvatt | vish_: can ya join #ubuntu-desktop so the people that made clutk and stuff see the discussion? :D | 20:38 |
| vish_ | /me joins | 20:39 |
| vish_ | /join #ubuntu-desktop | 20:39 |
| === rickspencer3 is now known as saacfl | ||
| === saacfl is now known as rickspencer3 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!