[03:55] <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:56] <Sarvatt> oh it already does look in cairo-traces:/usr/src/cairo-traces:/usr/share/cairo-traces
[03:57] <RAOF> alf__: Rocking!  Thanks!
[04:01] <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:05] <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:08] <Sarvatt> benchmark/ (the small directory) from cairo traces is 548MB extracted
[04:08] <Sarvatt> 208mb of that is firefox-talos-svg though
[04:11] <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:12] <Sarvatt> takes a good 30 seconds for docky to unhide while extracting a lmza archive on this atom nows
[04:13] <Sarvatt> been wanting to try the fixes in 2.6.36 but its failed every day on the mainline kernel site
[04:16] <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:18] <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:19] <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:20] <RAOF> Well, it's not a regression then :)
[04:22] <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:33] <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:37] <Sarvatt> http://paste.ubuntu.com/477267/
[04:41] <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:48] <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:49] <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:50] <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:52] <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:53] <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:54] <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:55] <Sarvatt> spread across mesa mutter gnome-shell and clutter
[04:59] <Sarvatt> http://pkgs.fedoraproject.org/gitweb/?p=clutter.git;a=blob;f=Use-a-native-format-for-atlas-textures.patch;h=ebceb86f0d4083cd1c4b9edcfb3b383bf5e1829f;hb=HEAD
[05:01] <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:02] <Sarvatt> http://pkgs.fedoraproject.org/gitweb/?p=mesa.git;a=commit;h=7870febc63af10f89beb276bc68160c47dd845f0
[07:21]  * bryceh waves
[07:40]  * RAOF shores
[07:42]  * tjaalton drowns
[07:45] <tseliot> any survivors? :-P
[07:50] <tjaalton> after working some time on X? heck no...
[07:53] <tseliot> :-D
[08:00] <tjaalton> btw, do you know if the nvidia-current module in lucid compiles against backported 2.6.35 from maverick?
[08:01] <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:02] <tjaalton> for local use
[08:03] <Sarvatt> the one in x-updates/lucid isn't any different than maverick's except with 256.44, no packaging changes
[08:04] <tjaalton> k, thanks
=== yofel_ is now known as yofel
[08:32] <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:33] <Sarvatt> ugh good point, no way thats going to happen..
[08:34] <Sarvatt> so maybe a little script that downloads it from cairographics.org and extracts it? :D
[08:34] <RAOF> Yeah.
[08:35] <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:36] <Sarvatt> nice, the 38mb snapshot has all of /benchmark in it that was 548mb extracted
[08:37] <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:38] <Sarvatt> gotta be in cairo-traces:/usr/src/cairo-traces:/usr/share/cairo-traces
[08:39] <RAOF> And this isn't trivially patchable?
[08:39] <Sarvatt> yeah it is, whats wrong with /usr/share/cairo-trace/ though?
[08:40] <RAOF> Nothing, I guess.
[08:42] <Sarvatt> that newest snapshot is missing a few of the tests that show off the more recent pixman arm improvements :(
[08:44] <Sarvatt> oh they dont work with our cairo either
[08:44] <Sarvatt> http://cgit.freedesktop.org/cairo-traces/commit/?id=2812a7131d21e77939de856092dc807e069266fe
[08:45] <Sarvatt> http://cgit.freedesktop.org/cairo-traces/commit/?id=4c51a0e0c868586c506df7242215479134790b30  -- those were the arm ones
[08:46] <RAOF> Hm.
=== maxb_ is now known as maxb
[12:09] <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:10] <mvo> it seems to be partly because xserver-xorg-video-v4l is not available for -video-8 afaics
[12:46] <RAOF> mvo: It is available, at least on amd64.
[12:55] <RAOF> It looks to me like it's complaining about -tseng?
[12:56] <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
[13:03] <RAOF> And, you know what?  10pm on a Friday evening.
[13:10] <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:20] <mvo> RAOF: I think tseng is a red herring, its just the first thing that it encouters
[13:27] <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:52]  * tseliot is uploading nvidia...
[15:48] <Sarvatt> asac: no way regarding 965g
[15:48] <asac> :(
=== cndougla is now known as cnd
[17:19] <jcristau> Sarvatt: mv softpipe i965g, nobody will notice
[17:20] <Sarvatt> i dont even install it in xorg-edgers
[17:21] <Sarvatt> Dr_Jakob even split it to 2 configure options now too, enable-gallium-i915 (working) and enable-gallium-i965 (aka broken)
[17:22] <seb128> bryceh, hey, are you there?
[17:22] <bryceh> seb128, yes
[17:23] <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:24] <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:25] <bryceh> seb128, probably not a good thing to change post-FF though
[17:25] <bryceh> seb128, but your call
[17:29] <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:30] <bryceh> seb128, I'm of similar mind
[17:30] <seb128> ok
[17:30] <seb128> thanks
[17:30]  * seb128 defer it
=== JMS is now known as JoeMaverickSett
[17:54] <Sarvatt> hmm Mesa 7.9-devel implementation error: Bad renderbuffer format: 21 on i915 with mesa git when launching unity
[18:03] <Sarvatt> oh might be related to the failed upgrade because of the poppler stuff
[19:44] <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
[20:01] <Sarvatt> gdb unity, then break ctk_render_target_resize then run
[20:01] <Sarvatt> vish_: ^
[20:01] <Sarvatt> it'll print the dimensions
[20:02] <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:03] <vish_> oh ok , /me tries
[20:06] <Sarvatt> you'll probably need to cont a bunch of times until you get to the error
[20:07] <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:09] <Sarvatt> looks like its something r300g does much better :(
[20:10] <Sarvatt> actually theres a bunch of fixes for r300 classic NPOT in mesa 7.9
[20:11] <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:12] <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:13] <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:14] <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:15] <Sarvatt> you couldn't run gdb unity and break on that function?
[20:16] <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:17] <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:18] <vish> hehe if it doesnt work out, i guess i'll try that from my install , i only have 2gb ram ;)
[20:25] <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:28] <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:36] <Sarvatt> vish_: I can reproduce that crash with MESA_EXTENSION_OVERRIDE=-GL_ARB_texture_non_power_of_two unity
[20:38] <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:39] <vish_>  /me joins
[20:39] <vish_>  /join #ubuntu-desktop
=== rickspencer3 is now known as saacfl
=== saacfl is now known as rickspencer3