Sarvatthas mesa-utils been in universe for a long time?03:01
Sarvattcant enable compiz or KDE desktop effects without glxinfo... was just messing around on a kubuntu livecd03:01
RAOFI thought compiz now did its own gl extension detection?03:04
RAOFIt'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:04
Sarvattkwin for sure needed mesa-utils installed to enable gl compositing, i couldn't activate it until i manually enabled universe and installed it03:06
Sarvattgrabbing the compiz source to check but i swear it just had glxinfo calls in it when i looked a few days ago03:06
RAOFfile $(which compiz): ELF 64-bit LSB executable.03:07
RAOFIt'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:07
Sarvattah yeah it doesn't need glxinfo anymore outside of the apport hook03:14
Sarvatti see the checks in src/screen.c03:15
RAOFSarvatt: 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:24
Sarvattnope, 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:26
RAOFYou are most welcome to be in bugfixing mode!03:42
SarvattRAOF: doesn't UNE call glxinfo to determine if it should run in 2D or 3D mode?03:48
RAOFThat's a good point!03:49
AtomicSparkSo 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
AtomicSparkIt mentions X, so I figured I'd ask about it in here. ;304:20
Sarvattlooks like kde and wine need some extending to work with nouveau 3D (yay...)04:29
Sarvattkwin/compositingprefs.cpp has the gl vendor strings hardcoded and wine does the same04:30
RAOFkwin hardcodes vendor strings?  Sucky.04:30
Sarvatt(in kdebase-workspace)04:30
Sarvattwell its just determining if gl compositing should be used by default by the vendor so its no so bad in KDE04:38
Sarvattwine on the other hand...04:38
Sarvattis 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 faster04:48
Sarvattyou're working on netbook-launcher now aren't ya RAOF? only reason I'm bugging you about it :)04:49
RAOFSarvatt: Yeah, I am.  You're welcome to bug me about it, but I'm currently turning f-spot into a fusion-powered rocket ship.04:52
Sarvattwell it'd have to be renderer string != Software Rasterizer or contains Mesa || Gallium, OR the opengl version string contains NVIDIA || ATI 05:01
Sarvattsilly 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 string05:03
Sarvattof 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) use05:05
tjaaltonyeah, serial wacom works08:34
tjaaltonapw, 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 break09:10
tjaaltonif we stick to 0.0.1509:11
apwtjaalton, they said they would be supporting .33 drm for some time, which api does that have09:22
jcristau15 i think09:40
tjaaltonapw: yes, but it's still the same problem; harder to run newer kernels with nouveau (needs the newer ddx as well)10:04
tjaaltonand lidrm10:04
apwbut that problem will always exist, upstream does not strive for compatibility10:05
tjaaltonhaven't asked but if nouveau gets out of staging in .34 then they have to10:06
tjaaltonand do what intel is doing, flagging features and turning them on if the userspace works with them10:07
tjaaltonor the other way around10:07
tjaaltonanyway, 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 future10:08
tjaalton(and speaking as the maintainer of an nvidia-only shop)10:08
tseliotaren't you working at the university any more?10:28
tseliotok, I get it now10:29
tjaaltongood, I can't explain the word :)10:32
tjaaltonin this context10:32
tjaalton"place to work" or so10:33
tseliotyes, just wanted to know whether I had to take that literally or not10:34
apwRAOF, about?  did you manage to test the update to the kernel in my red ppa?11:07
RAOFapw: I did; it works.11:24
apwRAOF, the versions with the linux-meta and everything11:24
RAOFYes.  It upgraded fine.11:25
apwRAOF, that worked here on my mini 10v, as far as i can tell ...11:25
apwyou were absolutly right abut the replaces etc not being needed11:25
apwthats great, can i take it you are happy with that kernel (essentially) going into the archive?11:26
RAOFYup.  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
RAOFYes.  I'm happy with that kernel going into the archive.11:27
tseliotsuperm1: I'm setting fglrx's alternative priority to 1000 as having the same priority of nvidia-current can cause unpredictable results when in automatic mode11:27
RAOFAnd tomorrow morning I'll pick up my new intel/nvidia netbook, and see how much nouveau likes switchable graphics.11:30
apwRAOF, 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 appropriate11:31
RAOFWould 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:33
apwRAOF, heh yeah i was assuming i would be in the frame for that, i can get bryceh to help11:34
RAOFThanks.  And with that, I depart.  Like a phantom into the night.11:35
apwRAOF, thanks for you testing help11:40
zniavrehello i posted bur report for legacy 173.22.14 nvidia driver https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/52310814:45
ubottuLaunchpad bug 523108 in nvidia-settings "nvidia x server settings on ubuntu 10.4" [Undecided,New]14:45
zniavrethis morning i tried them again and i got same worrie14:45
zniavreand 173.14.25 solved the problem14:46
zniavrebut i feel plymouth does not work cause im using this driver from nvidia.com14:46
zniavrewhat can i do ? to make driver from repos working ans plymouth running14:48
bjsniderchange your bug report so that it is a packaging request for the newer driver14:48
apwbryceh, how did your testing go on 'red' ...14:49
zniavre_sorry ...14:50
bjsniderzniavre_, 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 one14:52
zniavre_ok i ll try that14:53
bjsniderseems the firmware wasn't activating the gpu fan15:18
Sarvattnouveau 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 mind17:32
hyperairSarvatt: didn't you foresee this coming?17:33
Sarvattyes 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 things17:36
Sarvattfor 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 incompatable17:37
hyperairoh that sucks.17:37
Sarvattthe dumps that newer nvidia GPU support was based off of were just recently found to be completely broken17:38
hyperairand that sucks even more17:38
hyperairi think nv is a better bet for stability purposes then17:38
Sarvatta .33 based nouveau with the old api wont be supported by upstream17:38
hyperairunstable APIs suck17:39
Sarvattthis is alot of risk for something that is basically a gateway to install the blob graphically at this point17:39
jcristauwould be interesting to know whether rhel6 will have nouveau17:39
hyperairis it too late to revert?17:39
Sarvattno 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 package17:40
tjaaltonnouveau works great for me17:46
tjaaltoneh, -nv is crap17:47
tjaaltonno need to go back now17:47
hyperairtjaalton: no new kernels for you17:47
tjaaltonhyperair: well there are ways to go around that17:48
hyperairtjaalton: like using the blob? =p17:48
tjaaltonno, backporting libdrm/ddx too17:48
tjaaltonI'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)17:50
=== radoe_ is now known as radoe
Sarvattit 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:13
Sarvattand 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 miss18:14
libvheh, i just slotted an AIW 9000 into a debian stable: boom.18:15
libvluckily i know my way around a graphics driver a bit18:16
libvbut 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
libvnobody tests anything, as nobody has the ability to deploy new code easily18:16
jcristauwhat's aiw 9000? :)18:17
libvr250 or so18:17
libvall in wonder radeon18:17
johanbrSarvatt, 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 there18:18
libvi am not blaming you for this, btw, just the situation as a whole is messed up18:18
libvjohanbr: i have tried explaining nothing else for the last 5 years18:18
jcristaulibv: well i have no radeon hw so i'm relying on whatever testing happens in unstable before release.18:18
libvjohanbr: the mountain of crap i have received for that is hard to measure.18:18
libvjcristau: as said, not your fault18:19
jcristaulibv: if you have a fix for stable, though, i'll gladly take it :)18:19
libvjcristau: a return right after variable declarations is hardly a fix :)18:19
libvbut it did allow me to test the dri driver18:20
bjsniderlibv, the aiw series of cards hasn't been the best ati had in 8 years or so, not 3 years18:20
libvwhich was a success, as was unichrome18:20
libvbjsnider: 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 radeonhd18:20
libvbjsnider: this was 2.5ys ago18:20
libvbjsnider: 2.5ys ago, r200 had the best 3d support out there18:21
bjsnideri know who you are sir18:21
bjsnideri listened to that talk you delivered recently at the conference18:21
libvonly about 2ys ago, dri was becoming better for r300 than for r20018:21
bjsniderin which the intel guy took strong exception18:21
libvradeon 9000 was one of the later and faster r200s18:22
libvbjsnider: that'd be eric anholt; who did this commit: http://cgit.freedesktop.org/mesa/drm/commit/?id=b549552718:22
bjsniderright, anholt18:23
libvnow r200, at the time, was one of the best supported pieces of hardware out there18:23
libvbut... it still blew up in my face18:23
libvwhy: because people do not go and test things easily18:23
libvpeople cannot deploy a whole graphics driver stack easily18:23
bjsniderbut the aiw cards have tv chips on them as well18:23
libvbjsnider: which is exactly what exploded18:23
bjsniderthe tv chip?18:23
libvbjsnider: no, the code trying to initialise it18:23
bjsniderit never worked very well for me18:24
bjsnidereven back in the day18:24
bjsnideri've got one of those cards sitting around here18:24
libvi inherited this hw, as i did an agp r500, from my gamer cousin, i only pulled it out now to test dri drivers18:24
bjsniderused to use it in mandrake18:24
libvi know that it's early 2000s hw far too well, i recommended this hw to my cousin18:25
libvbut 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 tested18:26
libvthis works for many things, but not for volatile stuff like graphics hw and graphics drivers18:26
libvthe really strange thing is that, what i suggest doing is actually setting the graphics driver developers free to some extent18:27
libvand yet they are against it18:27
Sarvattr100/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:27
libvSarvatt: it's broken on 2.6.32?18:28
libvSarvatt: radeon still has xf86 modesetting18:28
jcristaulibv: ubuntu wanted kms in lucid18:28
Sarvattyeah wth KMS, quite alot of fixes in .33 that didnt make it back to .32 in that area but UMS is fine18:28
libvSarvatt: well, now the ratrace is on completely18:30
libvkernel, libdrm, xorg and mesa will soon be tied 1-1 completely18:30
Sarvattwhat'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 commit18:31
libvSarvatt: where are most of those bugs situated anyway?18:32
libvSarvatt: in the mesa code itself, or in the drivers?18:32
libv(that would be a mightily interesting datapoint for me)18:32
jcristaumy guess would be drivers, but i haven't looked.18:33
Sarvattdo you mean the drivers in mesa or the x drivers?18:33
libvSarvatt: we're talking about mesa, so the drivers in mesa :)18:33
libvwhat do you have to patch up most?18:34
libvsrc/mesa/ or src/mesa/drivers/dri/*18:34
jcristau(but then i've never had to update mesa in a stable release)18:34
Sarvattits both really but probably moreso the drivers18:35
libvSarvatt: ah, but this is probably seen as "both" because they are one whole right now18:35
libvguess what i was testing the aiw 9000 for :)18:35
Sarvattdo you count swrast as a driver? :)18:35
libvhehe :) in my world, no, as it conflicts with src/mesa/drivers/common/driverfuncs.c18:36
libvwhich all normal drivers do use18:37
libvbut the line is kind of blurry there18:37
Sarvattthey 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.118:38
libvSarvatt: even though it's only the radeon/r200/r300/r600 dri and gallium drivers that require that18:39
Sarvattmesa 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 stablebranch18:39
libvit's a mess18:39
libvsomeone asked me recently about how i see the future of mesa, with the tungsten people now part of vmware18:40
libvwhich is an interesting thought :)18:40
Sarvattyeah 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 see18:42
jcristauhaving 3 build systems is what prevents it from having a sane one :)18:44
tjaaltonSarvatt: the sru process is way too heavy imo, and having point releases would be nice18:48
tjaaltonwhy not put the whole point-release as a sru18:49
tjaaltonand keep it in -proposed for some time18:49
Sarvattfor 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 release18:51
Sarvattmesa 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 libdrm18:53
libvthe intel libdrm bump doesn't promise much good there18:55
libvthe really cool thing is, main mesa-dri only depends on libdrm 2.3.018:56
Sarvattthats 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 mistaken18:57
Sarvatttrying to work out why nvidia requires glx explicitly enabled in an xorg.conf now18:58
tjaaltonSarvatt: did you enable the blob, so that the alternatives are fixed?19:00
Sarvatthmm, 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 laptop19:01
Sarvattyeah glx is fine, forgot i did check it because i was using compiz19:15
Sarvattlooks 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.conf19:17
Sarvatteven though -- ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"19:18
Sarvatthaving an alternative for libglx.so would solve that but yuck19:24
brycehhi Sarvatt19:33
Sarvatthttp://pastebin.com/0nGXwtDX (no xorg.conf) vs http://pastebin.com/9G9LM0k4 (xorg.conf with glx forcibly loaded)19:33
brycehSarvatt, regarding your earlier concerns... I don't think he's made it public yet but RAOF has drafted a stabilization plan for nouveau.  19:34
brycehwe 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 expected19:35
brycehRAOF 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:36
Sarvattcould be really hacky and change xorg-server/hw/xfree86/common/xf86AutoConfig.c to add a device section with glx enabled always :)19:44
Sarvatterr module section I mean19:45
jcristauSarvatt: explicit Load "glx" vs default loading makes a difference?19:45
jcristauthat sounds like a bug to me...19:45
Sarvattyup, it ignores the ModulePath option for loading modules but loads drivers from ModulePath fine19:46
SarvattModulePath 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
SarvattSection "Module"19:47
Sarvatt        Load    "glx"19:47
jcristauthat's not modules vs driver..19:49
bjsniderlibv, how is the openchrome driver's 3d/compositing coming along?21:47
libvbjsnider: i am the guy who writes unichrome.21:47
libvopenchrome is the people who forked away from me because i wouldn't accept vbe and was working on real modesetting21:48
libvthis real modesetting was deemed useless at the time.21:48
libvand openchrome is just the xorg driver21:49
jcristauhow's via kms coming along then? :)21:50
libvjcristau: ask via :)21:50
libvopenchrome is basically a dead project21:50
libvthere is a guy doing some useful work fixing bugs though21:50
libvbut that's all it is21:51
libvoh, yeah, ivor hewitt pointed IDA at a more recent libddmpeg.so from via and added xvmc support for a few other chipsets too21:51
libvhis second contribution to free software in a decade21:51
bjsniderdoes the driver you are working on do compositing?21:51
libvbjsnider: nope, but sadly unichrome is just turning out to be a playground for future technology21:52
bjsnidergee, that's funny21:52
libveven though all i try to be as directly useful and immediately deployable and backwards compatible21:53
libvturns out that those goals means that i am shaping the future each time :)21:53
bjsniderthe gnome-shell guys said they had to work on via's driver to help it along so g-s would work with it21:53
libvtells one more about the current state of free software graphics than anything else21:53
libvbjsnider: yes, VIA's driver.21:54
libvbjsnider: VIA now claims it is working with openchrome, but it is not a symbiosis21:54
bjsnideri'd say free software graphics are pretty much a disaster at this point21:54
bjsniderbut whatever21:54
bjsniderthat's not a friggin' secret21:54
libvbjsnider: i know, and i have been working my ass off on changing that, sadly things don't work out too well each time21:54
libvthey do to some extent, as quite a few things of what i have done have been taken on, usually in a reinvented form21:55
libvin any case, unichrome is not a dead project, it's just me.21:56
libvopenchrome 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 via21:56
bjsnideri don't think the g-s guys were helping to develop a closed-source driver, i think it was openchrome21:56
libvvia 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 working21:57
libvi haven't seen any changes to the exa code on openchrome in the second half of the decade21:58
bjsniderjon nettlet21:58
libvhe talks.21:58
libvnever acts.21:58
libv"the openchrome people, who are trying way too hard to be relevant without doing actual code"21:58
bjsniderhe seems to be very active to me, although i'm not sure about the openchrome thing21:59
bjsniderhe's very active in the gnome-shell project and other gnome-related things21:59
libvhe is active in talking21:59
libvnot in doing21:59
libvi do not follow gnome development directly, i am following enough already doing graphics drivers :)22:00
libvbut on the openchrome side, he just talks.22:00
libvgang65 is bartosz, the guy who actually works when he finds time, and who fixes bugs22:00
libveveryone is just talking out of the wrong ends of their bodies.22:01
libveveryone else that is22:01
bjsnidereveryone's wrong but you...22:01
libvbjsnider: not everyone, and not on everything, but quite a few are on many things i whine about22:02
libvhence why i whine about them22:02
bjsniderthat's funny, because i thought everyone was wrong except me22:02
bjsniderso i might be wrong about that22:02
libvi liked the mark twain on the new ubuntu style notepad22:03
libv"The man with a new idea is a crank until the idea succeeds."22:04
bjsniderwhat's happening with the radeonhd driver? is that dead?22:05
libvbjsnider: novell fired 20% of devs in nue22:05
libvbjsnider: leaving me jobless, and leaving my colleagues unable to handle anything anymore22:05
libvamd also stopped formally working on it, as it had severe financial difficulties22:06
libvso ATIs plan succeeded22:06
bjsniderand what was ati's plan?22:06
bjsniderif ATI has ever had any plan for anything, this will be the first i've heard of it22:07
libvbjsnider: 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 driver22:07
libvbjsnider: i can spend many hours explaining what happened and provide many instances that can be deemed "highly curious" behaviour22:07
libvi usually hold the same monologue at least once per month22:08
bjsniderwhat competing driver? xf86-video-ati or radeonhd?22:08
bjsniderthat's  really old driver22:08
libvbjsnider: r500 support in radeon happened late november22:08
libvbjsnider: radeonhd development started late july of the same year22:09
bjsnideri see what you're getting at22:09
libvbjsnider: it is surprising how little people even know that little fact22:09
bjsnideryou think it was a redhat vs. novell thiing?22:10
libvbjsnider: 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 + rh22:11
libvATI versuse AMD and redhat versuse SuSE22:11
libvversuse :)22:12
bjsniderati and amd are the same thing during this22:12
libvbjsnider: 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 happy22:12
libvand if your mothercompany then says "fine, you're not doing it, we know some guys who will"22:13
libvand who then also succeed.22:13
libvbecause we managed to create a massive and working modesetting driver on a terribly small amount of information22:13
libvin a terribly small amount of time too22:14
libvno, terribly small is not true22:14
libvwe got the massive register doc22:14
libvand AMD bought us a box full of r500 hw22:14
bjsniderhahaha really?22:14
libvand ati thought we'd never manage to make the pieces fit together in time22:14
bjsniderthey sent you hardware?22:14
libvbjsnider: they always do22:15
libvbjsnider: hw vendors do that to distribution vendors22:15
bjsnidernews to me22:15
libvbjsnider: i am typing to you on a laptop amd gave the radeonhd developers22:15
libvas a gift22:15
libvfor the work we did and to get the support going at the same time (eat your own food)22:15
bjsniderif amd had problems changing the ati culture they should have fired them and brought their own people in22:15
libvbjsnider: bit hard when you just bought a business for more than your whole company is worth still at that point22:16
libvbjsnider: and when you are trying to make money from it22:16
libvadd some bad management into the mix, and fun things happen22:17
libvbjsnider: and about hw vendors giving sw vendors hw, this is normal22:17
bjsniderati's drivers were garbage, total garbage on windows when amd bought ati, and had been for years22:17
bjsniderthe driver developers were no doubt morons22:17
libvbut in the r500 case, there was no other option, as part of this hw was created before amd owned ati22:17
libvwe got preproduction hw after this though22:18
libvalso, always from amd22:18
libvnever from ati22:18
libvamd made sure it got on our desks22:18
libvthis was one part of the food chain that ati couldn't choke us on22:18
bjsnideri don't see why it would have been hard for amd to fire the driver team and bring in their own people22:19
bjsniderfire everybody else too22:19
libvbjsnider: 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 threatening22:19
libvbjsnider: 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 apparent22:20
libvthis 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 up22:22
jcristaubjsnider: 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
bjsniderjcristau, have you used windows xp + ati around 5-10 years ago?22:22
bjsniderthat wasn't a driver, it was a disaster22:23
bjsniderthere was nothing to save, nothing to bring the new guys up to speed on22:23
bjsnideri had so many little bugs and blue screens that it pushed me to nvidia when i couldn't even afford it22:23
libverr, hrm22:23
libvbjsnider: you just cannot do that, you can fire some rotten apples, and then tell the others to behave22:24
bjsniderand the register docs were there somewhere22:24
libvbjsnider: btw, there haven't been any register docs since early 200822:25
libvbjsnider: there were some shader docs, but the latest one was released by a part that at the time was already integrated in AMD22:26
bjsnideri wonder why22:26
jcristaubjsnider: i've never used windows xp22:26
libvAMD created a gpgpu team in 2007, outside of ati22:26
bjsniderjcristau, you're a smart man22:26
libvand they are solely responsible for the r800 shader ISA docs22:27
jcristauhaven't used windows in like 8 years22:27
libvATI just put it in with the rest of the public docs, thats their only involvement22:27
libvin 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 stream22:28
bjsnidersounds like the inmates running the asylum22:30
bjsniderthe amd guys should have authority over ati22:30
libvbjsnider: in late 2008 amd sold its foundries22:32
libvbjsnider: because they couldn't renegotiate their debt (noone will tell you this, but it stands to reason)22:33
libvbjsnider: at this point, ATI was unbelievably powerful and could do whatever they wish22:33
libvbjsnider: some people describe ATI as a trojan horse today22:33
bjsnideramd's problems are due to their real or imagined inferiority to intel in their main business line22:35
bjsnidernot because of ati22:35
libvbjsnider: sure, but there is more than just that going on22:37
libvbjsnider: there are always sidestories happening all the time, all the way down to the individuals22:38
cndI just got a new pinetrail netbook and I've loaded up lucid on it23:28
cndbut it doesn't have direct rendering enabled23:29
cndwhat do I need for 3d? 2.10.0 intel driver? (lucid currently has 2.9.x)23:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!