Re: [gentoo-user] Re: ebuild for recent ATI driver, whom to go to?
2008/12/14 James wirel...@tampabay.rr.com: should have said profiler Breaking down algorithms and make a fundamentally better algo for a gpu, will require a really good profiler to imho. So far I'd be happy at being able to run something and leave the evaluation of gains at a theoretical level. Anyway, it seems to me that all that is needed is to have the GPU compiler running on the host system. I wouldn't think that the code produced or the binding code for the CPU would then require us to pull in glibc-2.2.5. But then, I never used Brook+ or Cal. Me either. I was waiting until somebody in the gentoo community got things at least functional, before obtaining a high end video card for GPU experimentation and programming. I guess I'll just have to wait a little bit longer I'm not a very experienced Linux user, I've been using FreeBSD for longer. At work I keep a subtree of a gentoo kernel-2.4/glibc-2.3 which I do not update for chroot whenever I need to compile things for a 2.4 kernel. Do you (anyone?) have any hints on the less inconvenient way to run glibc-2.2.5 programs on Gentoo? -- Miguel Ramos 2...@miguel.ramos.name GnuPG ID 0xA006A14C
Re: [gentoo-user] Re: ebuild for recent ATI driver, whom to go to?
2008/12/11 James [EMAIL PROTECTED]: ATI Stream Computing Support It seems that with ATI Catalyst 8.12, we commoners can finally access and program so that the GPU is another available processor for us to access and use. Anyone with information, particularly relate to 'howto' use an ATI GPU under gentoo, would be of keen interest to me. I'm wondering if the aforementioned (experimental) ebuild would address basic access to the GPU? Thanks for the info. It really looks like the 8.12 is more recent than the 8.54.3 after all... I'm going to try to install this one and I'll get back to you. As to GPU programming, I'm certainly there too! However, there is another obstacle on the way, the AMD Brook+ and Cal toolkits seem to be linked to glibc-2.2.5 !! That's way too old for Gentoo. Perhaps some Gentoo expert can point us the less inconvenient way to work around that one. -- Miguel Ramos [EMAIL PROTECTED] GnuPG ID 0xA006A14C
Re: [gentoo-user] Re: ebuild for recent ATI driver, whom to go to?
2008/12/11 James wirel...@tampabay.rr.com: Did you see this? http://techreport.com/discussions.x/15886 I sure hope we get at least a function level profile that works with gcc with Catalyst 8.12. I await your respone. I took a look at your link but I can't see what I was expected to see. Anyway, it seems to me that all that is needed is to have the GPU compiler running on the host system. I wouldn't think that the code produced or the binding code for the CPU would then require us to pull in glibc-2.2.5. But then, I never used Brook+ or Cal. -- Miguel Ramos 2...@miguel.ramos.name GnuPG ID 0xA006A14C
Re: [gentoo-user] Re: ebuild for recent ATI driver, whom to go to?
2008/12/11 Nikos Chantziaras rea...@arcor.de: Same here, plus that switching to VTs and back to X a couple of times hangs the machine. That's has always the case with fglrx, with any version ever produced, on any distro you can imagine. Oh, I can't believe! I'm almost sure at some point this afternoon I got it not crashing. But in the meanwhile I changed my kernel config. I was using a lot of kernel debug options because I installed Gentoo the other day and had to go to kernel 2.6.27 because of the wireless, and this kernel comes with lots of debug options active. While experimenting with different driver versions and changed the kernel config to include less debuging... I wonder if this is the reason... I should never have changed two things at the same time... -- Miguel Ramos 2...@miguel.ramos.name GnuPG ID 0xA006A14C
Re: [gentoo-user] Re: ebuild for recent ATI driver, whom to go to?
On Friday 12 December 2008 01:24:27 Nikos Chantziaras wrote: Neil Bothwick wrote: On Thu, 11 Dec 2008 22:16:59 +, Miguel Ramos wrote: I did put the lengthly list of files in package.keywords with ~amd64, but I'm not sure this is the beast approach in the long run. Make /etc/portage/package.keywords a directory, then run autounmask x11-base/xorg-server, which will create a separate file in that directory. That way all your keywording for xorg is kept separate from other packages you may wish to run as ~arch. That failed. I had to keyword autounmask itself first (the stable version isn't stable.) Then did the above command. All it did was creating a file autounmask-xorg-server with this inside: # --- # BEGIN: x11-base/xorg-server-1.5.3 # --- =x11-base/xorg-server-1.5.3 ~amd64 # --- # END: x11-base/xorg-server-1.5.3 # --- Obviously, that isn't doing anything useful. Because there is no such version of xorg-server in portage. Latest is 1.5.2 -- alan dot mckinnon at gmail dot com
