[03:01] has mesa-utils been in universe for a long time? [03:01] cant enable compiz or KDE desktop effects without glxinfo... was just messing around on a kubuntu livecd [03:04] I thought compiz now did its own gl extension detection? [03:04] It's quite possible that kwin still calls out to glxinfo; I don't think kwin's been the subject of a ruthless time-to-desktop shaving exercise. [03:06] kwin for sure needed mesa-utils installed to enable gl compositing, i couldn't activate it until i manually enabled universe and installed it [03:06] grabbing the compiz source to check but i swear it just had glxinfo calls in it when i looked a few days ago [03:07] file $(which compiz): ELF 64-bit LSB executable. [03:07] It's no longer a wrapper script that calls glxinfo; I guess it might call out to glxinfo from C code, but that seems less likely. [03:14] ah yeah it doesn't need glxinfo anymore outside of the apport hook [03:15] i see the checks in src/screen.c [03:24] Sarvatt: Have you updated xorg-edgers with new nouveau stuff? It seems compiz broke for at least one poor widdle macbook with an update today. [03:26] nope, it needs to be updated, i haven't had time to mess with it because i've been in bug fixing mode all day and am about to pass out :) [03:42] You are most welcome to be in bugfixing mode! [03:48] RAOF: doesn't UNE call glxinfo to determine if it should run in 2D or 3D mode? [03:49] That's a good point! [04:20] So I have this little icon in my notification area and it references this blog http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/ [04:20] It mentions X, so I figured I'd ask about it in here. ;3 [04:29] looks like kde and wine need some extending to work with nouveau 3D (yay...) [04:30] kwin/compositingprefs.cpp has the gl vendor strings hardcoded and wine does the same [04:30] kwin hardcodes vendor strings? Sucky. [04:30] (in kdebase-workspace) [04:38] well its just determining if gl compositing should be used by default by the vendor so its no so bad in KDE [04:38] wine on the other hand... [04:48] is it me or does that netbook-launcher glxinfo check not look right in the first place..? its parsing the output for Direct Rendering: Yes when you could have that with swrast? if anything I'd think it should be checking the opengl renderer string for != Software Rasterizer or Mesa DRI || Gallium as well, or heck just put the code in and bypass glxinfo altogether to be faster [04:49] you're working on netbook-launcher now aren't ya RAOF? only reason I'm bugging you about it :) [04:52] Sarvatt: Yeah, I am. You're welcome to bug me about it, but I'm currently turning f-spot into a fusion-powered rocket ship. [05:01] well it'd have to be renderer string != Software Rasterizer or contains Mesa || Gallium, OR the opengl version string contains NVIDIA || ATI [05:03] silly blob drivers put the card names in the renderer string and the vendor in the version string and swrast has Mesa in the version string too so couldnt use just the version string [05:05] of course I see netbook-launcher being the most use on arm and who the heck knows what gl info those blob drivers (that arent even packaged in ubuntu) use [08:34] yeah, serial wacom works [09:10] apw, RAOF: so which nouveau API are we getting for lucid? reading through the dri-devel flamefest about this made me realize that if and when there are going to be newer kernels backported to lucid (as I've heard is the plan) nouveau will break [09:11] if we stick to 0.0.15 [09:22] tjaalton, they said they would be supporting .33 drm for some time, which api does that have [09:40] 15 i think [10:04] apw: yes, but it's still the same problem; harder to run newer kernels with nouveau (needs the newer ddx as well) [10:04] and lidrm [10:04] *libdrm [10:05] but that problem will always exist, upstream does not strive for compatibility [10:06] haven't asked but if nouveau gets out of staging in .34 then they have to [10:07] and do what intel is doing, flagging features and turning them on if the userspace works with them [10:07] or the other way around [10:08] anyway, I'm happy as it is now, having the .33 drm backported :) this was just a heads up to see what kind of problems there will be in the future [10:08] (and speaking as the maintainer of an nvidia-only shop) [10:26] :-) [10:27] shop? [10:27] "shop" [10:28] aren't you working at the university any more? [10:28] yes [10:29] ok, I get it now [10:32] good, I can't explain the word :) [10:32] in this context [10:33] "place to work" or so [10:34] yes, just wanted to know whether I had to take that literally or not [10:34] hehe [11:07] RAOF, about? did you manage to test the update to the kernel in my red ppa? [11:24] apw: I did; it works. [11:24] RAOF, the versions with the linux-meta and everything [11:25] Yes. It upgraded fine. [11:25] RAOF, that worked here on my mini 10v, as far as i can tell ... [11:25] you were absolutly right abut the replaces etc not being needed [11:26] thats great, can i take it you are happy with that kernel (essentially) going into the archive? [11:27] Yup. the linux-backports-moudles-nouveau-lucid-$FLAVOUR dependency can be currently satisfied by the actual packges, which don't apply to the new kernel ABI, and once those kernel packages are in the archive, published and mirrored we can drop the dependency from xserver-xorg-video-nouveau and make cjwatson happy. [11:27] Yes. I'm happy with that kernel going into the archive. [11:27] superm1: I'm setting fglrx's alternative priority to 1000 as having the same priority of nvidia-current can cause unpredictable results when in automatic mode [11:30] And tomorrow morning I'll pick up my new intel/nvidia netbook, and see how much nouveau likes switchable graphics. [11:31] RAOF, excellent, i'll get steves and bryceh's ack and then get it in, i suspect a special note to u-k and u-x mailinglists will be appropriate [11:33] Would you be able to do that? I'm off to bed, and I'm not entirely confident I'd be coherent if I tried to write such a note now :) [11:34] RAOF, heh yeah i was assuming i would be in the frame for that, i can get bryceh to help [11:35] Thanks. And with that, I depart. Like a phantom into the night. [11:40] RAOF, thanks for you testing help [14:45] hello i posted bur report for legacy 173.22.14 nvidia driver https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/523108 [14:45] Launchpad bug 523108 in nvidia-settings "nvidia x server settings on ubuntu 10.4" [Undecided,New] [14:45] this morning i tried them again and i got same worrie [14:46] and 173.14.25 solved the problem [14:46] but i feel plymouth does not work cause im using this driver from nvidia.com [14:48] what can i do ? to make driver from repos working ans plymouth running [14:48] change your bug report so that it is a packaging request for the newer driver [14:49] bryceh, how did your testing go on 'red' ... [14:50] sorry ... [14:52] zniavre_, your bug isn't an nvidia-settings bug it is a packaging request for the newer 173 driver. you need to mark the current one as invalid and create a new one [14:53] ok i ll try that [15:17] http://www.engadget.com/2010/03/05/nvidia-pulls-196-75-driver-amid-reports-its-frying-graphics-car/ [15:18] seems the firmware wasn't activating the gpu fan [17:32] nouveau is worrying me alot at the moment.. I see a whole lot of issues supporting it in a LTS with its current state and the risks by *far* outweigh the positives in my mind [17:33] Sarvatt: didn't you foresee this coming? [17:36] yes but I don't make the decisions and the work that has been done to get it going was a very positive thing in my eyes. I just don't feel its a good idea in its current state with how much it will break things [17:37] for instance, people wont be able to install backported or mainline kernels on nvidia machines unless they are using the blob. people are pushing for the .34 nouveau api to be a stable one and we'd be using .33 thats incompatable [17:37] oh that sucks. [17:38] the dumps that newer nvidia GPU support was based off of were just recently found to be completely broken [17:38] and that sucks even more [17:38] i think nv is a better bet for stability purposes then [17:38] a .33 based nouveau with the old api wont be supported by upstream [17:39] meh. [17:39] unstable APIs suck [17:39] this is alot of risk for something that is basically a gateway to install the blob graphically at this point [17:39] would be interesting to know whether rhel6 will have nouveau [17:39] is it too late to revert? [17:40] no i can see alot of ways we could safely have nouveau in and just not default like dropping xserver-xorg-video-nouveau from xserver-xorg-video-all and making the ddx optional while still keeping the xserver default nouveau patch, blacklisting the nouveau module by default, un-blacklisting it in a maintainer script in the ddx package [17:46] nouveau works great for me [17:47] eh, -nv is crap [17:47] no need to go back now [17:47] tjaalton: no new kernels for you [17:48] hyperair: well there are ways to go around that [17:48] tjaalton: like using the blob? =p [17:48] no, backporting libdrm/ddx too [17:50] I'm in favour of pulling the new api, more so _if_ it's marked as 1.0.0 (airlied asked for that on the nouveau list) === radoe_ is now known as radoe [18:13] it works great for me as well but I'm thinking of the average user who's going to be using it without understanding all these intricacies, nvidia has such a large number of users [18:14] and i know there are alot of gpu's that dont work properly that haven't been tested, and functionality thats broken that will be expected to work that we miss [18:15] heh, i just slotted an AIW 9000 into a debian stable: boom. [18:16] luckily i know my way around a graphics driver a bit [18:16] but come on, how can a graphics card that, 3 years ago was probably the best supported out there _not_ work with debian stable. [18:16] nobody tests anything, as nobody has the ability to deploy new code easily [18:17] what's aiw 9000? :) [18:17] r250 or so [18:17] all in wonder radeon [18:17] ok [18:18] Sarvatt, but if, as you say, it's mostly a gateway for installing the blob, broken functionality shouldn't be of too much concern, as long as the basic functionality of bringing up a display is there [18:18] i am not blaming you for this, btw, just the situation as a whole is messed up [18:18] johanbr: i have tried explaining nothing else for the last 5 years [18:18] libv: well i have no radeon hw so i'm relying on whatever testing happens in unstable before release. [18:18] johanbr: the mountain of crap i have received for that is hard to measure. [18:19] jcristau: as said, not your fault [18:19] libv: if you have a fix for stable, though, i'll gladly take it :) [18:19] jcristau: a return right after variable declarations is hardly a fix :) [18:20] heh [18:20] but it did allow me to test the dri driver [18:20] libv, the aiw series of cards hasn't been the best ati had in 8 years or so, not 3 years [18:20] which was a success, as was unichrome [18:20] bjsnider: i am one of the guys who worked with amd to free ati, i was the guy who wrote most of the modesetting code for radeonhd [18:20] bjsnider: this was 2.5ys ago [18:21] bjsnider: 2.5ys ago, r200 had the best 3d support out there [18:21] i know who you are sir [18:21] i listened to that talk you delivered recently at the conference [18:21] only about 2ys ago, dri was becoming better for r300 than for r200 [18:21] in which the intel guy took strong exception [18:22] radeon 9000 was one of the later and faster r200s [18:22] bjsnider: that'd be eric anholt; who did this commit: http://cgit.freedesktop.org/mesa/drm/commit/?id=b5495527 [18:23] right, anholt [18:23] now r200, at the time, was one of the best supported pieces of hardware out there [18:23] but... it still blew up in my face [18:23] why: because people do not go and test things easily [18:23] people cannot deploy a whole graphics driver stack easily [18:23] but the aiw cards have tv chips on them as well [18:23] bjsnider: which is exactly what exploded [18:23] the tv chip? [18:23] bjsnider: no, the code trying to initialise it [18:24] it never worked very well for me [18:24] even back in the day [18:24] i've got one of those cards sitting around here [18:24] i inherited this hw, as i did an agp r500, from my gamer cousin, i only pulled it out now to test dri drivers [18:24] used to use it in mandrake [18:25] i know that it's early 2000s hw far too well, i recommended this hw to my cousin [18:26] but still, it shows how badly these things get tested; and the reason for that is: nobody does, even though they sometimes want to, because everyone is either forced to change half their distribution, or forced to wait and upgrade their distribution before anything can be tested [18:26] this works for many things, but not for volatile stuff like graphics hw and graphics drivers [18:27] the really strange thing is that, what i suggest doing is actually setting the graphics driver developers free to some extent [18:27] and yet they are against it [18:27] r100/r200 is pretty much the main reason we're having to backport 2.6.33's drm to 2.6.32 to use KMS :) [18:28] Sarvatt: it's broken on 2.6.32? [18:28] Sarvatt: radeon still has xf86 modesetting [18:28] libv: ubuntu wanted kms in lucid [18:28] aiui [18:28] yeah wth KMS, quite alot of fixes in .33 that didnt make it back to .32 in that area but UMS is fine [18:30] Sarvatt: well, now the ratrace is on completely [18:30] kernel, libdrm, xorg and mesa will soon be tied 1-1 completely [18:31] what's the policy about stable mesa and ddx updates in -updates for a LTS? I really think we need to upgrade mesa point releases post release because almost all of my SRU's were fixes in the stable branches and bringing in whole new stable updates would wipe out big chunks of bugs instead of going through the SRU process for each individual commit [18:32] Sarvatt: where are most of those bugs situated anyway? [18:32] Sarvatt: in the mesa code itself, or in the drivers? [18:32] (that would be a mightily interesting datapoint for me) [18:33] my guess would be drivers, but i haven't looked. [18:33] do you mean the drivers in mesa or the x drivers? [18:33] Sarvatt: we're talking about mesa, so the drivers in mesa :) [18:34] what do you have to patch up most? [18:34] src/mesa/ or src/mesa/drivers/dri/* [18:34] (but then i've never had to update mesa in a stable release) [18:35] its both really but probably moreso the drivers [18:35] Sarvatt: ah, but this is probably seen as "both" because they are one whole right now [18:35] guess what i was testing the aiw 9000 for :) [18:35] do you count swrast as a driver? :) [18:36] hehe :) in my world, no, as it conflicts with src/mesa/drivers/common/driverfuncs.c [18:37] which all normal drivers do use [18:37] but the line is kind of blurry there [18:38] they do some sketchy things on the stable branches sometimes which would hinder what I was suggesting I guess, like making the libdrm-radeon1 api changes from 2.4.16 required in 7.6.1 [18:39] Sarvatt: even though it's only the radeon/r200/r300/r600 dri and gallium drivers that require that [18:39] mesa is weird, the vmware people work on the stable branch instead of master and pull fixes into master from there and everyone else works on master and backports to the stablebranch [18:39] it's a mess [18:40] someone asked me recently about how i see the future of mesa, with the tungsten people now part of vmware [18:40] which is an interesting thought :) [18:42] yeah the vmware people care alot more about windows support even though it seems like linux is by far the platform that uses it the most and its holding back having a sane build system from what I see [18:44] having 3 build systems is what prevents it from having a sane one :) [18:48] Sarvatt: the sru process is way too heavy imo, and having point releases would be nice [18:49] why not put the whole point-release as a sru [18:49] and keep it in -proposed for some time [18:51] for mesa 7.6 in karmic I saw issues with glxinfo segfaulting when not using mesa gl, swrast being broken on big endian platforms, too many intel and radeon fixes to count, and a bunch of memory leak fixes all over the place that were fixed by point release updates post release [18:53] mesa 7.8 should be branching any day now so hopefully they wont try to backport things that require new libdrm releases to 7.7 :D 7.7 wasn't branched yet when the ati stuff landed in 7.6 branch that needed a newer libdrm [18:55] the intel libdrm bump doesn't promise much good there [18:56] the really cool thing is, main mesa-dri only depends on libdrm 2.3.0 [18:57] thats on 7.8 though, seems like too big of a change to add to 7.7 since its dependant on so much stuff like the dri1 removal if i'm not mistaken [18:58] trying to work out why nvidia requires glx explicitly enabled in an xorg.conf now [19:00] Sarvatt: did you enable the blob, so that the alternatives are fixed? [19:01] hmm, you know, I didn't actually check that glx was working normally since I installed everything in a hurry for my wife to use it while I work on her laptop [19:15] yeah glx is fine, forgot i did check it because i was using compiz [19:17] looks like the problem is that it uses /usr/lib/xorg/modules/extensions/libglx.so instead of /usr/lib/xorg/extra-modules/libglx.so if you dont load glx via xorg.conf [19:18] even though -- ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [19:24] having an alternative for libglx.so would solve that but yuck [19:33] hi Sarvatt [19:33] http://pastebin.com/0nGXwtDX (no xorg.conf) vs http://pastebin.com/9G9LM0k4 (xorg.conf with glx forcibly loaded) [19:33] heyo! [19:34] Sarvatt, regarding your earlier concerns... I don't think he's made it public yet but RAOF has drafted a stabilization plan for nouveau. [19:35] we had known going into this that there'd be a lot of regressions, and that support was going to be tough, but at the time we decided to go forward with it, we felt it would be worth the risk. What I've seen so far has not been too far out of bounds from what I expected [19:36] RAOF says the next step is we need people to write bug reports on issues with nouveau, so the issues can be tracked and gotten upstream. [19:44] could be really hacky and change xorg-server/hw/xfree86/common/xf86AutoConfig.c to add a device section with glx enabled always :) [19:45] err module section I mean [19:45] Sarvatt: explicit Load "glx" vs default loading makes a difference? [19:45] that sounds like a bug to me... [19:46] yup, it ignores the ModulePath option for loading modules but loads drivers from ModulePath fine [19:47] ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" -- Loading /usr/lib/xorg/modules/extensions/libglx.so with no xorg.conf but it loads from /usr/lib/xorg/extra-modules/ fine with [19:47] Section "Module" [19:47] Load "glx" [19:49] that's not modules vs driver.. [21:47] libv, how is the openchrome driver's 3d/compositing coming along? [21:47] bjsnider: i am the guy who writes unichrome. [21:48] openchrome is the people who forked away from me because i wouldn't accept vbe and was working on real modesetting [21:48] this real modesetting was deemed useless at the time. [21:49] and openchrome is just the xorg driver [21:50] how's via kms coming along then? :) [21:50] jcristau: ask via :) [21:50] openchrome is basically a dead project [21:50] there is a guy doing some useful work fixing bugs though [21:51] but that's all it is [21:51] oh, yeah, ivor hewitt pointed IDA at a more recent libddmpeg.so from via and added xvmc support for a few other chipsets too [21:51] his second contribution to free software in a decade [21:51] does the driver you are working on do compositing? [21:52] bjsnider: nope, but sadly unichrome is just turning out to be a playground for future technology [21:52] gee, that's funny [21:53] even though all i try to be as directly useful and immediately deployable and backwards compatible [21:53] turns out that those goals means that i am shaping the future each time :) [21:53] the gnome-shell guys said they had to work on via's driver to help it along so g-s would work with it [21:53] tells one more about the current state of free software graphics than anything else [21:54] bjsnider: yes, VIA's driver. [21:54] bjsnider: VIA now claims it is working with openchrome, but it is not a symbiosis [21:54] i'd say free software graphics are pretty much a disaster at this point [21:54] but whatever [21:54] that's not a friggin' secret [21:54] bjsnider: i know, and i have been working my ass off on changing that, sadly things don't work out too well each time [21:55] they do to some extent, as quite a few things of what i have done have been taken on, usually in a reinvented form [21:56] in any case, unichrome is not a dead project, it's just me. [21:56] openchrome is pretty much a dead project, as only a few bugs are being fixed by one guy, while everyone else there is acting big and are talking loudly about how they are working together with via [21:56] i don't think the g-s guys were helping to develop a closed-source driver, i think it was openchrome [21:57] via is just using the openchrome people, who are trying way too hard to be relevant without doing actual code, to clean up its image while being able to retain their old mode of working [21:57] g-s? [21:57] gnome-shell [21:58] i haven't seen any changes to the exa code on openchrome in the second half of the decade [21:58] jon nettlet [21:58] he talks. [21:58] never acts. [21:58] "the openchrome people, who are trying way too hard to be relevant without doing actual code" [21:59] he seems to be very active to me, although i'm not sure about the openchrome thing [21:59] http://www.openchrome.org/trac/timeline [21:59] he's very active in the gnome-shell project and other gnome-related things [21:59] he is active in talking [21:59] not in doing [22:00] i do not follow gnome development directly, i am following enough already doing graphics drivers :) [22:00] but on the openchrome side, he just talks. [22:00] gang65 is bartosz, the guy who actually works when he finds time, and who fixes bugs [22:01] everyone is just talking out of the wrong ends of their bodies. [22:01] everyone else that is [22:01] everyone's wrong but you... [22:02] bjsnider: not everyone, and not on everything, but quite a few are on many things i whine about [22:02] hence why i whine about them [22:02] that's funny, because i thought everyone was wrong except me [22:02] so i might be wrong about that [22:03] i liked the mark twain on the new ubuntu style notepad [22:04] "The man with a new idea is a crank until the idea succeeds." [22:05] what's happening with the radeonhd driver? is that dead? [22:05] bjsnider: novell fired 20% of devs in nue [22:05] bjsnider: leaving me jobless, and leaving my colleagues unable to handle anything anymore [22:06] amd also stopped formally working on it, as it had severe financial difficulties [22:06] so ATIs plan succeeded [22:06] and what was ati's plan? [22:07] if ATI has ever had any plan for anything, this will be the first i've heard of it [22:07] bjsnider: first it was to stop the free software thing altogether, then they went together with redhat, who liked a bit of publicity, to provide a competing driver [22:07] bjsnider: i can spend many hours explaining what happened and provide many instances that can be deemed "highly curious" behaviour [22:08] i usually hold the same monologue at least once per month [22:08] what competing driver? xf86-video-ati or radeonhd? [22:08] -ati [22:08] that's really old driver [22:08] bjsnider: r500 support in radeon happened late november [22:09] bjsnider: radeonhd development started late july of the same year [22:09] i see what you're getting at [22:09] bjsnider: it is surprising how little people even know that little fact [22:10] you think it was a redhat vs. novell thiing? [22:11] bjsnider: it's an AMD + SuSE (novell had nothing to do with it, it was suse people, with their long standing relationship with AMD, that existed before novell bought suse) versus ATI + rh [22:11] ATI versuse AMD and redhat versuse SuSE [22:12] versuse :) [22:12] ati and amd are the same thing during this [22:12] bjsnider: if your new mothercompany tells you to opensource your crap and to provide docs and change your hw + software sales model to a hw only model, then you're not happy [22:13] and if your mothercompany then says "fine, you're not doing it, we know some guys who will" [22:13] and who then also succeed. [22:13] because we managed to create a massive and working modesetting driver on a terribly small amount of information [22:14] in a terribly small amount of time too [22:14] no, terribly small is not true [22:14] we got the massive register doc [22:14] and AMD bought us a box full of r500 hw [22:14] hahaha really? [22:14] and ati thought we'd never manage to make the pieces fit together in time [22:14] they sent you hardware? [22:15] bjsnider: they always do [22:15] bjsnider: hw vendors do that to distribution vendors [22:15] news to me [22:15] bjsnider: i am typing to you on a laptop amd gave the radeonhd developers [22:15] as a gift [22:15] for the work we did and to get the support going at the same time (eat your own food) [22:15] if amd had problems changing the ati culture they should have fired them and brought their own people in [22:16] bjsnider: bit hard when you just bought a business for more than your whole company is worth still at that point [22:16] bjsnider: and when you are trying to make money from it [22:17] add some bad management into the mix, and fun things happen [22:17] bjsnider: and about hw vendors giving sw vendors hw, this is normal [22:17] ati's drivers were garbage, total garbage on windows when amd bought ati, and had been for years [22:17] the driver developers were no doubt morons [22:17] but in the r500 case, there was no other option, as part of this hw was created before amd owned ati [22:18] we got preproduction hw after this though [22:18] also, always from amd [22:18] never from ati [22:18] amd made sure it got on our desks [22:18] this was one part of the food chain that ati couldn't choke us on [22:19] s/food/supply/ [22:19] i don't see why it would have been hard for amd to fire the driver team and bring in their own people [22:19] fire everybody else too [22:19] bjsnider: the thing is, when people are used to a certain mode of working, especially when they're not that clued technically, a change in that mode of working is extremely threatening [22:20] bjsnider: people cannot admit it when they are wrong, and then fix things, they keep on fighting that, and they will not change their mode of working because that would mean that those wrong things would become apparent [22:22] this is why i am so popular, i go in and poke the sore spots all the time, and this pisses off people who created those sore spots or who would like to ignore those parts where sore spots turn up [22:22] bjsnider: because firing a driver team means hiring a new one, get them up to speed on the existing driver (which you can't do because you've fired the guys who knew about it), and so on... [22:22] jcristau, have you used windows xp + ati around 5-10 years ago? [22:23] that wasn't a driver, it was a disaster [22:23] there was nothing to save, nothing to bring the new guys up to speed on [22:23] i had so many little bugs and blue screens that it pushed me to nvidia when i couldn't even afford it [22:23] err, hrm [22:24] bjsnider: you just cannot do that, you can fire some rotten apples, and then tell the others to behave [22:24] and the register docs were there somewhere [22:25] bjsnider: btw, there haven't been any register docs since early 2008 [22:26] bjsnider: there were some shader docs, but the latest one was released by a part that at the time was already integrated in AMD [22:26] i wonder why [22:26] bjsnider: i've never used windows xp [22:26] AMD created a gpgpu team in 2007, outside of ati [22:26] jcristau, you're a smart man [22:27] and they are solely responsible for the r800 shader ISA docs [22:27] haven't used windows in like 8 years [22:27] ATI just put it in with the rest of the public docs, thats their only involvement [22:28] in late 2007 early 2008, we had high hopes for going with the gpgpu guys, but then some key ati guys found out about it and killed our last hope of a clear and free information stream [22:30] sounds like the inmates running the asylum [22:30] the amd guys should have authority over ati [22:32] bjsnider: in late 2008 amd sold its foundries [22:33] bjsnider: because they couldn't renegotiate their debt (noone will tell you this, but it stands to reason) [22:33] bjsnider: at this point, ATI was unbelievably powerful and could do whatever they wish [22:33] bjsnider: some people describe ATI as a trojan horse today [22:35] amd's problems are due to their real or imagined inferiority to intel in their main business line [22:35] not because of ati [22:37] bjsnider: sure, but there is more than just that going on [22:38] bjsnider: there are always sidestories happening all the time, all the way down to the individuals [23:28] I just got a new pinetrail netbook and I've loaded up lucid on it [23:29] but it doesn't have direct rendering enabled [23:29] what do I need for 3d? 2.10.0 intel driver? (lucid currently has 2.9.x)