=== maxb_ is now known as maxb [02:35] hey bryceh, would you recommend ati or nvidia for a new linux box if i exclusively use non-free drivers? [02:35] nvidia, no contest [02:36] reasoning? [02:36] you're using the blobs, right? [02:37] the nvidia driver gives you vdpau, opengl 3.2, xrender accel [02:37] support for newest x servers and cards right away [02:38] OTOH, like I saw twice during the last 10 days, people can't seem to get there laptop to work together with a beamer if they have nvidia ;-) [02:38] what about free drivers? how are nv, nouveau, radeon, and radeonhd? [02:38] they all suck [02:38] buy a mac [02:38] they're all crap [02:38] no 3d? [02:39] radeon's ok [02:39] at least for R500 and earlier [02:39] the intel driver is the ony good foss graphics driver [02:39] radeonhd has 3D if you have the exact same card as the developers IIRC ;) [02:39] (or was it the radeon driver?) [02:39] intel graphic drivers are godly. intel graphic hardware is crap. [02:40] how is gallium coming along? [02:41] can i expect nouveau to perfect it and all of xf86-intel to use it by the end of 2011? [02:41] not ready for prime time [02:41] AFAIK gallium is a tool (library) to make 3D graphics drivers, it's not a graphics driver in itself... [02:41] possibly [02:41] ? [02:41] heh. i though gallium was replacing mesa. [02:42] or do i have a completely incorrect view of how graphic stacks work? [02:42] not anytime soon, that's for sure [02:42] well, mesa is used for something like that too ;) [02:43] as I understand mesa, it implements OpenGL in software, and lets drivers override that by hardware-supported methods [02:45] hm [02:46] i don't know how anyone tolerates the fglrx/ati drivers [02:46] """Gallium3D is a software library for 3D graphics device drivers being developed by VMware (previously Tungsten Graphics).[1] Gallium3D operates as a layer between the graphics API and the operating system with the primary goal of making driver development easier, bundling otherwise duplicated code of several different drivers at a single point.""" [02:47] http://en.wikipedia.org/wiki/Gallium3D [02:47] when i put this system together i tolerated it for 15 minutes before returning the card [02:51] wut. vmware gobbled tungsten? [02:52] maybe for the better (let's hope) [02:52] anyway, i have a question about the 2.6.33 backport plans. which option is being considered most heavily? [02:52] LLStarks: I guess vmware wanted 3D graphics knowledge for VMs [02:53] that's good. 3d emulation sucks. [02:54] as long as they keep it gpl [02:54] well, I guess they want 3D passthrough ;) [06:03] bryceh: if I have to add resume=/dev/sdXY to resume from hibernation should I mark test as passed or nt? [06:03] not* [06:03] bryceh: I'm talking about nouveau evaluation [06:03] not [06:03] mark it failed and list what you did to work around it [06:04] kklimonda, btw thanks for helping with testing :-) [06:08] bryceh: and when testing dual head should I mark it as failed if nouveau fail to detect that I've plugged my monitor until I use xrandr or display from preferences menu? [06:08] plugged or unplugged [06:09] if you can get it to work after fiddling with xrandr, count it passed [06:10] kklimonda, but we're not sticklers on what counts as passed or failed; kind of use your judgment, if you feel the driver is really sucking on something, fail it. If you think it's adequate, give it a thumbs up [06:10] remember we're comparing against -nv, so that's a pretty low hurdle ;-) [06:11] bryceh: I should mark all tests as passed then - maybe leave hibernation one as failed.. [06:11] kewl [06:11] bryceh: are all required bits for nouveau uploaded to archive or do I still have to use xorg-edgers ppa? [06:11] I'd like to reinstall system when alpha3 is released and test it on clean install [06:12] kklimonda, I'm pretty pleased with the testing that folks have done. It's giving me confidence that we're going in the right direction with nouveau. We may have some issues to square away but I don't feel like we're going to need to go back to -nv or anything drastic [06:12] kklimonda, there are still a few bits outstanding for nouveau. I think we may have them all in by the end of the week [06:13] bryceh: for example packages that have been uploaded to archive seem to be missing nouveau_kvm_hook for initramfs.. or maybe I don't have the right package installed [06:14] bryceh: I'm really pleased with nouveau myself - especially now that there are so many weird problems with nvidia driver in lucid :) [06:14] yeah I'm not sure whether linux-backports-modules is in yet, but we'll need that in the archive before we can really start wrapping things up [07:11] kklimonda: The kms hook really needs to go into the framebuffer hook shipped with initramfs-tools. === hypera1r is now known as hyperair [10:47] any pending changes to mesa, or should I upload what's in git now? [10:48] Sarvatt: ^ [12:21] xserver 1.7.5 merged [14:12] tseliot: your new nvidia upload to lucid drops my glxgears frames rate about 5-10k (to half maybe) [14:13] sebner: what does glxinfo say? [14:14] tseliot: http://pastebin.com/m59fe117a [14:15] sebner: it's not the final release so it might be a temporary regression [14:15] kk [14:15] sebner: do 3D applications seem slower? [14:16] tseliot: definately [14:16] glxgears is not a benchmark [14:16] ok [14:17] sebner: also what does this command say? "ldconfig -p | grep GL" and does the X log show anything interesting? [14:18] tseliot: http://pastebin.com/m213d74b2 Xorg log shows acpi failure (dunno if this is new though) [14:20] sebner: maybe nvidia is doing something "new" ;) [14:20] but other than that it should be fine [14:21] heh [14:21] kk [14:22] * sebner will just wait until mighty tseliot gets his hands on a new and fixed driver then :) [14:22] ;) === Sinnerman is now known as Cobalt [18:42] tjaalton: whats in git now works for mesa, the bug fix for building rss-glx is waiting on moving libGL back to /usr/lib as far as I can see but the alternatives for libgl1-mesa-swx11 are working fine [19:06] heya Sarvatt [19:06] Sarvatt, what's your opinion on sticking with 2.9.1 vs moving to 2.10 for -intel? [19:12] no execbuf error for days... Duke` is happy \o/ [19:13] Duke`, is that with stock lucid or xorg-edgers? [19:13] xorg-edgers [19:13] on karmic [22:45] tjaalton, heh the comments on the phoronix article are arguing every single opinion on this. [22:46] a third think we're crazy not to be using the 2.6.33 kernel, a third think we're crazy to be considering backporting *anything* from 2.6.33 for an lts, and a third are crazy themselves [22:47] Are you sure those groups have no intersection? :) [22:47] RAOF, ;-) [22:49] ehe [22:49] bryceh: what are we backporting from .33? [22:50] it's a bit irritating how closely phoronix follows our development discussions. It's like having a conference call and someone hooks the phone to the loudspeaker at comdex [22:51] BUGabundo, drm [22:51] BUGabundo, RTFPhornix ;-) [22:51] ? [22:51] that I don't know [22:52] probably for the best [23:05] bryceh: haha :) [23:06] Sarvatt: ok, I'll probably upload it tomorrow until someone gets to it before me [23:13] tjaalton, mesa? [23:15] any news on fixing 3D in nouvuea? [23:15] been broken since Sunday [23:15] bryceh: yep [23:16] tjaalton, great [23:17] BUGabundo: -ENOTSUPPORTED! Without having looked at it, I'd guess that it now requires libdrm 2.4.18 and a drm interface version 0.0.16, which means pulling from nouveau's linux tree rather than linus. [23:18] ok [23:18] thanks [23:20] If we end up planning on pulling 2.6.34 intel & radeon into linux-backports-modules, we may well end up pulling in the 0.0.16 nouveau drm interface soon. [23:59] Hey. Seems that the latest x11-common pulls in a heap of -dev packages. Is this intentional? What use case does it support?