RAOF | Among other things I think that steam does some GL vendor string parsing and freaks out about gallium drivers. | 00:00 |
---|---|---|
RAOF | The nouveau drivers would be pretty featureful, but significantly less stable. | 00:01 |
RAOF | And significantly less fast, too. | 00:01 |
lifeless | brb | 00:05 |
lifeless | right, where was I | 00:08 |
lifeless | oh yes | 00:08 |
RAOF | In Sacrifice? | 00:08 |
lifeless | heh | 00:10 |
lifeless | so in lucid | 00:11 |
RAOF | Cedega fullscreen being off by a couple of issues is likely to be either (a) cedega's fault or (b) a VGA connector issue. | 00:11 |
lifeless | and I just upgraded my games machine, so its new | 00:11 |
lifeless | when it goes fullscreen, most of the time, its offset to the bottom-right | 00:12 |
lifeless | *but the desktop shows in the gap* | 00:12 |
RAOF | Ah. Silly cedega. | 00:13 |
lifeless | worked in karmic | 00:13 |
Sarvatt | intels gpu's are such crap noone would buy a seperate card and they know it :) | 00:14 |
RAOF | And it turned out doing a GPU in software on top of a bunch of tiny x86 cores wasn't as easy as they thought, too. | 00:16 |
RAOF | Worked in Karmic, eh? | 00:16 |
lifeless | RAOF: this occurs with both i915 or whatever my laptop has, and the nvidia in my games machine | 00:16 |
lifeless | RAOF: and it was pixel perfect yesterday morning before the upgrade | 00:16 |
Sarvatt | what upgrade? | 00:17 |
lifeless | karmic-lucid | 00:17 |
lifeless | my games machine was shipped transtasmin so this was the first chance to do it | 00:17 |
lifeless | http://imagebin.org/100511 | 00:17 |
lifeless | RAOF: ^ | 00:17 |
RAOF | I think this is unlikely to be an X problem. | 00:17 |
lifeless | shows both the offset, and the other thing I wanted to query you on | 00:17 |
RAOF | Oh, a third thing? :) | 00:18 |
lifeless | yes | 00:18 |
lifeless | choosepixelformat failed | 00:18 |
lifeless | which google tells me was fixed in 2006 with glx1.3 | 00:19 |
lifeless | and glxinfo claims the nvidia driver is glx1.4 | 00:19 |
lifeless | whats particularly special is alt-tab to and from the fullscreen app aligns it correctly on the screen | 00:19 |
RAOF | I think google might be wrong, because the open drivers haven't been claiming glx1.3 support until… Lucid, until we disabled it. | 00:20 |
lifeless | well, I know that I know not, in this space. | 00:20 |
lifeless | I'm going to get a vanilla wine install of steam up | 00:20 |
lifeless | and see if its better | 00:21 |
Sarvatt | yeah that'd be the first thing i'd try too | 00:21 |
lifeless | though that itself appears to be black magic | 00:21 |
Sarvatt | ? it installs fine here | 00:22 |
Sarvatt | i'm in the process of installing counterstrike now in it | 00:22 |
Sarvatt | pretty sure you can just use the cedega one too since its just wine | 00:24 |
lifeless | blows up when I run regular wine on it | 00:25 |
lifeless | with WINE_ENV or whatever set | 00:25 |
lifeless | cleaner to start fresh, I think | 00:25 |
Sarvatt | looks like wine with the blob starts things at 60hz when it changes resolutions | 00:28 |
Sarvatt | the blob lies about what refresh rate you're at for its twinview crap | 00:28 |
Sarvatt | try adding Option"DynamicTwinView""false" to your xorg.conf? | 00:29 |
Sarvatt | found an old forums post from 07 with the same problem it looks like - http://ubuntuforums.org/showthread.php?t=629173 | 00:30 |
lifeless | I'm in awe of your googlejuice | 00:30 |
Sarvatt | wine fullscreen xserver 1.7 found it :) | 00:31 |
lifeless | ah | 00:31 |
lifeless | thats for the offset thing, not the pixel format | 00:31 |
lifeless | right | 00:31 |
Sarvatt | looks like disabling compiz will fix the choosepixelformat error | 00:33 |
lifeless | I have visual effects set to None already | 00:34 |
lifeless | I thought that disabled compiz ? | 00:35 |
Sarvatt | oh, darn :( | 00:35 |
Sarvatt | http://forums.steampowered.com/forums/showthread.php?t=1282981 | 00:36 |
Sarvatt | looks like it picks directx mode by default and that switched it to opengl so it works | 00:37 |
lifeless | that screenshot was set to gl mode :) | 00:38 |
lifeless | d3d mode goes boom | 00:38 |
lifeless | I'm pulling down cs in a fresh wine setup | 00:39 |
lifeless | will report back in a couple hours I guess | 00:39 |
lifeless | for now, bzr stuff awaits | 00:40 |
Sarvatt | intel needs a rebuild :( looks like the server was stuck in NEW | 02:17 |
Sarvatt | Provides: xserver-xorg-video-6 | 02:18 |
lifeless | RAOF: so, lucid wine does a bit better | 02:43 |
lifeless | Sarvatt: the twinview thing helped | 02:43 |
ripps | I'm trying to use ppa-purge to downgrade xorg-edgers to default maverick, but I'm having some kind of dependency problem with xserver-xorg-core and the virutal input packages. | 03:34 |
ripps | Sarvatt: ^ | 03:36 |
RAOF | ripps: Yes, you will. Not everything's built for the new server yet. | 03:36 |
ripps | RAOF: ah, okay. Any idea when they'll roll out? | 03:37 |
RAOF | Today. | 03:37 |
lifeless | RAOF: cedega is still naffed :-) chalk one up for open sores | 03:42 |
RAOF | Heh. | 03:43 |
lifeless | RAOF: now, just have to remove pulseaudio and everything should be happy again | 04:08 |
RAOF | Ok. Weirded out by that mesa backtrace. | 04:47 |
=== lifeless_ is now known as lifeless | ||
ntr0py | I have a very strange bug indicating gdm starts too early in upstart on lucid resulting in low graphics mode with nvidia-current installed via jockey... | 09:12 |
ntr0py | This is very irritating for people installing the suggested nvidia driver via jockey and on next reboot they get "ubuntu is running in low graphics mode" error message... | 09:15 |
bryceh | ntr0py, http://ubuntu.com/support | 09:16 |
ntr0py | To avoid the effect of this issue it is enough to delay the start of gdm for only 2 seconds on my system, but it leaves the causes (upstart race) untouched... | 09:17 |
ntr0py | bryceh: What should i do with your url?? | 09:23 |
bryceh | ntr0py, if your interest is merely in getting your machine working with lucid, there are plenty of support channels to go through. This is a development channel. | 09:25 |
ntr0py | bryceh: I do have a working machine with a the dirty hack avoiding the effects of this issue (delaying gdm start), but i think this is a bug in upstart (race condition). | 09:28 |
bryceh | then analyze it fully and submit a bug report (and perhaps a patch against the upstart rule if you're conversant in upstart) | 09:30 |
bryceh | however you might check if it's just that the nvidia kernel module didn't finish building before gdm tried to start X, which is already a known issue. | 09:32 |
bryceh | patches definitely welcomed on that one, as the number of developers who support the proprietary driver is pretty limited. | 09:33 |
bryceh | anyway, nite. | 09:33 |
RAOF | bryceh: Good night! | 09:33 |
ntr0py | bryceh: I did analyse it finding out the hack and tried adding something in /etc/init/gdm.conf ("and graphics-device-added nvidiactl PRIMARY_DEVICE_FOR_DISPLAY=1"), but unfortunately im not familiar enough with upstart to do this... | 09:34 |
RAOF | ntr0py: Something like that would be the way to do it, yeah. | 09:34 |
* RAOF is also off. | 09:34 | |
ntr0py | Any ideas how i could wait with gdm's start on nvidia module having build and beeing ready for use in upstart? | 09:38 |
seb128 | the current intel driver got built with the old xserver | 10:16 |
seb128 | should it be rebuilt to get the new abi? | 10:16 |
jcristau | yes. | 10:17 |
seb128 | is there a list of things that need to be rebuilt still somewhere? | 10:17 |
seb128 | jcristau, do you know if the rebuild is hold off for a reason or if I should just do a no change upload for it? | 10:18 |
jcristau | don't know of a reason you should hold off | 10:19 |
seb128 | ok thanks | 10:20 |
seb128 | I will let a bit for somebody to comment if there is a reason or do an upload in an hour otherwise | 10:20 |
jcristau | it's the middle of Sarvatt's night and RAOF said he was off an hour ago :/ | 10:21 |
seb128 | seems quite some other drivers didn't get rebuild though | 10:22 |
seb128 | let's give some build retries | 10:25 |
seb128 | soyuz depwait handling got turned off yesterday | 10:25 |
seb128 | they had issues with it since the new update | 10:26 |
bigjools | it's coming back RSN :) | 10:26 |
seb128 | how rsn is? | 10:26 |
bigjools | it's getting cherry picked right now | 10:26 |
seb128 | which means it will land in production today? | 10:27 |
seb128 | ie it will be active once cherry picked? | 10:27 |
seb128 | or does it still need to wait a rollout? | 10:27 |
bigjools | it'll be in production when it's picked | 10:27 |
seb128 | ok thanks | 10:27 |
seb128 | I will stop to manually retry all the drivers then | 10:28 |
asac | whats the story about gallium driver? what benefit/use case is that targetting? | 13:24 |
RAOF | seb128: I've got a set of no-change rebuilds locally plus a new siliconmotion upstream to build against 1.8. You're welcome to retry or upload no-change rebuilds for all the video drivers. | 13:30 |
seb128 | RAOF, seems they fixed depwait now | 13:32 |
seb128 | RAOF, do you plan to upload your no change rebuilds? | 13:32 |
RAOF | I don't have upload rights for them. I was going to beg for for sponsorship from Luke tomorrow. | 13:33 |
seb128 | do you have them ready somewhere? | 13:34 |
RAOF | Yeah. I'll put them on my webserver | 13:34 |
seb128 | so it's just debsign and upload? | 13:34 |
RAOF | Right. | 13:34 |
seb128 | can you give the url on #ubuntu-desktop? | 13:35 |
ripps | grr... still can't downgrade from xorg-edgers yet... when are they gonna finish building those packages. | 13:37 |
RAOF | asac: The gallium architecture is meant to make it easier to write graphics drivers for modern cards. The idea is basically to have a low-level architecture which maps easily to modern graphics chips (which are all about programmable stuff) that you can build APIs on top of (OpenGL, OpenVG, DirectX, etc) | 13:40 |
asac | RAOF: so is that something that will become interesting for ARM (or already is?) | 13:45 |
jcristau | as long as arm means sgx... | 13:46 |
asac | ok so its vendor responsibility to make that happen i guess ... | 13:47 |
asac | but is that of benefit for us? | 13:47 |
asac | e.g. should i go to vendors and tell them to do gallium? | 13:47 |
RAOF | Only if it makes sense for their hardware. | 13:48 |
asac | please elaborate a bit ;) | 13:49 |
RAOF | The gallium architecture only makes sense for GPUs which look sufficiently like current desktop GPUs - where there's not much fixed-function hardware, and pretty much everything is programmable and shader-y and such. | 13:55 |
RAOF | If your GPU hardware looks sufficiently like that, then building your driver using the gallium code will make it easier to support lots of API frontends - OpenGL, GL|ES, OpenVG, etc. Video decode acceleration is also likely to be implemented there (at some point). | 13:59 |
RAOF | If your GPU hardware doesn't look like that - it doesn't have flexible shaders, it's got a lot of fixed-function stuff - then using the gallium code won't be helpful. | 14:02 |
RAOF | The classic mesa infrastructure is more suitable for fixed-function hardware, and is not going to be going away. We still need it to support the fixed-function desktop hardware, like pre r300 ATI, and older intel chips. | 14:04 |
asac | RAOF: whats your personal opinion? do you think the win through reduced efforts in writing driver frontends is worth this extra level of abstraction? | 14:04 |
asac | ok ... so all modern stuff is using gallium? | 14:05 |
RAOF | A lot of modern development is using gallium. | 14:06 |
RAOF | Almost all of the recent work on r300-r500 cards has been in the gallium driver, and gallium offers a much easier path to get to OpenGL 3 and 4 than the classic mesa drivers. We'll likely be shipping the r300 gallium driver instead of the r300 classic driver for Maverick. | 14:07 |
asac | ok so there is consent that gallium is the way forward for modern hardware. thanks for the background | 14:08 |
RAOF | Nouveau only has a gallium driver for nv30+. The older chips (nv04-nv2x, corresponding to TNT → GeForce 3) have a classic mesa driver. | 14:08 |
RAOF | asac: Right. Anything which looks like a modern desktop GPU should be using gallium. ARM GPUs have significantly different constraints, so I'm not sure how much like a modern desktop GPU they behave. | 14:09 |
RAOF | Hm. Anything which is supposed to support GL|ES v2 is probably enough like a desktop GPU to benefit from gallium. From what I read of GLES v2 it's very much about programmable pipelines and shaders, which is what gallium requires. | 14:10 |
Dr_Jakob | RAOF: Anything that has shaders and want to implement either GL or DX is suitable for gallium | 14:23 |
Dr_Jakob | Which is all modern hardware | 14:24 |
Dr_Jakob | including low powered ARM gpu's.. | 14:24 |
RAOF | Dr_Jakob: Didn't know you idled here! | 14:25 |
Dr_Jakob | I do now :) | 14:25 |
RAOF | I think I'd talked myself around to the position that ARM gpus probably wanted gallium, since they GLES v2 appears to be all about the shaders, too. :) | 14:26 |
Dr_Jakob | I dunno about the mali GPU but for SGX most people pay PowerVR for their closed source driver. | 14:28 |
RAOF | I think we're aiming to be in a position to show demand for opensource drivers, rather than actually having any drivers currently. | 14:31 |
hyperair | aaargh | 17:46 |
hyperair | third time crashing due to intel gpu hang, third time re-running mp3gain, and third time fixing corrupted banshee sqlite db. | 17:47 |
* hyperair groans | 17:47 | |
ilmari | hyperair: gpu hang or driver deadlock? | 17:48 |
hyperair | er | 17:48 |
hyperair | how do i tell which? | 17:48 |
ilmari | which gpu? | 17:48 |
hyperair | intel gpu | 17:48 |
hyperair | er | 17:48 |
hyperair | 2a02 | 17:48 |
hyperair | 965 | 17:48 |
hyperair | X3100 | 17:48 |
hyperair | the first number is my pci-id | 17:48 |
hyperair | the last two are the two different model numbers my gpu appears to go by | 17:49 |
hyperair | well i'm using xorg-edgers, so i can't really blame anyone but myself for getting these wonderful hangs >_. | 17:49 |
ilmari | ah | 17:49 |
ilmari | I used to get gpu lockups on lucid, but that stopped. now I get x/kernel deadlocks instead :( | 17:51 |
ilmari | on arrandale (core i7 integrated graphics) | 17:51 |
hyperair | ilmari: how do you tell the difference between a gpu lockup and an x/kernel deadlock? | 17:53 |
ilmari | hyperair: by SSHing in when it happens and looking at dmesg, Xorg.0.log, intel_gpu_dump | 18:04 |
hyperair | ilmari: ah i see. well soudn hangs for me, so i'm sure it's a deadlock then =p | 18:05 |
hyperair | time to start mp3gain again.. | 18:05 |
hyperair | and hope that it doesn't fail miserably this time >_> | 18:05 |
ilmari | also SysRq-d (show held locks, requires a kernel with lock debugging), SysRq-w (show blocked tasksk) | 18:07 |
hyperair | eh? | 18:07 |
ilmari | to show what's blocking | 18:08 |
hyperair | no sysrq keys all crash for me | 18:08 |
hyperair | i mean | 18:08 |
hyperair | the sysrq keys no longer do anything. | 18:08 |
ilmari | not even sysrq-b? wow | 18:08 |
ilmari | (preferrably preceded by s and u) | 18:08 |
hyperair | not even that. | 18:09 |
ilmari | that sounds like a GPU or other hardware hang | 18:09 |
hyperair | =\ | 18:10 |
ilmari | my deadlock is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/568138 | 18:11 |
ubot4 | Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 6) (dups: 1) (heat: 36)" [Undecided,Confirmed] | 18:11 |
hyperair | AAAAAAAAAAAAAAAAAAAAAAAARGH! | 18:29 |
hyperair | AGAIN! | 18:29 |
Sarvatt | hyperair: 945 and g33 are fine here, no idea whats up with yours | 18:39 |
* hyperair switches from forbid-version to hold | 18:39 | |
Sarvatt | what kernel? | 18:39 |
hyperair | .35-rc2 | 18:39 |
Sarvatt | maybe try rc1 again and see if its ok there still? | 18:41 |
hyperair | nah, things only went sour after last night's upgrade | 18:43 |
hyperair | after mp3gain finishes, i'll turn on X to see what's going on. | 18:44 |
Sarvatt | machine dead when it hangs or can you get any more info out of it? | 18:45 |
Sarvatt | there were huge changes in 965 mesa yesterday | 18:45 |
hyperair | haaaaaaaangs. | 18:45 |
Sarvatt | maybe try disabling compiz? | 18:46 |
Sarvatt | so ya can blame mesa | 18:46 |
hyperair | and go non-composited for hours on end until it hangs? | 18:47 |
hyperair | nothanks. | 18:47 |
hyperair | i'd end up ignoring the machine, which would in turn ignore me and refuse to hang. | 18:47 |
Sarvatt | metacity compositing? :D | 18:49 |
ThisOtherGuy | hi all - can anyone help me with this: http://pastebin.com/7wdqrVdH | 18:54 |
hyperair | Sarvatt: ._. that sounds terrible. | 19:11 |
hyperair | Sarvatt: i really meant compizless though. gnome-shell is still tolerable, but i can't really go without compiz's extra features, particularly scale for long before cracking and switching to my desktop | 19:12 |
Sarvatt | hyperair: build compiz from git where opengl is optional? :D | 19:13 |
hyperair | Sarvatt: don't have the plugins require opengl? | 19:14 |
hyperair | Sarvatt: actually i've been meaning to, but at the rate i'm crashing, i'll never get to clone compiz from git. | 19:14 |
Sarvatt | i dunno, lets see. i dont think they do though | 19:15 |
Sarvatt | <requirement> | 19:15 |
Sarvatt | <plugin>opengl</plugin> | 19:15 |
Sarvatt | so scale does :( | 19:15 |
hyperair | heheh | 19:16 |
Sarvatt | could always just purge xorg-edgers and use 2.11 from x-updates :D | 19:20 |
Sarvatt | of course mesa is going to suck then | 19:20 |
=== asac_ is now known as asac | ||
Sarvatt | why did we make nvidia-graphics-drivers provide a video abi again? it supports multiple abi's with the same package.. | 19:31 |
Sarvatt | (needs to be no change rebuilt too) | 19:31 |
Sarvatt | nvidia-173 and lower dont work with 1.8 either yet, i think they'll work with the IgnoreABI option though | 19:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!