| kees | tomreyn: final version appears to be: https://lkml.org/lkml/2013/3/11/677 | 00:50 |
|---|---|---|
| tomreyn | thanks | 02:18 |
| tjaalton | tomreyn: huh? | 05:11 |
| tomreyn | <tjaalton> uploading -intel 2.21.4 | 05:12 |
| tomreyn | <tjaalton> yeah, it has that fix :) | 05:12 |
| tomreyn | ... is what i was referriing to | 05:12 |
| tjaalton | no | 05:12 |
| tjaalton | that was not the kernel.. | 05:13 |
| tomreyn | okay thanks | 05:14 |
| RAOF | tjaalton, Sarvatt: Sounds like glamor works for 1.14 & 1.13.x; we should keep radeonsi enabled in -edgers. | 06:47 |
| === ripps_ is now known as ripps | ||
| tjaalton | RAOF: oh cool | 07:14 |
| tjaalton | we still have it on raring too | 07:14 |
| tjaalton | but glamor needs an update? | 07:14 |
| tjaalton | hum, is it even in the archive? | 07:15 |
| tjaalton | what a mess :P | 07:15 |
| RAOF | tjaalton: Nope, not in the archive; that needs to be done ): | 07:41 |
| RAOF | :) | 07:41 |
| mlankhorst | ooh fun | 07:41 |
| mlankhorst | could it be made part of the xorg group? | 07:41 |
| tjaalton | i recently got an unreleased 8xxx series card, but it's not even si-based.. duh | 07:42 |
| tjaalton | el cheapo series | 07:42 |
| mlankhorst | :> | 07:43 |
| tjaalton | was disappointed for not being able to test this stuff.. even to just notice it's "utter failure" or whatever phoronix calls it this week | 07:43 |
| mlankhorst | hahah | 07:44 |
| tjaalton | mlankhorst: yeah it probably makes sense under pkg-xorg | 07:56 |
| mlankhorst | yeah if it does get MIR'd, I'll ask to get pixman and all the blob packages in the xorg package list too :) | 07:59 |
| tjaalton | oh that list, right | 08:00 |
| mlankhorst | but ok when you checked the race condition I'll upload xorg-server 1.13.3 :) | 08:05 |
| mlankhorst | brb | 08:06 |
| tjaalton | well, at least the git version doesn't break anything here | 08:07 |
| tjaalton | although if you need the race case tested then yes, within the next hour | 08:07 |
| mlankhorst | Lies! | 09:08 |
| tjaalton | hah | 09:10 |
| tjaalton | soon | 09:10 |
| tjaalton | disabled swap and eth0 bridge so it's actually able to hit it | 09:10 |
| mlankhorst | it should show something in the xorg log if you do hit it | 09:11 |
| tjaalton | first I'll try with the current one | 09:11 |
| tjaalton | mlankhorst: ok, I have the current package obviously doing something there, now trying the new one | 09:57 |
| tjaalton | ooh, reproduce the race with it | 09:58 |
| tjaalton | +d | 09:58 |
| mlankhorst | does it survive? | 09:59 |
| tjaalton | no | 09:59 |
| mlankhorst | ah boo, logs? | 09:59 |
| tjaalton | low-graphics mode | 09:59 |
| tjaalton | http://pastebin.com/ebwTGe1C | 10:00 |
| tjaalton | here's the previous one http://pastebin.com/yRpBX0jA | 10:01 |
| mlankhorst | it's happy about it though | 10:02 |
| mlankhorst | afaict | 10:02 |
| mlankhorst | so where does it go wrong? :S | 10:03 |
| tjaalton | beats me | 10:04 |
| mlankhorst | can you paste correct log too? | 10:04 |
| tjaalton | with this kernel? | 10:05 |
| tjaalton | um, xserver | 10:05 |
| mlankhorst | sure | 10:05 |
| * mlankhorst has the feeling it fails somewhere else in a similar fashion | 10:05 | |
| tjaalton | this matches my old tests, so there's nothing new | 10:05 |
| mlankhorst | [ 5.162] (II) intel(G0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen <tjaalton@ubuntu.com>) | 10:07 |
| mlankhorst | is it a hybrid? | 10:07 |
| tjaalton | no | 10:07 |
| tjaalton | ivb sdp | 10:07 |
| tjaalton | the package is from the archive | 10:08 |
| tjaalton | here's a working one http://pastebin.com/kYRdDYv4 | 10:08 |
| mlankhorst | it's saying G0 though | 10:09 |
| mlankhorst | which is weird | 10:09 |
| mlankhorst | iirc that was graphics offload | 10:10 |
| * mlankhorst rechecks | 10:11 | |
| tjaalton | just (0) with the working one | 10:11 |
| mlankhorst | yeah but what is it trying to bind to.. | 10:13 |
| mlankhorst | [ 4.779] (==) Matched intel as autoconfigured driver 0 | 10:13 |
| mlankhorst | [ 4.779] (==) Matched intel as autoconfigured driver 1 | 10:13 |
| mlankhorst | o.O | 10:13 |
| mlankhorst | oh well, both have that | 10:14 |
| tjaalton | when it fails plymouth doesn't have a chance of showing the splash, it's showing vt1 instead | 10:15 |
| tjaalton | but still would like to try with it disabled, can't remember what to put on cmdline | 10:16 |
| tjaalton | removing splash isn't enough | 10:16 |
| tjaalton | plymouth.enable=0, maybe | 10:18 |
| mlankhorst | tjaalton: what if you remove the drmSetMaster call from plymouth? :p | 10:20 |
| mlankhorst | it will probably fail | 10:20 |
| mlankhorst | just checking if the race is gone then | 10:20 |
| tjaalton | I'll try without plymouth a few times, first was successful | 10:22 |
| mlankhorst | or something like in activate if (!ply_terminal_is_active (backend->terminal)) return; | 10:22 |
| mlankhorst | probably src/plugins/renders/drm/plugin.c or something | 10:22 |
| mlankhorst | that should hopefully be enough to prevent it from stealing master | 10:22 |
| tjaalton | ha, failuer | 10:24 |
| tjaalton | -re | 10:24 |
| mlankhorst | when | 10:24 |
| tjaalton | [ 4.765] drmSetMaster failed with -1(Operation not permitted) | 10:24 |
| tjaalton | without plymouth | 10:24 |
| mlankhorst | o.O | 10:25 |
| tjaalton | http://pastebin.com/HzXGPRMS | 10:26 |
| mlankhorst | oh duh | 10:28 |
| mlankhorst | drmsetmaster doesn't return err code | 10:28 |
| mlankhorst | tjaalton: pushed new version | 10:30 |
| mlankhorst | my guess is it will fail with -EINVAL, lets see >:X | 10:31 |
| mlankhorst | I'm hoping for -EINVAL, in fact | 10:32 |
| mlankhorst | if so, I'll ask you to test a kernel patch | 10:33 |
| tjaalton | building | 10:36 |
| tjaalton | bah, plymouthd _was_ still running, I'll disable it harder | 10:40 |
| mlankhorst | that's fine, I just want that error again :P | 10:41 |
| tjaalton | alright | 10:41 |
| tjaalton | [ 4.901] drmSetMaster failed with 22(Invalid argument) | 10:43 |
| mlankhorst | yay | 10:43 |
| mlankhorst | let me grab the raring kernel | 10:43 |
| tjaalton | guess I need it too?-) | 10:44 |
| tjaalton | oh I have it.. | 10:44 |
| mlankhorst | is a .patch good enough? | 10:44 |
| tjaalton | yep | 10:44 |
| mlankhorst | tjaalton: http://paste.ubuntu.com/5607392/ | 10:50 |
| mlankhorst | blergh should probably have fixed it, missing fops_put(old_fops); ah well | 10:52 |
| mlankhorst | wont be able to load drm module :p | 10:52 |
| tjaalton | the last hunk failed to apply | 10:53 |
| mlankhorst | I'll try 3.8 ish | 10:53 |
| mlankhorst | applies cleanly against 3.8.0 here | 10:54 |
| mlankhorst | http://paste.ubuntu.com/5607407/ | 10:57 |
| tjaalton | not -12.21 | 10:57 |
| mlankhorst | is that 3.8 kernel? | 10:57 |
| tjaalton | yep | 10:57 |
| tjaalton | maybe .2 or such | 10:58 |
| mlankhorst | I'll try v3.8.x branch then | 10:58 |
| mlankhorst | still applies cleanly o.O | 10:59 |
| mlankhorst | just apply with hand, it's a small patch | 10:59 |
| mlankhorst | idea is that f_op gets replaced only once, and not reset on failure | 11:00 |
| mlankhorst | and then it drops drm_global_mutex before calling f_op->open | 11:00 |
| mlankhorst | drm_open re-takes global_mutex to prevent races | 11:00 |
| tjaalton | hah | 11:01 |
| tjaalton | UBUNTU: SAUCE: drm -- stop early access to drm devices | 11:01 |
| tjaalton | that's a nearly three year old patch.. | 11:01 |
| tjaalton | why it didn't apply | 11:02 |
| tjaalton | mind reviewing that one? | 11:02 |
| mlankhorst | zap it | 11:03 |
| mlankhorst | this solution *should* work better | 11:03 |
| tjaalton | and apply yours? | 11:03 |
| mlankhorst | yeah | 11:03 |
| tjaalton | k | 11:03 |
| tjaalton | wonder if that patch is what's causing the race in the first place.. | 11:04 |
| mlankhorst | nah it's a fail attempt to work around it | 11:04 |
| mlankhorst | then again maybe | 11:04 |
| mlankhorst | though I would expect open to fail in that case with -EAGAIN | 11:05 |
| tjaalton | don't recall having this bug before maybe a year ago | 11:05 |
| mlankhorst | I think it would still fail with that workaround because it's not complete | 11:06 |
| mlankhorst | just taking global mutex seems to be a reasonable fix :p | 11:06 |
| mlankhorst | it could otherwise return the second open call before firstopen is called in drm | 11:07 |
| tjaalton | building | 11:09 |
| mlankhorst | hm or worse, possibly before load finishes | 11:10 |
| mlankhorst | only it wouldn't happen on first open, but if 2 devices open in parallel, like xorg and plymouth | 11:11 |
| mlankhorst | first one would nicely block on global_mutex, second one would race ahead without any locking at all | 11:12 |
| tjaalton | hmm no kms on vt | 11:31 |
| mlankhorst | o.O | 11:31 |
| mlankhorst | drm failed to load? | 11:31 |
| tjaalton | no it was fine | 11:31 |
| tjaalton | second boot, kms fine, vt change and the mouse cursor follows :) | 11:32 |
| tjaalton | and can't find the greeter again | 11:33 |
| tjaalton | restart lightdm and it's fine | 11:34 |
| tjaalton | ha, failure | 11:37 |
| mlankhorst | was afraid of that, meh :/ | 11:38 |
| tjaalton | mlankhorst: same as before | 11:38 |
| mlankhorst | still -EINVAL? | 11:38 |
| tjaalton | yep | 11:38 |
| mlankhorst | on setmaster right? | 11:38 |
| tjaalton | [ 4.856] (II) config/udev: Adding drm device (/dev/dri/card0) | 11:38 |
| tjaalton | [ 4.856] drmSetMaster failed with 22(Invalid argument) | 11:38 |
| tjaalton | [ 4.861] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64 | 11:38 |
| mlankhorst | was afraid of that | 11:39 |
| mlankhorst | tjaalton: could you add a printk to drm_setmaster_ioctl to find out which exactly it triggers on? | 11:40 |
| tjaalton | where? | 11:40 |
| mlankhorst | drm_stub.c | 11:40 |
| === MonsterKiller_ is now known as MonsterKiller | ||
| mlankhorst | I'm hoping it's complaining about file_priv->minor->master, in which case I should revive the first part of bryce's attempt | 11:49 |
| tjaalton | building | 11:49 |
| mlankhorst | or better yet, plymouth should not call drmsetmaster and just bug out early if it didn't get master, it lost to xorg-server :P | 11:50 |
| tjaalton | or just wait for the system compositor.. | 11:51 |
| mlankhorst | http://paste.ubuntu.com/5607513/ | 11:57 |
| mlankhorst | could you try that? | 11:58 |
| tjaalton | so not the printk stuff? | 11:59 |
| mlankhorst | could keep it, but this is for plymouth to not take master if not on active vt | 11:59 |
| mlankhorst | at least, I guess it works like that | 11:59 |
| === popey_ is now known as popey | ||
| tjaalton | mlankhorst: didn't try the plymouth patch yet, but the failing check was "if (file_priv->minor->master)" | 12:20 |
| mlankhorst | good, plymouth one is probably the fix | 12:21 |
| mlankhorst | I hope | 12:21 |
| tjaalton | funny that it follows the same pattern. first boot I get the cursor-on-vt issue, second one is fine, third one fails | 12:21 |
| tjaalton | fails with failsafe (hah) | 12:22 |
| mlankhorst | resetting or full power off? | 12:23 |
| tjaalton | reset | 12:23 |
| tjaalton | mlankhorst: nope, still failed | 12:30 |
| mlankhorst | I guess I'll revive the spin patch on setmaster then | 12:31 |
| mlankhorst | pushed | 12:41 |
| mlankhorst | tjaalton: can you retest xorg-server with the patch refreshed patch? | 12:42 |
| tjaalton | building | 12:43 |
| tjaalton | hm, it's probably not normal that on nearly every boot I have dmesg full of ext4_orphan_cleanup | 12:50 |
| tjaalton | ..messages | 12:50 |
| tjaalton | [ 4.888] (II) config/udev: Adding drm device (/dev/dri/card0) | 12:55 |
| tjaalton | [ 4.888] (II) spinning! | 12:55 |
| tjaalton | [ 5.111] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64 | 12:55 |
| tjaalton | works | 12:55 |
| mlankhorst | \o/ | 12:55 |
| mlankhorst | now reset the rest to previous state, and see if it still works? | 12:56 |
| mlankhorst | eg default plymouth and kernel | 12:57 |
| tjaalton | yep | 12:57 |
| mlankhorst | * radeon_driver_firstopen_kms - drm callback for last close | 13:00 |
| mlankhorst | void radeon_driver_lastclose_kms(struct drm_device *dev) | 13:00 |
| mlankhorst | :D | 13:00 |
| tjaalton | works | 13:14 |
| tjaalton | now I have the mouse cursor on top of a vt (blinking cursor on top-left), heard the bongos | 13:17 |
| tjaalton | it didn't spin, but the intel driver spent half a second on "something" | 13:18 |
| tjaalton | [ 4.950] (++) using VT number 7 | 13:18 |
| tjaalton | [ 5.451] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen <tjaalton@ubuntu.com>) | 13:18 |
| mlankhorst | could it be plymouth? :P | 13:18 |
| tjaalton | could, I enabled it again | 13:19 |
| tjaalton | booted fine a couple of times | 13:19 |
| mlankhorst | presumably plymouth shouldn't attempt to attach if xorg-server ended up starting | 13:19 |
| mlankhorst | could you try with the plymouth patch? | 13:20 |
| tjaalton | now I just got a blank screen | 13:22 |
| mlankhorst | fun :/ | 13:22 |
| tjaalton | root 1638 1339 0 15:21 ? 00:00:00 plymouth --ping | 13:22 |
| tjaalton | plymouth doesn't exit | 13:23 |
| mlankhorst | can you attach to plymouthd, see if it's stuck on something? | 13:23 |
| tjaalton | [+0.01s] DEBUG: Waiting for ready signal from X server :0 | 13:23 |
| tjaalton | [+0.01s] DEBUG: Stopping Plymouth, no displays replace it | 13:23 |
| tjaalton | from lightdm.log | 13:24 |
| tjaalton | ply_terminal_deactivate_vt | 13:25 |
| tjaalton | http://pastebin.com/C9wvXrF9 | 13:25 |
| tjaalton | I need to run -> | 13:25 |
| mlankhorst | boo it needs debug symbols | 13:30 |
| mlankhorst | oh that's from lightdm | 13:32 |
| mlankhorst | blargh I need some way to reproduce this if I want to fix it :/ | 13:40 |
| mlankhorst | boooo this one's too slow | 13:54 |
| === ogra_` is now known as ogra_ | ||
| === yofel_ is now known as yofel | ||
| === maxb_ is now known as maxb | ||
| Sarvatt | https://bugs.freedesktop.org/show_bug.cgi?id=62198 gen3 possibly messed up in x-x-v-intel 2.21.4 if anyone comes across corruption bugs on them | 18:22 |
| ubottu | Freedesktop bug 62198 in Driver/intel "x11-drivers/xf86-video-intel-2.21.4 and transparency" [Normal,Reopened] | 18:22 |
| tjaalton | i'll check it out | 18:24 |
| tjaalton | or maybe not | 18:24 |
| tjaalton | forget 965gm is gen4 | 18:24 |
| mlankhorst | my eee is gen 3 :P | 18:25 |
| mlankhorst | I'll test tomorrow | 18:25 |
| Sarvatt | Duke`_: probably what you're hitting | 18:29 |
| Duke`_ | hum the last two updates seems ok for me | 18:34 |
| Duke`_ | I remember having a glxgears with transparent background, instead of black | 18:36 |
| Duke`_ | ok, I just installed 2.21.4, going to reboot | 18:39 |
| Sarvatt | Duke`: ah sorry, another bug then | 18:41 |
| Sarvatt | i updated edgers right after you complained in case it was a transient bug, so much changes every day and i hadn't for a week | 18:42 |
| Duke` | eh ;) | 18:42 |
| Duke` | the 20130301 version was terrible, X totally broken | 18:43 |
| Duke` | black screen and it was hard to switch to a VT | 18:44 |
| burp | dear ubuntu-x people | 20:41 |
| burp | nvidia-current 304.84 in the precise ubuntu-x-swat PPA depends on xserver-xorg-core | 20:42 |
| burp | but the new https://wiki.ubuntu.com/Kernel/LTSEnablementStack depends on xserver-xorg-core-lts-quantal | 20:42 |
| burp | so they can't be readily installed together | 20:43 |
| burp | (and maybe shouldn't :) | 20:43 |
| burp | I haven't been able to find any more information on this | 20:44 |
| burp | except these gentlemen on askubuntu who ran into the problem: http://askubuntu.com/a/257889 | 20:44 |
| burp | will ubuntu-x-swat stick with the current situation, or are there plans for compatibility with the LTSEnablementStack? | 20:44 |
| jcristau | what does the lts stack buy you if you're using nvidia's driver anyhow? | 20:46 |
| burp | I'm not sure yet. :) | 20:47 |
| burp | but currently if you install bumblebee on a 12.04.2 system, X doesn't startup anymore | 20:48 |
| burp | that would be reason #1 to clear things up | 20:48 |
| burp | also, bumblebee systems have Intel graphics as wel | 20:48 |
| burp | l | 20:48 |
| burp | (the LTSEnablementStack seems to be default on new 12.04.2 installs. I just got burned by this problem.) | 20:49 |
| Sarvatt | sudo apt-get install xserver-xorg-lts-precise :) | 20:49 |
| bryce | yeah bumblebee should probably update their depends | 20:50 |
| Sarvatt | that'll downgrade you back to the older stack | 20:50 |
| burp | it's not bumblebee | 20:50 |
| burp | bumblebee only depends on nvidia-current | 20:50 |
| burp | but nvidia-current depends on xserver-xorg-core | 20:50 |
| burp | is there no solution possible where the enablement stack is also supported? | 20:50 |
| tjaalton | don't use the ppa? | 20:51 |
| burp | one needs the PPA if one has a NVIDIA 7xx no? | 20:51 |
| burp | (this laptop has NVIDIA GeForce 710m) | 20:51 |
| bryce | burp, ah. mlankhorst was working on getting that resolved. Check with him. | 20:51 |
| tjaalton | well there are other versions available on precise | 20:52 |
| tjaalton | if bumblebee depends on nvidia-current then fix that | 20:52 |
| Sarvatt | the nvidia driver is whats messed up in the ppa | 20:52 |
| tjaalton | sure | 20:53 |
| tjaalton | but why use the ppa? | 20:53 |
| Sarvatt | bjsnider: ya didnt pick up tseliot's recent packaging changes it looks like | 20:53 |
| Sarvatt | because newer blob drivers actually are worth upgrading to? :P | 20:53 |
| tjaalton | and there's nvidia-310, no? | 20:53 |
| Sarvatt | 304.84 is still newer | 20:54 |
| tjaalton | probably doesn't matter for this hw? | 20:54 |
| burp | so should I not want to install the latest nicely packaged nvidia binary drivers on this Ivy Bridge i7 with NVIDIA GeForce 710m in Optimus configuration? | 20:55 |
| Sarvatt | it fixes a kde logout problem, xrandr rotation, and speeds up font rendering, perfectly valid reasons to want to update it.. | 20:55 |
| burp | It felt like a logical thing to do at the time. | 20:55 |
| tjaalton | ok then, so wait for it to get fixed :) | 20:56 |
| burp | :) | 20:56 |
| Sarvatt | thanks for the heads up it was broken | 20:56 |
| burp | I should probably double-check if it has been reported and if not report it, no? | 20:56 |
| Sarvatt | burp: nah its not a distro bug, reporting it here was right :) | 20:56 |
| burp | ok great thanks! | 20:57 |
| Sarvatt | bjsnider: patch incoming for fixing the precise blob depends | 21:11 |
| Sarvatt | bjsnider: http://paste.ubuntu.com/5608946/ | 21:12 |
| Sarvatt | burp: just uploaded it, should be up in a few hours | 21:18 |
| burp | wow, that's awesome, thank you very very much! | 21:19 |
| bjsnider | Sarvatt, is it just in precise? | 21:24 |
| mlankhorst | bjsnider: it's only needed for precise, unless you want to backport the enablement stack to quantal ;)( | 21:25 |
| Sarvatt | bjsnider: yeah, its a pain in the rear i know :( | 21:26 |
| mlankhorst | but you could probably harmlessly sync those changes back to later | 21:26 |
| Sarvatt | could just make them all except precise then make the precise at the end slapping that patch on though | 21:26 |
| Sarvatt | mlankhorst: except he's still doing lucid blobs even :) | 21:27 |
| mlankhorst | o.o | 21:27 |
| Sarvatt | would need to extend the number of abis it provides | 21:27 |
| mlankhorst | not for much longer? | 21:27 |
| bjsnider | burp, you have which chip? | 21:27 |
| bjsnider | i can't find a record of that one | 21:27 |
| Sarvatt | bjsnider: rebadged 620m | 21:28 |
| burp | http://www.notebookcheck.net/NVIDIA-GeForce-710M.84746.0.html | 21:28 |
| bjsnider | he shouldn't be using the ppa then | 21:28 |
| bjsnider | too new | 21:28 |
| bjsnider | only geforce 6k/7k hardware | 21:29 |
| burp | I shouldn't? | 21:29 |
| Sarvatt | burp: does it work? :P | 21:29 |
| burp | hehehe | 21:29 |
| burp | it seems to! | 21:29 |
| burp | I'm only just installing the thing | 21:30 |
| burp | but optirun glxspheres is doing the right thing much faster than the intel is doing it | 21:31 |
| Sarvatt | -310 probably doesn't even work on it since the one in precise is so old | 21:31 |
| bryce | good sign | 21:31 |
| bryce | Sarvatt, :-/ | 21:31 |
| burp | cancel that | 21:32 |
| burp | actually the intel with vblank_mode=0 is much faster than than optirun | 21:32 |
| mlankhorst | hah | 21:32 |
| Sarvatt | try optirun glxinfo and see if it says nvidia | 21:33 |
| burp | it does :) | 21:33 |
| burp | OpenGL Renderer: GeForce 710M/PCIe/SSE2 | 21:33 |
| burp | vs OpenGL Renderer: Mesa DRI Intel(R) Ivybridge Mobile | 21:33 |
| burp | nvidia gives 120+ frames per second | 21:33 |
| burp | intel almost 200 | 21:34 |
| burp | :) | 21:34 |
| burp | I sure hope that nvidia is sleeping most of the time | 21:34 |
| mlankhorst | it has to copy twice | 21:34 |
| burp | shees I should probably get me a real irc client | 21:34 |
| mlankhorst | nobody said optimus worked well | 21:34 |
| * mlankhorst tests on lapptop | 21:34 | |
| Sarvatt | on a real app it'd probably be much better :) | 21:35 |
| burp | I'm just happy that there's something with which I can keep it sleeping | 21:35 |
| burp | lemme try primus just for reference | 21:36 |
| burp | a much more respectable 160+ frames per second | 21:36 |
| burp | I'm actually really happy with this cheapskate performance laptop so far | 21:38 |
| burp | if anyone's interested | 21:38 |
| burp | Acer V3 571G with Full HD IPS display (very pretty), Intel i7 quad core (real quad), 8G RAM and big slow hard disk for 800 eurobucks | 21:38 |
| burp | seems to run ubuntu 12.04.2 fine! | 21:38 |
| burp | (no I'm not selling) | 21:39 |
| * mlankhorst wonders where you get glxspheres from | 21:39 | |
| Sarvatt | mesa demos, we just dont package it | 21:39 |
| mlankhorst | ah | 21:39 |
| burp | jeez | 21:39 |
| burp | on this system it seems to come from virtualgl | 21:39 |
| * mlankhorst builds | 21:39 | |
| * burp wonders what IRC client is en vogue these days | 21:40 | |
| burp | irssi still? or something else? | 21:40 |
| Sarvatt | oh nope, its packaged with virtualgl | 21:40 |
| mlankhorst | icechat? | 21:40 |
| burp | err, seems to be windows? | 21:41 |
| mlankhorst | dno | 21:41 |
| burp | it does say "the chat cool people use" | 21:41 |
| burp | I see what they did there | 21:42 |
| mlankhorst | hm guess you're right | 21:46 |
| mlankhorst | ugh c# too | 21:46 |
| mlankhorst | 275.781442 frames/sec - 289.647733 Mpixels/sec | 21:49 |
| burp | what graphics? | 21:49 |
| mlankhorst | radeon and i915 | 21:49 |
| Sarvatt | 76.287995 frames/sec - 80.123756 Mpixels/sec whee ultrabook hd4000 :) | 21:51 |
| mlankhorst | was with DRI_PRIME=1 so it rendered on the radeon | 21:52 |
| * mlankhorst tries i915 | 21:52 | |
| mlankhorst | erm native radeon* | 21:52 |
| Sarvatt | oh 32 bit version is much faster | 21:54 |
| mlankhorst | how do I kill off vblank? | 21:55 |
| Sarvatt | vblank_mode=0 | 21:55 |
| mlankhorst | that doesn't seem right :p | 21:55 |
| mlankhorst | oh.. right, no syncing between i915 and radeon probably | 21:56 |
| Sarvatt | isn't that what you're working on........? | 21:56 |
| * Sarvatt coughs | 21:56 | |
| mlankhorst | it's tear free! | 21:57 |
| mlankhorst | but that doesn't mean userspace performs its own sync correctly | 21:57 |
| Sarvatt | woohoo, starcraft 2: heart of the swarm time :) | 21:57 |
| Sarvatt | lets see if this bugger works in wine | 21:58 |
| mlankhorst | Sarvatt: anyway syncing should work tear free, but if both ddx drivers don't tell that they wrote or read something, you could have 2 reads off the same frame | 22:00 |
| mlankhorst | so it shows as higher fps ;P | 22:01 |
| * mlankhorst will be sure to break wine this friday | 22:01 | |
| RAOF | mlankhorst: Hey, do you know off hand what would happen if I close() a prime dma-buf fd after importing it? Do I lose access to that buffer? | 22:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!