[06:27] BAH! [06:28] Stupid mesa stupid egl damn broken implementations bah. [06:31] what's up?-) [06:43] RAOF: oh hey what was the idea behind the shared gallium patch? [06:44] no more rpath issues btw, slangasek fixed it [06:44] problem was installing the drivers from the build-tree [06:44] ah ofc [06:44] so getting close.. [06:50] unity works on intel, ship it [06:50] :D [07:04] tjaalton: EGL is broken on !intel because of wayland changes. [07:04] And I was playing around with some prototype EGL code. [07:04] And wondering why it wasn't working... [07:04] ah [07:05] :D [07:05] mlankhorst: The shared gallium patch was basically the same as libdricore - take all the static archives in src/gallium and make a shared library out of them, rather than including them in all the gallium drivers. [07:05] oh so I was moving in the right direction then [07:05] I just get troubles at the linking phase now [07:06] Yeah, it was pretty frustrating. [07:06] have you seen the preliminary patch I created? [07:06] Ultimately upstream would like to have a monolithic everything_dri.so, as I understand it. That would be a bigger change, but easier to maintain I think. [07:06] mlankhorst: No, I didn't - is it on the list, or in git? [07:07] git [07:07] oh everything_dri.so.. [07:07] it fails to link swrast [07:07] i wonder what good did llvm-shared-libs bring [07:08] tjaalton: Not adding ~20MiB of llvm to each and every gallium driver? [07:09] ah, ok then [07:09] Cave johnson here, let me tell you something, when I buy a hard disk, I want to use it. None of this sissy dynamic link everything. I paid for the best and I want the best! [07:10] hmm that's what we used to have before too, no? [07:10] just not it has to be enabled separately? [07:10] *now [07:10] Yeah, we used to patch that in. [07:10] heh, ok [07:11] that's good then [07:12] the drivers are still huge [07:12] radeonsi_dri.so is 35M [07:13] Yeah, that's without libgallium, right? [07:13] all the gallium ones are 27-35M [07:13] yep [07:13] sounds about right? [07:13] libgallium factors out ~25 MiB of that. [07:13] ok [07:13] 25? [07:13] wow [07:13] Yeah, sounds about right. [07:13] libgallium.so is only 8 mb.. [07:13] only 2MB here (precise) [07:14] oh wait [07:14] hehe [07:14] the stripped binaries are much more manageable [07:14] :) [07:14] 4-5M [07:15] no point in looking in debian/tmp/dri.. [07:18] hm weird [07:19] oh great, make can swallow errors [07:22] I think I accidentally got it to work today, I don't know how [07:22] Heh [07:29] doing one more test run to see if it's really the case [07:32] slangasek also told that libxatracker isn't linked properly, it's missing -ldl -lm [07:33] dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so.0.0.0 exists in debian/tmp but is not installed to anywhere [07:33] dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so exists in debian/tmp but is not installed to anywhere [07:33] dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so.0 exists in debian/tmp but is not installed to anywhere [07:33] scary.. [07:34] :) [07:40] is he in this channel? he made a mess of the git tree [07:40] mess? [07:41] builds fine here [07:41] of course it does [07:41] committed with patches applied? [07:42] jcristau: winner :D [07:42] ah :) [07:42] bad vorlon [07:42] quite easy to do that :) [07:46] ah too bad he's not in any channels I'm in, can someone else point and laugh at him for me? :) [07:46] you're not on #ubuntu-devel? [07:47] I'm in too many channels already, I cut out at 10 :p [07:47] 10?? [07:48] damn, need to run.. installing quantal on the ati box just finished but can't test mesa there until late this evening ./ [07:48] :/ [07:48] jcristau: easier that way [07:48] i have 20+ [07:48] * jcristau has like 80 irssi windows open [07:48] jcristau: professional lurker :) [07:48] hah [07:48] :) [07:48] that's a lot [07:49] bunch of them are privmsg tho [07:49] 20 is the limit after which alt+key shortcuts stop working [07:49] still... [07:49] tjaalton: I'll run it on this ati box if you like. [07:50] RAOF: that would be great, I'll be on the bus for the next 1,5h and can do stuff but not test :) [07:50] afk -> [07:54] tjaalton: ok refreshed the patch [07:55] tjaalton: yeah that's why I give up on 10, personal irc comes after that :) [07:56] * mlankhorst has ignore on joins/quits from everyone, and nicks on some people who keep dropping out and auto rename [08:11] ok now to figure out how to add version to libgallium [08:11] no need [08:12] it's internal [08:12] so is libdricore right? [08:12] yes [08:12] yeah but they added a version for some reason [08:12] ewll [08:12] *well [08:13] the reason was probably that you could have several of those installed, but this is strictly a packaging detail right now so I wouldn't bother :) [08:13] * mlankhorst bets the symbols would still conflict, leaving fun issues to debug [08:13] ah well I'll leave it the same for now [08:15] Upstream versioned it to make it easier on developers. [08:15] looks like I didn't have that messy commit when I built it locally :) [08:17] mlankhorst: adding libgallium.so to .install.in means it'll fail on !x86 !armhf [08:17] ugh [08:17] now mixing things again [08:17] tjaalton: oh right armel.. [08:17] or sth [08:18] anyway, probably best to copy it in rules [08:19] We don't build libgallium on armel? [08:19] probably, was thinking of llvm again.. [08:19] I could upload to my armel ppa [08:20] leave it as is, like it was before.. [08:20] my bad :) [08:20] ah k [08:21] so now only the libxatracker linking issues remain [08:21] oh I didn't actually test if it ran or not [08:21] just if it built :p [08:21] hehe [08:22] needs ati or nvidia hw then [08:23] oh I know, lets netboot that thingy in precise again [08:23] btw other drivers will depend on libgallium.so.0 too [08:24] which other gallium drivers are there? [08:24] not counting llvmpipe [08:25] well just simple grep, seems libgbm1, libxatracker1, and libegl1 might depend on it [08:25] vmwgfx? [08:25] tjaalton: ah right. but that's also x86 :) [08:25] so maybe it needs a libgallium0 package.. [08:26] jcristau: oh, indeed [08:26] mlankhorst: or just drop it, the space savings aren't that critical anymore [08:26] mlankhorst: dunno about xatracker, but i would sure hope libegl doesn't link in gallium [08:26] if it saves 20MB that's still peanuts [08:26] libegl1-mesa-drivers/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so [08:27] at this point anyway [08:27] hrm [08:27] if there's risk of breaking something then maybe leave it unenabled for now? [08:28] well lets quantify it [08:28] * mlankhorst tries out both [08:29] egl_gallium.so isn't totally necessary (although it *is* the only way to get OpenVG support) [08:29] I'm just going to compare size [08:34] but would it be worth it trying to upstream it? [08:34] not if they have other plans (the monolithic dri.so?) [08:35] $ du -sh ?ummy* [08:35] 39M dummy [08:35] 233M dummy2 [08:35] 45M summy [08:35] 287M summy2 [08:35] blegh 6 mb [08:35] 2 contains all the -dev and -dbg files [08:36] tjaalton: I don't think that rose to the level of a *plan* [08:36] RAOF: ok, so in that case it might be worth it :) [08:36] That was more “thanks for the dricore patch. I've always wanted to do something like that, but roll everything up into a monolithic dri.so” [08:37] So it's probably on the TODO list, just after “learn Portuguese” [08:37] ahh [08:37] so do we keep the patch or.. [08:38] tjaalton, mlankhorst: how much extra space are we talking about on the deb? [08:38] keep it, and ship with it if it works, but if there's risk of breaking something maybe spend some more time on it? [08:38] seb128: 6 mb uncompressed if the entirety of mesa was shipped, so less than that [08:39] mlankhorst, how much on the deb? 6mb is quite some [08:39] let me test build one more time [08:40] testing the xatracker link fail [08:41] seb128: what debs do you mean specifically? I bet not all of them are shipped [08:42] libgl1-mesa-dri [08:42] mlankhorst, I'm trying to figure what would the impact on the CD to drop that optimisation, it was done for a reason ;-) [08:44] I recall that it nabbed on the order of 10 MiB of CD space when I first did it; the gains may be less now that dricore is upstream. [08:45] RAOF: probably, it's 5 mb saved uncompressed for just libgl1-mesa-dri [08:46] but yeah looks like libgl1-mesa-dri compresses well so it saves like 300 kb compressed.. [08:47] well, the liveCD is not deb compressed, it's squashfs compressed I think [08:47] I guess we could try to drop that optimization and wait for the next daily iso and see the difference [08:49] but the total still rounds up to 1.4mb because the other parts need to compress parts of libgallium too [08:50] see http://paste.ubuntu.com/1160450/ [08:51] the debs are xz-compressed now [08:52] tjaalton, deb compression doesn't matter for the liveCD, they do for the alternate [08:52] Wah! Nearly 7pm. Time to stop! [08:52] seb128: i know, but while comparing deb sizes.. [08:53] tjaalton: same compression is used :) but I imagine squashfs compression might be different [08:53] tjaalton, mlankhorst, RAOF: well, your call at the end to see how much work it is and if you think it's worth it, CD space is still a limited resources and some mb can mean we need to drop support for a language spoken by some hundred of million of people [08:54] I think we ought to measure it [08:54] so it's not like there was not a tradeoff [08:54] could I bug someone to master a cd with both debs to see the space difference? [08:56] but I'll post it on mesa-dev [08:56] mlankhorst, well the deb difference probably done a rough estimation, they are not compressed the same way but they are both compressed [08:56] mlankhorst: duh, of course. i'll get me coat [09:07] hm, suppose I should test first before posting it [09:15] seb128: I think I'm going to try to get it upstream, if it gets accepted there we wouldn't need to keep it. [09:16] mlankhorst, that would be great [09:21] yeah [09:24] -modesetting moved to main [09:32] meh, no success in getting xatracker linked properly [09:32] later -> [09:45] Hey all, updated my nvidia drivers having xorg dependency issues. [09:45] Any one else done this too? [09:49] UraniumSlug: it's done on purpose [09:49] new nvidia drivers claim to be compatible, but aren't.. [09:49] mlankhorst, what's the work around? [09:50] not installing new x server :-) [09:50] I've tried using the xorg-edgers ppa nvidia-current package. [09:50] Not getting past the login screen with them though. [09:50] yeah they just broke, no good fix right now, depends on new nvidia drivers [09:51] tjaalton: hm glxgears spins [09:51] and login screen comes up right [09:52] mlankhorst, thanks for the info, much appreciated. [09:55] hello Xers! [09:55] Is there any technical reason why we couldn't backport nvidia-current in quantal to precise? [09:56] I am told there are some compelling features (xrandr support) improved in the version in quantal [10:05] popey: I would imagine that would be for nvidia-current-updates, but no idea when that updates, we mostly deal with the things we can influence here :) [10:13] mlankhorst, well, I'm asking because someone on the backports team wanted to know if there was a technical reason we shouldn't backport that driver, I don't know :) [10:22] I don't know if there is any technical reason, but nvidia-current-updates would be the right place to put it, maybe bryceh or Sarvatt know [10:24] ok [10:24] ta [10:36] popey: but let me know, it would be useful when the quantal server works with nvidia so I could copy it to my q-lts-backports ppa :) [10:52] popey: nvidia-current-updates is the package deliberately designed to do post-release updates. I don't think we've ever managed to *do* one, but that's what its for :) [10:52] hah! [10:52] RAOF: actually the version is newer [10:53] 295.40-0ubuntu1.1 vs 295.49-0ubuntu0.2 [10:53] is it a time/resource reason for not doing it, technical or some thing else? [10:56] popey: because not updating to newest and shiny all the time is more likely to keep systems running, or because we don't find it a high piority, pick one :) [10:57] it's not 'oh new version, lets update' but more like 'things broke, is there a new version that fixes it?' :-) [11:01] well, the specific thing that prompted me asking is because colour profiling seems broken with the nvidia proprietary driver because it doesn't support xrandr 1.2 [11:02] then use that as justification for requesting an update :-) === yofel_ is now known as yofel [11:03] whats the process? file a bug? [11:03] RAOF: is the process the same for the binary drivers? [11:06] just ask tseliot to update it? [11:06] tseliot: ^ [11:09] yes? [11:09] popey: please file a bug report and feel free to assign it to me [11:10] (against nvidia-graphics-drivers-updates) [11:10] ok! [12:40] yay for nvidia is not completely removed types of bugs.. === jibel__ is now known as jibel === Amaranthus is now known as Amaranth [17:01] thanks tseliot [17:02] :) === ogra__ is now known as ogra_ [17:48] ah great, my libgallium patch might get folded in to the patch for automaking whole of gallium :) [17:48] Wouldn't it be better to just fold all the gallium drivers into a single binary. [17:49] Enable -fvisibility=false and get an even smaller total binary size. [17:49] And faster loading [17:52] Prf_Jakob: in that case you might as well link everything into libGL completely [17:53] mlankhorst: there is no real gain for that, since DRI driver only export on symbol. [17:54] And doing a mega classic dri driver might be harder. [17:54] but it won't help for vdpau and other gallium drivers that aren't dri :) [17:55] At least mega dri drivers would be officially supported, the whole shared thing is hacky as hell since we have no formal ABI or promise of ABI over that boundry. [17:56] true [17:57] Loading extra gallium drivers arn't that bad since they are relativly tiny 400-700k [17:58] Also why you guys don't just upx all binaries I don't get. [18:01] because it doesn't make the cd smaller :-) === jussio1 is now known as jussi === jussi is now known as Guest83481 === jibel_ is now known as jibel