[10:03] <mlankhorst> RAOF/bryceh: What would it take to create a drm backport for 3.7? Although I fear the delta might be too big because of the defered fput changes which made it into 3.6
[11:34] <tjaalton> mlankhorst: difficult, because of the agp changes (which is builtin)
[11:34] <mlankhorst> yeah was afraid of that :/
[11:35] <tjaalton> dunno if it would be possible to revert them from drm
[11:35] <mlankhorst> oh right that's why it locks up, no defered fput
[11:36] <mlankhorst> maybe for r we can at least advertise some support for hybrid graphics then
[11:38] <tjaalton> hopefully gnome will have some support as well
[11:39] <mlankhorst> for once i wish nvidia weren't so following and would just get into contact with me
[11:45] <tjaalton> what for?
[11:46] <mlankhorst> if the proposals I threw on the list would work for them or not
[11:47] <mlankhorst> but I fear that they're not replying either because 1. they don't care, 2. it would work for them, 3. afraid of backlash by replying publicly, 4. held back by lawyers form replying :/
[11:48] <mlankhorst> or a combination of those
[11:53] <tjaalton> the five patch series?
[11:54] <mlankhorst> yeah, mostly worried about the interface
[20:26] <Sarvatt> the agp changes are mostly intel stopping using intel_agp for newer stuff, could possible do a drm and just nouveau dkms? *note i haven't looked
[20:26] <Sarvatt> actually a large part of the intel_agp changes were just backported in 3.5.0-17
[20:31] <Sarvatt> https://lists.ubuntu.com/archives/quantal-changes/2012-October/010991.html
[21:10] <mlankhorst> Sarvatt: yeah but the defered fput which would fix hangs for prime are probably too deep to be backported
[21:15] <bjsnider> alright, i tested the latest vaapi code in vlc on ivb
[21:15] <bjsnider> so, using vaapi, 3 of 4 cpus are at approximately 10% but no higher. the 4th cpu is at approximately 20%
[21:16] <bjsnider> without vaapi, all 4 cpus are at 10-15%
[21:16] <mlankhorst> bjsnider: are you trying 1080p?
[21:16] <bjsnider> negative, not yet anyway
[21:17] <bjsnider> 720p x264 at about 5000k
[21:17] <mlankhorst> at that point vaapi starts to become interesting at least
[21:21] <bjsnider> alright, i tested mega-high bitrate 1080p x264, and here's the deal
[21:21] <bjsnider> with vaapi 3 cpus are at 10% or less, one cpu is at 40
[21:21] <bjsnider> without vaapi all 4 are at around 20
[21:22] <bjsnider> what i'd really like to do is test gstreamer but i haven't figured it out yet. also the code is for 0.10, not 1.0
[21:26] <mlankhorst> probably best to zap other cores during testing
[21:27] <mlankhorst> ~$ for n in /sys/devices/system/cpu/cpu*/online; do echo 0 | sudo tee -a $n; done
[21:43] <Sarvatt> bjsnider: might be a bit late for new libva :(
[21:46] <Sarvatt> oh vaapi code in vlc, helps to read all of the scrollback :)
[22:46] <bjsnider> Sarvatt, doesn't matter anyway, because libva 1.1.0 breaks the intel code, so we'd have to wait for another release of that
[23:30] <bjsnider> ok, i tested gstreamer-vaapi using playbin2. mega-high bitrate 1080p x264 file plays with all 4 cores at less than 10%
[23:33] <bjsnider> same file played in totem, which is gstreamer 1.0 and no vaapi -- all 4 cores spiking very high, at least one over 60% at all times
[23:34] <bandit-led> getting artifacts at startup after login to gnome-classic and frequent total lockups 
[23:34] <bandit-led> kernel 3.6 and 12.10 
[23:35] <bandit-led> x64'
[23:36] <bandit-led> bah looks like its updating to 304.43 let me tries that see if its fixed
[23:45] <bjsnider> ok, that was a fairer test. used playbin for both. all 4 cores at least twice as high without vaapi as with it