Slashdot Log In
AMD Banks On Flood of Stream Apps
Posted by
timothy
on Thu Nov 13, 2008 08:22 PM
from the streams-come-with-banks-anyhow dept.
from the streams-come-with-banks-anyhow dept.
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."
Related Stories
[+]
Hardware: NVIDIA Shaking Up the Parallel Programming World 154 comments
An anonymous reader writes "NVIDIA's CUDA system, originally developed for their graphics cores, is finding migratory uses into other massively parallel computing applications. As a result, it might not be a CPU designer that ultimately winds up solving the massively parallel programming challenges, but rather a video card vendor. From the article: 'The concept of writing individual programs which run on multiple cores is called multi-threading. That basically means that more than one part of the program is running at the same time, but on different cores. While this might seem like a trivial thing, there are all kinds of issues which arise. Suppose you are writing a gaming engine and there must be coordination between the location of the characters in the 3D world, coupled to their movements, coupled to the audio. All of that has to be synchronized. What if the developer gives the character movement tasks its own thread, but it can only be rendered at 400 fps. And the developer gives the 3D world drawer its own thread, but it can only be rendered at 60 fps. There's a lot of waiting by the audio and character threads until everything catches up. That's called synchronization.'"
[+]
S3 Jumps On GPGPU Bandwagon 86 comments
arcticstoat writes "It's sometimes easy to forget that the PC graphics market isn't owned by ATI and Nvidia, and the company that first gave us 3D acceleration, S3, is very much still around. So much so, in fact, that it's now even developed its own GPGPU technology. S3 claims that its Chrome 400 chips can accelerate gaming physics, HD video transcoding/encoding and photo enhancement. To demonstrate the latter, S3 has released a free download called S3FotoPro, which enhances color clarity and reduces haze in photos. However, the company hasn't yet revealed whether it plans to support OpenCL in the future."
The Tech Report also points out that this could allow S3's parent company, VIA, to compete with Intel and AMD in graphics processing technology.
Submission: AMD banks on flood of Stream apps by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Useless without free drivers! (Score:5, Interesting)
Re:Useless without free drivers! (Score:4, Insightful)
Surely I'm not the only one who thinks this'll be useless without open-source drivers, so you can actually make your fancy cluster use these vector-processing units.
You may or may not be surprised by this, but not all of the magic happens in hardware, which is why you don't see open sourced drivers for a lot of stuff.
Sometimes it just makes sense to put the optimizations in the driver, so that when you tweak them later, you don't have to flash the BIOS.
Parent
Re: (Score:2)
Think.
GPGPU is USELESS unless it is in hardware. It is were a "driver thing", it couldn't possibly work. Indeed, the GPGPU user would get worse performance, because the multiple execution units would have to be simulated...
So, these "optimizations" are not in the driver.
Re: (Score:3, Interesting)
What about things like GLSL compilers? Are they in hardware too?
No, really useless. Hence the reason AMD opened up (Score:2)
That was true in the mid-90s, when drivers meant the difference between 10fps and 30fps. We're in the late 00s now, where drivers are as thin as possible, so that APIs are sitting right on top of hardware commands, and compiling shaders is the about the only thing left to do with software alone.
Any such optimizations or color corrections are typicall
Re: (Score:3, Insightful)
Plenty of people seem to be getting serious work done with NVidia's proprietary Linux CUDA drivers.
blah blah blah (Score:2, Insightful)
You chose to run on a platform knowing full well these things aren't likely to be supported. Very little sympathy from me. Sorry.
If you want to encourage more drivers on your platform of chose, perhaps you might consider making it easier for hardware companies to target your kernel. Maybe consider, oh I don't know, a stable, predictable ABI?
Maybe loose the attitude as well. The world doesn't owe you or your OS choices anything. All you can do is focus your efforts at making your platform of choice at
Re: (Score:3, Informative)
We're not talking about video games here. Some people use computers for important work, not just for screwing around.
Re:Useless without free drivers! (Score:5, Funny)
We're not talking about video games here. Some people use computers for important work, not just for screwing around.
How dare ye!
Parent
Re:Useless without free drivers! (Score:5, Informative)
Yes, thank you for telling me. I use mine for cancer research. That includes GPGPU, by the way. Yes, I'm serious.
I don't believe I know anyone who uses the source code for their video driver. All the GPGPU people use one of the GPU programming languages. The hard core ones use assembly. The young 'uns will grow up with CUDA. None of those requires the source code for the driver.
Parent
Re: (Score:2)
i think the point is that if you want to use GPGPU for cluster computing it's ideal to have open source drivers, especially if you're not going to release Linux/Unix drivers yourself.
Re:Useless without free drivers! (Score:5, Insightful)
Any my point is, why? All you need is a decent API. Claiming it's useless without open source drivers is just a silly ruse by an open source zealot to advance an agenda.
Open source has a lot of things going for it, but it's more fanatical followers are not among them.
Parent
Re:Useless without free drivers! (Score:4, Insightful)
what agenda are they advancing? the agenda of being able to use this feature on the platform they are running?
sure, if all hardware manufacturers were in the habit or releasing Unix & Linux drivers then closed-source binaries and a decent API would be fine. but the reality is that many manufacturers do not have good Linux/Unix support. that is fine. but if they want to leave it to the community to develop the Linux/Unix drivers themselves then it would be really helpful to have open source Windows drivers to use as a template.
it's not useless to you since you're running Windows, but not everyone uses a Windows platform for their research. for those people it would be useless without either, open source drivers or a set of Linux/Unix drivers. i mean, if you're already running a Beowulf cluster of Linux/BSD/Solaris machines then it might not be practical to convert them to a Windows cluster (can you even run a Beowulf cluster of Windows machines?), not to mention the cost of buying 64 new Windows licenses and porting all of your existing applications to Windows.
it's probably an exaggeration to say that closed-source drivers are useless. and perhaps AMD will release Linux/Solaris/Unix drivers. but if they're not going to then open sourcing the Windows drivers and the hardware specs would be the next best thing. and the outcry for open source drivers isn't without some merit since past Linux support by AMD/ATI with proprietary drivers have left much to be desired, with Linux drivers only receiving updates half as a often as the Windows drivers and consistently underperforming against comparable graphics cards.
Parent
Re:Useless without free drivers! (Score:5, Insightful)
It's fine to lobby for open source drivers. It's also great if you want to run something on your chosen platform and you want the company who makes the hardware to support that. Both of those I can wholeheartedly support.
Claiming that something is useless without open source drivers is either dishonest or deluded. As I said, I don't think the important goals of the open source movement are served by either lying or ranting about your delusions.
Parent
When I was a kid, my mom used to tell me (Score:3, Insightful)
If something hurts, stop doing it.
You expect the world to cater to your lifestyle choices. You made the choice to run a platform that isn't well supported by video card manufacturers. Either stop using the platform, or find video cards that work on your platform. What if there is no good video cards for your platform? Tough luck. Sorry. You should have cons
Re:When I was a kid, my mom used to tell me (Score:5, Informative)
i'm a graphic designer so run Windows. i haven't touched Linux or Unix in over half a decade. but i'm not a selfish jackass who thinks that only my needs are important, and as long as they are met everyone should just go to hell.
there's nothing arrogant about expecting hardware manufacturers to support the 3 most popular OSes: Windows, OS X, and Linux. and it's precisely because people understand that hardware manufacturers can't be expected to support every single OS out there (even well-known ones like Solaris, FreeBSD, BeOS, etc.) that people are pushing for open source drivers.
your mom may not have told you this, but businesses depend on their customers to make money. so listening to consumers and meeting consumer demands is generally a good idea (ever heard of market research?). by allowing their hardware to be used on a wider range of platforms they are broadening the market for their products.
AMD isn't in the business of selling video card drivers, just the video cards. that is why they have open sourced their Radeon drivers in the past. and if we were all as simple-minded as your mom, then no one would ever speak up for themselves. and hardware manufacturers aren't run by mind readers.
Parent
Re:When I was a kid, my mom used to tell me (Score:4, Insightful)
You expect the world to cater to your lifestyle choices.
Of course - we are a customer base, and we expect to have our needs catered to.
ou made the choice to run a platform that isn't well supported by video card manufacturers. Either stop using the platform, or find video cards that work on your platform. What if there is no good video cards for your platform? Tough luck. Sorry. You should have considered that before installing the OS, eh?
Third choice: lobby for support from major chip manufacturers. What makes you think a large group of users is powerless, anyway? 5% of 100M is 5MM people, with some of them having cause to buy 100+ units of product.
It is beyond arrogant to expect the world to cater to your choice of operating system.
Don't need the world. Just need a couple companies.
Parent
Re: (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 hard
Re: (Score:2)
And Google just serves web pages, which doesn't require access to the source code for the web server. That doesn't mean that they'd be caught dead using a binary blob for a web server. It's just not an acceptable business risk.
It's like having backups. Sure, restoring from backups isn't part of the plan, but not having backups isn't a risk that anyone takes with important business data. Personally, I'd consider my research data to be even more important
And someday (Score:4, Funny)
Lord only knows what kinds of boobie traps they put in power supplies. The CIA and the NFL probably know more about you then you realize thanks to that "120V power supply" on the back of each computer in Google's data center. I mean, unless you have the schematics, how do you really know what it is doing?
You dont. Neither does Google. The wise are already beginning to short GOOG. Will their shareholders wake up and demand schematics? Only time will tell.
Parent
Re: (Score:3, Interesting)
Re:Useless without free drivers! (Score:4, Insightful)
Like I said about zealots making things up....
Your argument about the business world not using non-open source is spot on. Excellent example. Of COURSE nobody would trust their critical systems to, say, an OS they don't have the source for! Never mind closed source apps! Naturally they only buy video cards that have open source drivers too.
Parent
Re: (Score:3, Informative)
I think you're letting your personal ideology cloud your view of the world around you.
I think you missed the sounds of sarcasm. Not too hard to do, as it was confusingly mixed with some other, simpler HHOS-style text.
Of COURSE nobody would trust their critical systems to, say, an OS they don't have the source for!
Most major companies don't. They happily run employee desktops on Microsoft Windows, because they can easily swap them out when they break.
Not a critical system, then. Critical systems are the machines that cause serious problems when they fail.
They run critical legacy systems on IBM mainframes (or whatever). And they run new critical systems on platforms that are almost entirely FOSS.
IBM sells more Linux than AIX today, and they sell quite a bit of Linux across their line, at least on the systems-formerly-known-as-S/390-and-RS/6000. I'm not sure if I'm disagreeing with you, or proving your point, but whatever.
All I know for sure is that the EULA for Wind
I for one... (Score:2)
...welcome our new GPGPU overlords.
All I'm wondering is why it took so long? They are in the business of selling hardware, and if we can find a new use for it, then we're more likely to purchase AMD/ATI's hardware.
What they might have been waiting for (Score:2)
All I'm wondering is why it took so long? They are in the business of selling hardware, and if we can find a new use for it, then we're more likely to purchase AMD/ATI's hardware.
A new driver that would turn a consumer-grade high-end video card into an easy-to-use midrange supercomputer? More powerful than the stuff the US nuclear weapon programs were using when they designed the last batch of bombs?
Maybe they were waiting for a congress and president that they don't think will declare their graphics cards
Re: (Score:2)
They're produced outside the US and the technology to produce processors isn't exactly some US trade secret the rest of the world doesn't have.
But you keep up that baseless paranoia.
Re: (Score:3, Funny)
Precisely. The Democrats would never tinker with computing hardware or software (like trying to force everyone to use the same, weak, encryption algorithm AND turn over their keys to the government) like the Republicans would.
Coprocessor. (Score:2)
Actually what I had in mind when I mentioned it on the previous story is that AMD could make the SIMD part of the CPU. That way you could use whatever video card you wanted and have the advantages SIMD brought.
Hope it's not like the last transcoding software.. (Score:4, Informative)
Last time I looked at the Catalyst/Avivo hardware transcoding software it was somwhat less usable than I hoped. The thing that killed it for me was the lack of batching or cl options. It actually turned out to be less time consuming for me to use a software transcoder with batching and leave it on overnight and while I was at work than it did to go back over to the pc after every finished run to setup the next file for transcoding on the vid card. The quality of the video that was transcoded in hardware was a bit on the patchy side as well.
Somthing that I would be interested in is integrating support into burning software to speed up the transcoding side of DVD video burning. Unfortunately it doesn't look like it's happening any time soon. I think the problem is that by the time technology has matured enough to make it viable, the increase in CPU speed will have made it redundant.
Re: (Score:2)
I think the deal is, CPU speed is what has matured. These days, we dont get fast by increasing clock speed, we get fast by going massively parralel. Hence the article and the hardware. The GPU is reaching the point where it is a fancy specialized CPU. Kind of like the FPU's back in the day before 486 DX's were king.
No matter what happens though, the "CPU" as we define it currently will never be able to outperform what we now define as the "GPU" no ma
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:Open standard API (Score:4, Informative)
OpenCL will be the standard; it should support real processors, ATI, NVidia, and maybe Cell if someone bothers to write a backend.
Parent
Re: (Score:2, Insightful)
No standard API yet, because the NVIDIA chips only work on integers and the Stream processors actually can do double precision. From a scientific computing standpoint, portability of my codes is almost as simple as a patching process to get the keywords correct (nevermind the memory handling and feedback, that is still pretty different) and that is only because of the floating point. It's a pain in the you know what trying to keep numbers straight when you have to multiply everything by 10000.
Re: (Score:3, Informative)
NVIDIA's Tesla products all support single precision IEEE-754 floating point, and their 10-series supports double precision.
Re:Open standard API (Score:4, Informative)
NVIDIA's Tesla products all support single precision IEEE-754 floating point, and their 10-series supports double precision.
Nvidia is moving to OpenCL compliance, as well.
Parent
The future of Computing is in... (Score:2, Redundant)
Low cost, low power CPUs. Already, 99% of people don't use 99% of the power of their CPUs 99% of the time. Why then, is AMD banking on people wanting massive power on specialized hardware that will require fancy compilers?
I consider myself in the ever-dwindling group of "PC gamers," and even I am looking forward to the death of GPUs in my computer. I'm tired of building expensive and power-sucking desktops that go obsolete in 18 months. Instead of building a 1000 dollar desktop next year, I'm getting a lapt
Re:The future of Computing is in... (Score:5, Insightful)
You do realize this article has ~absolutely nothing to do with gaming, or even normal users, right?
The systems discussed using CUDA or GPGPU will probably spend ~100% of their lives running flat out, doing simulations or such.
Visualize a Beowulf Cluster of these. Really.
Parent
You misunderstand how people use computers (Score:4, Insightful)
So by your logic, those people would be happy with a computer that was 1% as fast as what it is now?
Make no mistake, once you actually hit that 1% of the time you need 100% of your CPU, the more the better. I can think of two horsepower intense things a normal, every day joe now expects his computer to do:
1) Retouching photos
2) Retouching and transcoding video (from camera/video camera -> DVD)
Dont underestimate transcoding video either. More and more people will be using digital video cameras and expect to be able to output to DVD or Bluray.
Parent
AMD Is Out to Lunch (Score:3, Insightful)
And so are Intel and Nvidia. Vector processing is indeed the way to go but GPUs use a specific and highly restricitve form of vector processing called SIMD (single instruction, multiple data). SIMD is great only for data-parallel applications like graphics but chokes to a crawl on general purpose parallel programs. The industry seems to have decided that the best approach to parallel computing is to mix two incompatible parallel programming models (vector SIMD and CPU multithreading) in one heterogeneous processor, the GPGPU. This is a match made in hell and they know it. Programming those suckers is like pulling teeth with a crowbar.
Neither multithreading not SIMD vector processing is the solution to the parallel programing crisis. What is needed is a multicore processor in which all the cores perform pure MIMD vector processing. Given the right dev tools, this sort of homogeneous processing environment would do wonders for productivity. This is something that Tim Sweeny [wikipedia.org] has talked about recently (see Twilight of the GPU [slashdot.org]). Fortunately, there is a way to design and program parallel computers that does not involve the use of threads or SIMD. Read How to Solve the Parallel Programming Crisis [blogspot.com] for more.
In conclusion, I will say that the writing is on the wall. Both the CPU and the GPU are on their death beds but AMD and Intel will be the last to get the news. The good thing is that there are other players in the multicore business who will get the message.
Re: (Score:2)
What is needed is a multicore processor in which all the cores perform pure MIMD vector processing.
You mean like what's in the Playstation 3; an IBM Cell processor?
Re: (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 yo
Re: (Score:3, Insightful)
Wait a minute. Typically the SIMD of GPU commands is for handling vector triples (coordinates or colors) and matrices, which completely translates into supercomputer tasks that are being talked about in TFA: "tasks such as scientific simulations or geographic modelling".
GPUs nowadays have hundreds of parallelized vector/matrix processors and the drivers & hardware take care of scheduling them all through those pipelines for you. Within the targeted fields, I can't see a downside of this sort of develo
Re:AMD Is Out to Lunch (Score:5, Informative)
Theres a lot of tall claims here, but the one that sticks out as most needing some kind of justification is that "The industry seems to have decided that the best approach to parallel computing is to mix two incompatible parallel programming models (vector SIMD and CPU multithreading)". GPU's mix these models fine and I havent seen anyone bitching about the thread schedulers on them or bitching about not being able to use every transistor on a single stream processor at the same time. How you can claim these models are incompatible, when in fact its the only working model we have and it works fine for those using it, is beyond me. You criticize the SIMD model, but the GPU is not SIMD: it is a host of many different SIMD processors, and that in turn makes it MIMD.
Moving on to what you suggest, I fail to see how superscalar out-of-order execution is not MIMD, and we've been doing that shit for years. The decoder pulls in a crap ton of things to do, assigns them to work units, and they get crunched in parallel. Multiple inputs, multiple data sources, smart cpu to try to crunch it all. Intel tried to take is a step further with EPIC explicitly parallel instruction computing and look how that fucking turned out: how many people here know what Itanium even fucking is?
The "how to solve the parallel programming crisis" link is pretty hilarious. Yes, lists of interlocking queues are badass. Unfortunately the naive implementation discussed at the link provide no allowances for cache locality. In all probability the first implementation will involve data corruption and crap performance. Ultimately the post devolves into handwaving bullshit that "the solution I am proposing will require a reinvention of the computer and of software construction methodology". This is laughable. Just because stream processing isnt insanely easy doesnt mean we have to reinvent it just so we arent burdened with dealing with multiple tasks. Even if you do reinvent it, as say XMT has done, you still have to cope with many of the same issues (xmt's utility in my mind is a bridge between vastly-superscalar and less-demanding EPIC).
Good post, I just strongly disagree. The GPU is close to the KISS philosophy: the hardware is dumb as a brick and extremely wide, its up to the programmers to take advantage of it. I find this to be ideal. I've seen lots of muckraking shit saying "this is hard and we'll inevitably build something better/easier" but a lot of people thought the internet was too simple & stupid to work too.
Parent
Consumer GPGPU Will Happen, Just Not On ATI Cards (Score:3)
Consumer products using GPGPU tech will (and indeed are) happening, but it's sure as heck not going to be on ATI's GPUs. The performance is there, but the development tools are a joke. The main runtime (Brook+) is the technological equivalent of giving yourself a root canal every time you program in it, and the rest of the Stream SDK supporting toolset is more or less entirely AWOL. It's rather unfortunate, but compared to NVIDIA's CUDA the whole system is a joke; CUDA is an excellent toolkit that someone clearly put a lot of thought in to in order to meet the needs of developers, while the Stream SDK/Brook+ still feels like it's a research project that nobody optimized for commercial use.
The hardware is there, but no one in their right mind is going to program with AMD's software. Everyone is waiting for OpenCL. Even if it doesn't really take off, it still can't possibly be worse than the Stream SDK.
Re:Consumer GPGPU Will Happen, Just Not On ATI Car (Score:4, Insightful)
Yes yes yes and yes.
However, AMD already said it was backing OpenCL. I'm pissed as fuck I didnt hear anything about OpenCL this press cycle, but they're the only major graphic company to have ever stated they were getting behind OpenCL: I'm holding onto hope.
You're right: no one uses Brook. Trying to market it as any way part of the future is a joke and a mistake: a bad one hopefully brought on by a 2.50$ share price and pathetic marketting sods. On the other hand, I think people using CUDA are daft too; its pre-programmed obsolesence, marrying yourself to proprietary tech that one company no matter how hard they try will never prop up all by themselves.
OpenCL isnt due out until Snow Leopard, which is rumored to be next spring. Theres still a helluva lot of time.
Parent
what for the CPU? (Score:2)
So if I understand this right, they're adding transistors to the graphics card that would normally be added to the CPU. How exactly does that help? It's not really a graphics cards anymore if you're doing general processing on it. Why not just p
Re: (Score:3, Informative)
It is still capable of hight speed rendering, so it can still be used as a GPU.
Arcsoft (Score:3, Funny)
Is this the same arcsoft that gave us .arc back in the 80s?
If so, I'd like to get rarsoft involved. Any idea how long it takes my P233 machine to unrar a .264 video? I mean, like HOURS.
Imagine if I could harness my video card, an S3Virge.... holy bat, crapman, I'd probably cut my derar times by what, a third?
--Toll_Free
Open Source Audio and Video Encoders (Score:3, Insightful)
MP3, OGG, FLAC - get these out the door (especially the first one) and a host of popular GUI and CLI encoders would jump on the bandwagon. If there are huge speed gains and there are no incompatibility issues because the abstraction layer and drivers are *stable* and retain *backwards compatibility* with new releases then more people will see the light and there will be pressure to do the same with video encoders. Before you know it the abstraction layer would become defaco and all GPU makers would follow suit - at that point we (the consumer) would win in having something that works on more than one OS on one particular card from one particular GPU maker and we can get on with some cool innovations.
"deadly and vaporware" acronym (Score:3, Funny)