AMD Banks On Flood of Stream Apps 124
Slatterz writes "Closely integrating GPU and CPU systems was one of the motivations for AMD's $5.4bn acquisition of ATI in 2006. Now AMD is looking to expand its Stream project, which uses graphics chip processing cores to perform computing tasks normally sent to the CPU, a process known as General Purpose computing on Graphics Processing Units (GPGPU). By leveraging thousands of processing cores on a graphics card for general computing calculations, tasks such as scientific simulations or geographic modelling, which are traditionally the realm of supercomputers, can be performed on smaller, more affordable systems. AMD will release a new driver for its Radeon series on 10 December which will extend Stream capabilities to consumer cards." Reader Vigile adds: "While third-party consumer applications from CyberLink and ArcSoft are due in Q1 2009, in early December AMD will release a new Catalyst driver that opens up stream computing on all 4000-series parts and a new Avivo Video Converter application that promises to drastically increase transcoding speeds. AMD also has partnered with Aprius to build 8-GPU stream computing servers to compete with NVIDIA's Tesla brand."
Useless without free drivers! (Score:5, Interesting)
Open standard API (Score:4, Interesting)
So... is there an open standard API for this stuff yet that works on hardware from multiple manufacturers?
If not, developing for this feels like writing assembly code for Itanium or the IBM Cell processor. Sure, it'll give you pretty good performance now, but the chances of the code still being useful in 5 years is basically zero.
Re:And someday (Score:3, Interesting)
Re:Useless without free drivers! (Score:2, Interesting)
I think you're letting your personal ideology cloud your view of the world around you.
Most major companies don't. They happily run employee desktops on Microsoft Windows, because they can easily swap them out when they break. They run critical legacy systems on IBM mainframes (or whatever). And they run new critical systems on platforms that are almost entirely FOSS. I'm sure you can easily come up with a counterexample, but they're the exception, not the rule.
Re:Useless without free drivers! (Score:3, Interesting)
What about things like GLSL compilers? Are they in hardware too?
Re:AMD Is Out to Lunch (Score:3, Interesting)
Wow, that's really fascinating, because the Sweeney article you mention has him going on and on about generally programmable vector processors which make heavy use of that SIMD thing you so hate.
Oh wait, I didn't mean fascinating, I meant boring and you're an idiot. Engineers don't implement SIMD instructions because vector processors are easy to program, they implement them because they are cheap enough that they're worth having even if you hardly use them, never mind problem domains like graphics where you're expecting to use them all the time.
(And yes, I did read your article too, just to be charitable. It's amusing that you think the Cell is "a perfect example of how not to design a multicore processor", because the first step of writing software that performs well on the Cell is to break it down into a signal processing chain. What's hilarious, though, is that you think this will make software easier to write. Clearly you haven't tried to write any real software using your proposed system yet, much less worked with a team on it.)
Re:Useless without free drivers! (Score:3, Interesting)
> Any my point is, why? All you need is a decent API.
Well, that assumes closed source can provide a decent API.
Considering the huge amount of bugs even the CUDA compilers have (and they are fairly good compared to others, particularly FPGA synthesis tools) there is a severe risk that you will get stuck in your project without the possibility to do _anything_ about it.
Closed source also leads to such ridiculousness as the disassembler only being available as a third-party tool (decuda) making it even harder to find the bugs in the tools.
(But yes, calling it useless is over-the-top.)