[00:39] <bjsnider> RAOF, gstreamer-vaapi is free, although it is very raw at this point
[00:39] <bjsnider> it works but doesn't have any subtitle support right now
[00:40] <RAOF> Oh, and it actually works & exists now?  I've been aware that there's been work on that area, I just haven't followed closely.
[00:40] <RAOF> (vdpau on fluendo on my tiny little netbook is sufficiently useful to crowd out other investigations)
[00:41] <bjsnider> you have to actually...
[00:41] <bjsnider> horro of horros...
[00:41] <bjsnider> PAY for that right?
[00:43] <RAOF> Indeed you do!  Shocking, I know.
[00:43] <bjsnider> pardon me while i throw myself off the nearest tall building in despair
[00:46] <bjsnider> RAOF, you've always been madly in love with gstreamer, but others prefer mplayer and/or vlc
[00:46] <RAOF> Yeah, I know.
[00:46] <bjsnider> i think there's a movement on to make kde's media player engine vlc instead of xine
[00:46] <RAOF> But gstreamer is (rightly) the default, so it's reasonable to care more about it.  Particularly when that aligns with my own interests :)
[00:47] <bjsnider> it's RIGHTLY the default
[00:47]  * RAOF still isn't sure why kde's media player isn't a thin layer around gstreamer :)
[00:47] <jcristau> because gstreamer has a g
[00:47] <jcristau> they can't possibly allow that in kde
[00:48] <RAOF> Worse, it's gobject based!
[00:48] <bjsnider> yeah but why did they pick xine, of all things?
[00:48] <RAOF> Because it's an actual engine, I think.
[00:48] <RAOF> Like, is intended to be used as such.
[00:48] <RAOF> Does vlc provide that sort of thing?  I've only interacted with it as a (kick-arse) player for Windows/Mac.
[00:49] <bjsnider> evidently so
[00:49] <bjsnider> but anything that can be used at the command line could theoretically be used that way
[00:49] <RAOF> Yeah, but that's *made* of ugly.
[00:49] <jcristau> so is kde, so that's fine
[00:49]  * jcristau hides
[00:49] <bjsnider> xine couldn't even do 24-bit flac until very recently
[00:50] <bjsnider> it still can't do flac 5.1
[00:50] <RAOF> See?  GStreamer :P
[00:50] <bjsnider> why is gstreamer better than mplayer?
[00:51]  * RAOF doesn't actually know if the gstreamer decoders support that, 'cause he doesn't have (a) a 24bit soundcard, (b) 5.1 speakers.
[00:51] <bjsnider> gstreamer does do both
[00:51] <bjsnider> but so does mplayer and so does vlc
[00:51] <RAOF> Mainly because mplayer is the whole widget, with a terrible UI.
[00:52] <bjsnider> ok, forget the stupid ui
[00:52] <bjsnider> it's been dropped anyway
[00:52] <RAOF> So it's now just a commandline client?
[00:53] <bjsnider> yes
[00:53] <bjsnider> but nobody who seriously uses it had installed mplayer-gui for years
[00:53] <bjsnider> there are much better gui clients, like gnome-mplayer and smplayer
[00:54] <RAOF> A commandline client isn't particularly programmer-friendly.
[00:54] <bjsnider> it doesnt eh best subtitles, and it was the first app that had vdpau
[00:54] <RAOF> The thing that I particularly like about gstreamer is that it can be, and is, our media framework.
[00:55] <RAOF> (Also that it's trivially pluggable, which is important)
[00:55] <bjsnider> so it's better because it's what we currently have? i do not accept that reasoning
[00:56] <RAOF> It's better because nothing else can reasonably be our media framework.
[00:56] <RAOF> Nothing else (bar xine, I think?) does the sort of plugability we need.
[00:57] <bjsnider> what if videolan could?
[00:58] <RAOF> Then it might be a good idea, but it'd need to be significantly better than gstreamer to justify the switch.
[00:59] <RAOF> Is videolan actually intended to be used as a media player framework, though?  I know that it's possible to use it as such, but isn't it much more focused on vlc?
[00:59] <bjsnider> you know, it's developed as heavily as anything i've seen, so it might not have been yesterday, and it might be today
[01:00] <bjsnider> if you ever try to build it, it's significantly different after 6 weeks than it was earlier
[01:00] <bjsnider> quite unlike xine, by the way
[01:00] <RAOF> That's not exactly an unconditional win :)
[01:01] <bjsnider> vlc probably cooks your supper and tucks you into bed by now
[01:05] <RAOF> Well, get it stabilised, supporting plugabble codecs, and used by GNOME applications and I'll care significantly more about it :)
[01:49]  * freeflying 
[02:57] <warewolf> hm
[02:57] <warewolf> ok, #ubuntu is useless, I have an X problem so I'll try poking around here.
[02:57] <warewolf> I updated my T91MT running lucid last night, and now stuff is all kinds of broken.
[02:58] <warewolf> single user mode gets stuck before getting to that curses UI menu thing, and X acts like there are no mouse/keyboard devices defined.
[02:58] <warewolf> I can get a shell via init=/bin/bash, but have no idea how to troubleshoot upstart.
[03:11] <RAOF> Sounds like udev might be broken?
[03:12] <warewolf> I just disabled the one and only custom rule I had in there for android adb
[03:13] <warewolf> oh I suppose I could have looked at the xorg log. duh.  lemme see.
[03:15] <warewolf> er
[03:15] <warewolf> I don't even see *mention* of keyboard in the xorg conf at all.
[03:15] <RAOF> You have an xorg.conf?
[03:15] <warewolf> yeah, but it's really short.
[03:15] <RAOF> Many people won't.
[03:16] <warewolf> just some stuff for the T91MT's touchscreen, with Sarvatt's help
[03:16] <warewolf> er
[03:16] <RAOF> Ok.
[03:16] <warewolf> s/xorg conf/xorg log/
[03:16] <warewolf> I expect to see something about a keyboard device in the xorg log
[03:16] <RAOF> Only if udev's working.
[03:16] <RAOF> If udev isn't working then X won't see *any* input devices.
[03:16] <warewolf> ok, another notch in udev being broken.
[03:16] <warewolf> yeah, that sounds about right then.
[03:17] <warewolf> how the fsck did I break udev by doing a system update last night? *boggles*
[03:17] <warewolf> I suck at troubleshooting udev
[03:49] <warewolf> ok
[03:50] <warewolf> dpkg-reconfigure udev and update_initramfs=all fixxored
[04:15] <Sarvatt> sorry richard, I just walked in the door and missed your messages, get it working? wonder what the heck happened there
[04:16] <Sarvatt> warewolf: did you see there were proprietary drivers for that piece of junk now that probably work on lucid? :)
[04:17] <Sarvatt> i think one of those guys that was packaging up the PSB stuff has a PPA with them on launchpad, bernardo something?
[04:17] <Sarvatt> drivers are called emgd
[04:18] <Sarvatt> i still can't download anything but windows drivers direct from intel, trying to download for any linux distro gives me an exe
[04:19]  * Sarvatt goes back to trying to root his G2
[04:24] <RAOF> Good plan!
[04:26] <bjsnider> does jockey not block the nvidia run files anymore?
[04:27] <RAOF> As in: prevent them from working?  Did it ever?
[04:27] <bjsnider> it prevented them from installing starting with lucid
[04:28] <bjsnider> but now all these n00bs are in the +1 channel talking about how they installed the .run files
[06:16] <Sarvatt> warewolf: speak of the devil... http://woot.com/
[07:34] <Sarvatt> just ordered a 5770, time to go through some of this fglrx pain :)
[07:35] <RAOF> :)
[13:28] <bjsnider> tseliot, does jockey not block the nvidia run files anymore?
[13:49] <tseliot> bjsnider: jockey never did that
[14:03] <bjsnider> ok, well i must hve misunderstood then
[14:33] <bjsnider> it's nvidia-current that does it, but it's not part of the metapackages, so it's not there by default
[14:43] <warewolf> Sarvatt: hah
[15:13] <Sarvatt> bryceh: would it be possible to move intel to the top of the chart so the other packages are easier to follow? http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
[15:47] <dandel> Sarvatt: lol... that report shows how popular ati hardware is on linux.
[15:49] <Sarvatt> dandel: i think you're looking at it wrong
[15:50] <Sarvatt> fglrx being at the top doesn't mean it has the most, the fglrx bugs are represented by the tiny blue strip at the top only
[15:51] <dandel> if that's the case, the #1 used hardware is intel (which is not surprising)
[15:52] <Sarvatt> you cant really pull any use numbers out of that, intel is really skewed because we have automatic crash reporting bugs for that package only which is getting triggered by some non fatal crashes and flooding launchpad
[15:54] <dandel> i see... and that bug report results are not as bad... i know i removed a few packages results manually because i did bleeding edge tests (2.6.36 kernel tests)
[16:06] <Sarvatt> cnd: dunno if you got my message about it, but wouldn't it make more sense to install 60-magictrackpad.conf in a utouch package instead of evdev since utouch isn't installed by default everywhere and there is a loss of functionality using evdev without it?
[16:12] <cnd> Sarvatt, utouch is merely a meta package
[16:12] <cnd> you could argue it could go into libutouch-grail1
[16:12] <cnd> but that is installed everywhere
[16:13] <cnd> to answer the question more directly, we don't want a different experience between the desktop and netbook installs
[16:13] <cnd> right now the desktop has a subset of the features in netbook because compiz doesn't have gestures like unity does
[16:13] <cnd> but we don't want there to be divergent features between the two
[16:14] <cnd> and to be honest, I was on your side too
[16:14] <jcristau> so you regress the desktop instead :)
[16:14] <cnd> I would rather have left the magic trackpad alone for now
[16:14] <cnd> but I was overruled by others :)
[16:14] <cnd> the desktop never regressed
[16:14] <cnd> in lucid, the synaptics functionality wasn't present
[16:14] <jcristau> oh, ok
[16:15] <cnd> we had a choice in maverick to either enable synaptics functionality, or enable gestures
[16:15] <cnd> due to time constraints
[16:15] <bjsnider> Sarvatt, why in the world are you buying an ati card?
[16:15] <bjsnider> do you enjoy pain?
[16:15] <cnd> and all the synaptics functionality should be duplicated in our gesture framework in Natty (hopefully)
[16:16] <cnd> it not in Natty, certainly by the O
[16:44] <Sarvatt> woo baby, http://cgit.freedesktop.org/mesa/drm/commit/?id=726210f87d558d558022f35bc8c839e798a19f0c is going to fix a massive amount of these apport intel bugs
[16:48] <Sarvatt> bjsnider: I don't have any ati's to break anymore and there was nothing better at $120
[16:48] <Sarvatt> hell, I want a poulsbo machine still :)
[16:48]  * Sarvatt likes broken stuff
[16:49] <Sarvatt> but i draw the line at 8xx intel's
[16:49] <jcristau> heh
[17:40] <bryceh> Sarvatt, nice work - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick.svg
[17:41] <Sarvatt> bryceh: that aint even half of it, and a large chunk of the duped ones are going to be closed whenever I can get that libdrm fix SRUed :)
[17:42] <Sarvatt> i'm going through and adjusting the titles of all of them now and will dupe after since that makes it easier so they stopped going down for a bit
[17:44] <Sarvatt> then i can start actually fixing things.. lol
[17:49] <bryceh> cool
[17:49] <bryceh> special attention to 656243 would be deserved
[17:50] <Sarvatt> yep thats the libdrm problem
[17:51] <Sarvatt> already have it in git, asked for testing of the PPA one on the many bugs
[17:52] <Sarvatt> haven't started condensing that one too much because people report the symptoms differently and want to get feedback on the different symptoms, but there are 3 major ones i'm looking at so far
[17:52] <bryceh> cool
[17:55] <Sarvatt> bryceh: when should I start looking for sponsors and preparing the bugs for SRU? I'm just assuming I'd have to wait until release first :)
[17:56] <bryceh> nope you can prepare SRUs as soon as you are confident in the fix
[17:56] <bryceh> in fact the release team sometimes pulls in SRUs pre-release if there's time and the bug looks acceptable to them
[17:58] <bryceh> also, sru bugs generally need a week or so of testing before the archive team puts them out, so filing them now means they can be tested while the release is finishing up, and can go out a few days post-release
[18:01] <Sarvatt> oh heck, I've had a sandybridge fix ready and tested by many HWE people for the past week but assumed it was bad form to try to SRU before release unless it was critical
[18:15] <Sarvatt> RAOF: forgot to commit something to x-x-v-intel git?
[18:15] <Sarvatt>   * Cherry-pick e30f0338 to free the Screen pixmap on close.  Fixes a memory
[18:15] <Sarvatt>     leak on server regeneration, and another crash on KDE log out hidden by
[18:15] <Sarvatt>     LP 628077.
[18:15] <ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i865] Crash on logout with KDM (affects: 1) (heat: 111)" [High,Fix released] https://launchpad.net/bugs/628077
[18:15]  * Sarvatt just noticed it missing in the debdiff
[18:42] <Sarvatt> hmm, not where where this bug should go http://launchpadlibrarian.net/55916325/XorgLogOld.txt
[20:03] <Sarvatt> bryceh: well the apport reports are for sure better than 90% of the normal bugs, the automatic duping just needs to  be fixed up a bit. at least I can tell whats actually happening without relying on what they say, like if they have a video playing in firefox and just say firefox is causing the crash and its a lot easier to spot dupes
[20:04] <Sarvatt> looking at non apport bugs is painfully slow now :)
[20:09]  * penguin42 is going to try and apply THomas Hellstrom's ttm fix that Dave Airlie pushed today , see if it fixes his -12 errors
[20:10] <Sarvatt> if PGTBL_ER + chipset generation match they can be duped, IPEHR: 0x7xxxxxxx are all 3D engine related on 965+, IPEHR: 0x018xxxxxx are enable/disabling/resizing the monitor related, IPEHR: 0x01810000 is always accelerated video playback on 8xx, etc
[20:11] <Sarvatt> guess I should read the docs
[20:14] <Sarvatt> beats the heck out of manually going over the logs for 10+ minutes on each bug to find a trace of the problem
[20:33] <penguin42> did Radeon hd5xxx ever work on Lucid? I had a bug raised where it was wrongly doing KMS for them but couldn't cut it - was there ever anything to address that?
[20:38] <Sarvatt> penguin42: I don't know for sure but I'll find out tomorrow when I get my 5770 in, as far as I remember it shouldn't have even tried to work at that point and vesa would be used until fglrx was installed
[20:39] <penguin42> ah it's listed in lucid-updates
[20:39] <penguin42> Sarvatt: Bug 560306
[20:39] <ubot4> Launchpad bug 560306 in xserver-xorg-video-ati (Ubuntu Lucid) (and 3 other projects) "[lucid] ATI hd5xxx cards wrongly doing kms? (affects: 38) (dups: 5) (heat: 154)" [High,Fix released] https://launchpad.net/bugs/560306
[20:41] <Sarvatt> hmm that shouldn't have been happening
[20:41] <Sarvatt> it even loaded the rv710 microcode
[20:41] <penguin42> Sarvatt: Hence why I reported it
[20:42] <Sarvatt> oh looks like I responded there and didn't check up on it after too, I thought the radeon.modeset=1 that we had forced in the x-x-v-ati synced from debian was screwing it up
[20:43] <Sarvatt> lets see, one person saying no problem in the lucid -rc..
[20:43] <penguin42> Sarvatt: With that guy just reporting it still happening on 10.04.1 it would be good to get it fixed next time a CD gets regenerated (is there going to be a .2 ?)
[20:43] <Sarvatt> haven't made it down that far in the  bug yet :)
[20:43] <Sarvatt> ugh its another dumping ground bug so far, people reporting all kinds of other problems thinking its the same
[20:44] <penguin42> yeh - whether it is or not is a good question
[20:44] <Sarvatt> like the dvi-0/dvi-1 issue
[20:44] <penguin42> Sarvatt: I don't have a 5k to try it out, if 10.04.1 actually works for you it would be good to note it
[20:44] <Sarvatt> yeah will do for sure
[20:46] <Sarvatt> there was a bug where the dvi port assignments were messed up and only one of the two was working on radeon that I see a few people mentioning but i'm (almost) positive that was fixed
[20:47] <penguin42> oh well, that's the sods law of having two ports, it'll always use the wrong one
[20:47] <Sarvatt> evergreen firmware isn't the issue since .33 didn't support it in the first place but I guess it got added anyway
[20:47] <Sarvatt> radeon thinks its an rv710
[20:48] <jcristau> you didn't backport evergreen kms?
[20:48] <Sarvatt> nope
[20:48] <Sarvatt> not that i'm aware of
[20:48] <jcristau> k
[20:49] <Sarvatt> we released before it was even remotely stable if i'm remembering right, you guys had more room to do it :)
[20:49] <jcristau> ah right, we got that in may
[20:54] <Sarvatt> penguin42: yeah people are just hitting the dvi problem, I know theres a fix for that and will try to work it out when the card comes. we got time with 10.04.2 being released in january :)
[20:54] <Sarvatt> backporting 5xxx KMS sure would be nice though
[20:55] <Sarvatt> there's no logs on that bug to look over to see whats happening now on them
[20:56] <Sarvatt> oh dang, missed some of the later responses, people hitting it on maverick?
[20:56] <penguin42> that's a pity, the drm-fixes patch I pulled didn't fix my -12 error :-(
[21:01] <Sarvatt> -12 error?
[21:05] <penguin42> Sarvatt: I can get an ENOMEM out of the ttm code by scrolling around google maps in chromium-browser (daily-ppa) in KDE with desktop effects on (HD4350)
[21:07] <penguin42> I have managed to trigger it on Gnome without desktop effects once, but I can trigger it in KDE with de in seconds
[21:07] <Sarvatt> is it one of those crazy AGP versions?
[21:08] <penguin42> no, PCI-e, 512MB ram on it
[21:13] <Sarvatt> penguin42: do you have a bug on it by any chance? not having any luck finding any with that that aren't from IGP's
[21:14] <penguin42> Sarvatt: I commented on bug 583891
[21:14] <ubot4> Launchpad bug 583891 in debian (and 1 other project) "X.org crashes sometimes. [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! (affects: 9) (heat: 46)" [Undecided,Confirmed] https://launchpad.net/bugs/583891
[21:15] <Sarvatt> of course its filed against linux and has no X related logs :(
[21:16] <Sarvatt> and quite a few of the people have old 9xxx series IGP's like the other bugs
[21:16] <penguin42> Sarvatt: I was wonderign whether to add an also-affects to Xorg
[21:17] <Sarvatt> that wouldn't get good logs in there but I doubt its the same bug hitting your card and those IGP's the other people have
[21:17] <penguin42> ok, should I file a separate one, and what would be useful for debug?
[21:17] <Sarvatt> they have things like [    8.435421] [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of ASIC bug ?) in it
[21:18] <Sarvatt> does the system completely hang when it happens?
[21:18] <penguin42> Sarvatt: No
[21:18] <Sarvatt> oh, it does for the IGP people too
[21:18] <penguin42> Sarvatt: Just the Chromium process dies
[21:19] <Sarvatt> if you could trigger it then run ubuntu-bug xorg it'd put some useful logs on it, that'd be appreciated
[21:19] <penguin42> Sarvatt: OK, will do - I don't think there is anything useful in any of the logs to be honest
[21:20] <Sarvatt> i haven't found anyone else on r600+ reporting it so far
[21:20] <Sarvatt> your dmesg to see what's happening at startup would be useful
[21:21] <penguin42> ok, let me just switch back to the kernel without my debug in
[21:21] <penguin42> Sarvatt: I'd thought Dave's post to lkml/dri-devel today sounded promising though - but I think I've patched that in to my build and it hasn't helped
[21:22]  * Sarvatt takes a look
[21:24] <Sarvatt> penguin42: just curious, have you tried 6.13.2 from here? https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
[21:24] <penguin42> no, I haven't but can do
[21:29] <penguin42> Sarvatt: You want the bug against xserver-xorg-video-ati ?
[21:30] <Sarvatt> penguin42: if you have that 6.13.2 installed then just xorg since it wont let you
[21:30] <Sarvatt> xorg and xserver-xorg-video-ati attach the same info
[21:31] <Sarvatt> can just move it over after
[21:31] <penguin42> Sarvatt: Well I was just going to report it with the standard stuff first and then try 6.13.2
[21:32] <Sarvatt> sounds good, thanks for that since if we upstream it they're going to ask you to try newer :)
[21:36] <penguin42> Sarvatt: OK, bug 656522
[21:36] <ubot4> Launchpad bug 656522 in xserver-xorg-video-ati (Ubuntu) "drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! from google-maps in chromium-browser (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656522
[21:42] <penguin42> Sarvatt: Still does it with 6.13.2-0ubuntu1~xup1
[22:30] <Sarvatt> penguin42: hmm, that bug is proving tricksy to track down, you really are running out of memory somewhere. have you tried disabling the memory remap option in bios by any chance? your bios looks to be full of all kinds of iommu fail
[22:31] <penguin42> Sarvatt: I can try, not sure if it has any options for that - what makes you say it has lots of iommu fail; I know it has plenty of intremap fail :-(
[22:31] <Sarvatt> that ^
[22:31] <penguin42> what?
[22:32] <Sarvatt> 1.50	9/15/2009	Instant Flash	874.94KB	1. Modify for Intel HD Audio.
[22:32] <Sarvatt> 2. Change 'Memory Remap Feature' function default = 'Enabled'.
[22:32] <Sarvatt> the interrupt remapping problems
[22:32] <penguin42> ok, will try that - what does it actually do?
[22:33] <penguin42> hang on; aren't interrupt and memory remapping separate things?
[22:33] <Sarvatt> its all in intel-iommu
[22:33] <penguin42> what's memory remapping?
[22:33] <Sarvatt> magic that breaks thing very often :)
[22:34] <penguin42> ah; I had noticed that I only get 256MB of the cards memory mapped into the PCI-bar -b ut that's a limit of PCI bars isn't it?
[22:34] <Sarvatt> http://en.wikipedia.org/wiki/IOMMU explains it better than i ever could
[22:38] <penguin42> is there a way to see how much ttm memory is allocated/in use?
[22:43] <RAOF>  /sys/kernel/debug/dri/0/gem_objects should be a reasonable proxy, I think.
[22:43] <Sarvatt> not sure off the top of my head, there might be something ttm specific in debugfs?
[22:44] <penguin42> Sarvatt: I don't see an option for IOMMUI
[22:44] <penguin42> IOMMU or remapping in the bios
[22:45] <penguin42> only turning VT or VT-d on and off
[22:45] <Sarvatt> no memory remap option? VTd?
[22:45] <penguin42> no memory remap option; there is a VT-d option - is that related?
[22:45]  * penguin42 has just flipped an option for the default graphics card type from PCI to PCI-e but I think that's just for selecting between multiple cards
[22:47] <Sarvatt> yeah thats DMAR and interrupt remapping, really this is magic to me that i just see pop up as broken in bug reports often :)
[22:47] <penguin42> the interrupt remapping is some VT related stuff; so VT-d might be involved but I haven't followed it well enough
[22:48] <penguin42> right, so starting kde with desktop effects enabled and gem_objects says 874 objects, 100MB object bytes 0 pinned, 0 pin bytes, 0 gtt bytes, 0 gtt total
[22:49] <penguin42> starting chromium with no pages loaded and that's upto 993/128MB
[22:49] <Sarvatt> it just sounds like theres some artificial size barrier along the way giving you the ENOMEM
[22:49] <penguin42> zooming in and we're at 206MB
[22:50] <penguin42> zoomed out hit 430MB, so maybe it did flip over 512MB?
[22:51] <Sarvatt> sheesh, filled up that fast?
[22:51] <penguin42> yeh
[22:51] <penguin42> zooming out in particular
[22:52] <Sarvatt> is it going down or going over the limit ever? did it crash already?
[22:52] <penguin42> it's also being very jerky, not fuilly repainting and stuff - it's not happy
[22:52] <penguin42> yeh it does go down a bit
[22:52] <penguin42> it's not completing a redraw, I'm getting the satellite imagery but none of the overlays
[22:54] <Sarvatt> i think theres ttm info somewhere in debugfs, +EXPORT_SYMBOL(ttm_page_alloc_debugfs);
[22:55] <penguin42> I have a ttm_page_pool
[22:55] <penguin42> the only none-0 line curently reads wc refuills 267 freed 0 size: 136704
[22:57] <penguin42> 635125760 object bytes
[22:58] <RAOF> A mere 600MB
[22:58] <penguin42> on a 512MB card
[22:58] <RAOF> Which would be a problem, if ttm isn't evicting pages properly.
[22:59] <RAOF> If it was working properly that wouldn't be too much of an issue.  Unless you actually need to be texturing from all 600MB there, in which case performance will die.
[22:59] <penguin42> I mean this is kind of a nice bug in the sense that I can trigger it in seconds, except that I have to login to KDE to do it
[23:02] <Sarvatt> cant reproduce it in gnome?
[23:03] <penguin42> Sarvatt: I have done once, although I haven't tried turning on desktop effects in gnome (I have them on in KDE)
[23:04] <Sarvatt> what do you use normally?
[23:05] <penguin42> gnome without desktop effects
[23:05] <penguin42> I'll just go and get something to eat; back in 15mins; but I'll give Gnome+desktop effects a go and see if it breaks
[23:05] <Sarvatt> gnome with effects would be interesting
[23:06] <Sarvatt> :) food! good idea
[23:15]  * penguin42 tries KDE every so often, it's getting closer to what I like but it's model of using storage devices just doesn't work for me since KDE4
[23:18]  * penguin42 files a PA bug - switching from KDE to Gnome leaves PA broken
[23:22] <penguin42> right
[23:22] <penguin42> oh god, wobbly windows
[23:26] <penguin42> Sarvatt: I can't quite get it to pop, even with full desktop effects
[23:27] <penguin42> (In gnome)
[23:27] <penguin42> The amount of space is still big, but not as big and it's obviously still got redraw issues
[23:44]  * penguin42 comes to the conclusion that the daily chromium builds are using GL in some way where as the standard set aren't
[23:47] <RAOF> I think that is the case, yeah.
[23:48] <penguin42> the standard repo chromium is fine