the software (drivers, SDK) is crap and the ATI developers don't give a damn about GPGPU. "Support" (for application developers) is essentially absent
I ran for a while an ATI GPU application developed by Raistmer to run SETI@home work. While he got it running, what he had to say about the ATI development environment and improvement thereof was even less happy than this.
So AMD is losing the supercomputer application of GPUs to nVidia.
Tullio
To put our experience with OpenCL in short: For GPU computing ("GPGPU"), buy NVidia. The ATI cards are great, powerful hardware, but the software (drivers, SDK) is crap and the ATI developers don't give a damn about GPGPU. "Support" (for application developers) is essentially absent.
Sorry, we're quit frustrated by ATI over here.
BM
I see messages like this in almost every project working on ATI OpneCL apps.
Nevertheless, your Albert@home project has a very stable and good working app, running on GPU's and also on APU's.
I'm shure that OpenCL will work better in the future and the speed difference will be less, then the price/energy factor will be of greater interest.
To give hard facts for those who don't run Albert:
The BRP 1.22 needs on
nVidia GTX550ti ~ 1 hr 773 GFLOPS
HD5830 ~ 1:45 2464 GFLOPS
HD6550 (A8 APU) ~ 3:00 880 GFLOPS
(win7 x64, 8GB, 7.0.18)
Price/Energy:
A8: 4 CPU's @ 3GHz (no L3) + 1 APU all together TDP of 100 Watt, € 125.-
So AMD is losing the supercomputer application of GPUs to nVidia.
Tullio
They never really had it. Nvidia has been dominant in this sector for a long time. ATI hardware is very good, but as others have said overall support is poor. I remember early on AMD was actually very good on folding@home, but those days are long gone it seems.
OP: probably worthwhile to wait a bit for Kepler. The things are supposed to be computer powerhouses, so they will most likely be worth the price of admission.
To put our experience with OpenCL in short: For GPU computing ("GPGPU"), buy NVidia. The ATI cards are great, powerful hardware, but the software (drivers, SDK) is crap and the ATI developers don't give a damn about GPGPU. "Support" (for application developers) is essentially absent.
So AMD is losing the supercomputer application of GPUs to nVidia.
Tullio
They never really had it. Nvidia has been dominant in this sector for a long time. ATI hardware is very good, but as others have said overall support is poor. I remember early on AMD was actually very good on folding@home, but those days are long gone it seems.
those days might be long gone for F@H, but not so for other projects. so long as there still exist DC projects that have applications optimized for ATI GPU and pique my interest, i'll continue to buy both AMD and nVidia GPUs for my crunching needs.
it sucks that AMD's developer support is this discouraging, so i applaud folks like Raistmer who, as archae86 already mentioned, wrote ATI CAL apps for SETI@Home Astropulse and Multibeam...particularly the former, b/c while Multibeam tasks were faster on nVidia hardware by a factor of ~6, Astropulse tasks were faster on AMD hardware by a factor of 20+. also consider Milkyway@Home, Collatz Conjecture, and PrimeGrid, all of which run far more efficiently on AMD hardware.
so i applaud folks like Raistmer who, as archae86 already mentioned, wrote ATI CAL apps for SETI@Home Astropulse and Multibeam...particularly the former, b/c while Multibeam tasks were faster on nVidia hardware by a factor of ~6, Astropulse tasks were faster on AMD hardware by a factor of 20+. also consider Milkyway@Home, Collatz Conjecture, and PrimeGrid, all of which run far more efficiently on AMD hardware.
Raistmer's apps are Brook+ for the Hybrid Astropulse app, and OpenCL for the Astropulse and Multibeam apps, Not CAL, and OpenCL Astropulse is not 20 times slower on Nvidia hardware, given equivalent hardware, performance is reasonably similar.
I run a pair of 6950's crunching at also have a 560ti I use on GPUGRID.(different computers).I tried running the 560ti on milkyway+it took just over 7 mins.to complete a task vs.1 min 8secs on one of the 6950's,so the AMD cards are about 6.5x faster than the ATI card.On any double precision tasks the AMD cards will spank the ATI cards!!!!
ATI is owned by AMD, I think you mixed up ATI and NVIDIA?
I think as Bernd has already stressed, AMD/ATI cards are magnificant pieces of hardware, and if you program then in ATI's native code, yes, they will outperform NVIDIA card of the same price range in many cases. But it is quite understandable, IMHO, that projects would prefer to use OpenCL code (running on both platforms), with just one codebase (less error prone, less effort to maintain, more likely to cross-validate).
LOL nothing's changed in 25 years for ATI..theoretically the best hardware in the industry totally crippled by the worst software/drivers.
Always had the worst software, apparently always will.
AMD/ATI cards are magnificant pieces of hardware, and if you program then in ATI's native code, yes, they will outperform NVIDIA card of the same price range in many cases. But it is quite understandable, IMHO, that projects would prefer to use OpenCL code (running on both platforms), with just one codebase (less error prone, less effort to maintain, more likely to cross-validate).
Note that there is no "native code" for ATI or NVidia cards, at least none that is accessible for programming. There are various APIs, some of which (Stream/CAL, CUDA) are vendor-specific, and some cover many different devices of different vendors (OpenCL). But OpenCL is an API, a language extension, nothing more. You could write OpenCL code that only runs on one particular device, or only on a given group of devices (e.g. vendor). And in fact to use a particular device to its full potential, you need to do exactly that. At current state of OpenCL platform independence is an illusion, particularly if performance is paramount. And BTW OpenCL doesn't usefully specify numeric precision, rounding etc. OpenCL doesn't save you from numerical differences (that cause validation issues) either.
RE: RE: the software
)
So AMD is losing the supercomputer application of GPUs to nVidia.
Tullio
RE: To put our experience
)
I see messages like this in almost every project working on ATI OpneCL apps.
Nevertheless, your Albert@home project has a very stable and good working app, running on GPU's and also on APU's.
I'm shure that OpenCL will work better in the future and the speed difference will be less, then the price/energy factor will be of greater interest.
To give hard facts for those who don't run Albert:
The BRP 1.22 needs on
nVidia GTX550ti ~ 1 hr 773 GFLOPS
HD5830 ~ 1:45 2464 GFLOPS
HD6550 (A8 APU) ~ 3:00 880 GFLOPS
(win7 x64, 8GB, 7.0.18)
Price/Energy:
A8: 4 CPU's @ 3GHz (no L3) + 1 APU all together TDP of 100 Watt, € 125.-
Alexander
RE: So AMD is losing the
)
They never really had it. Nvidia has been dominant in this sector for a long time. ATI hardware is very good, but as others have said overall support is poor. I remember early on AMD was actually very good on folding@home, but those days are long gone it seems.
OP: probably worthwhile to wait a bit for Kepler. The things are supposed to be computer powerhouses, so they will most likely be worth the price of admission.
RE: To put our experience
)
Well, thanks for the effort anyways. :)
RE: RE: So AMD is losing
)
those days might be long gone for F@H, but not so for other projects. so long as there still exist DC projects that have applications optimized for ATI GPU and pique my interest, i'll continue to buy both AMD and nVidia GPUs for my crunching needs.
it sucks that AMD's developer support is this discouraging, so i applaud folks like Raistmer who, as archae86 already mentioned, wrote ATI CAL apps for SETI@Home Astropulse and Multibeam...particularly the former, b/c while Multibeam tasks were faster on nVidia hardware by a factor of ~6, Astropulse tasks were faster on AMD hardware by a factor of 20+. also consider Milkyway@Home, Collatz Conjecture, and PrimeGrid, all of which run far more efficiently on AMD hardware.
RE: so i applaud folks like
)
Raistmer's apps are Brook+ for the Hybrid Astropulse app, and OpenCL for the Astropulse and Multibeam apps, Not CAL, and OpenCL Astropulse is not 20 times slower on Nvidia hardware, given equivalent hardware, performance is reasonably similar.
Claggy
I run a pair of 6950's
)
I run a pair of 6950's crunching at also have a 560ti I use on GPUGRID.(different computers).I tried running the 560ti on milkyway+it took just over 7 mins.to complete a task vs.1 min 8secs on one of the 6950's,so the AMD cards are about 6.5x faster than the ATI card.On any double precision tasks the AMD cards will spank the ATI cards!!!!
Hi >the AMD cards will
)
Hi
>the AMD cards will spank the ATI
ATI is owned by AMD, I think you mixed up ATI and NVIDIA?
I think as Bernd has already stressed, AMD/ATI cards are magnificant pieces of hardware, and if you program then in ATI's native code, yes, they will outperform NVIDIA card of the same price range in many cases. But it is quite understandable, IMHO, that projects would prefer to use OpenCL code (running on both platforms), with just one codebase (less error prone, less effort to maintain, more likely to cross-validate).
HBE
LOL nothing's changed in 25
)
LOL nothing's changed in 25 years for ATI..theoretically the best hardware in the industry totally crippled by the worst software/drivers.
Always had the worst software, apparently always will.
RE: AMD/ATI cards are
)
Note that there is no "native code" for ATI or NVidia cards, at least none that is accessible for programming. There are various APIs, some of which (Stream/CAL, CUDA) are vendor-specific, and some cover many different devices of different vendors (OpenCL). But OpenCL is an API, a language extension, nothing more. You could write OpenCL code that only runs on one particular device, or only on a given group of devices (e.g. vendor). And in fact to use a particular device to its full potential, you need to do exactly that. At current state of OpenCL platform independence is an illusion, particularly if performance is paramount. And BTW OpenCL doesn't usefully specify numeric precision, rounding etc. OpenCL doesn't save you from numerical differences (that cause validation issues) either.
BM
BM