No, that's simply not true. What has happened is that game programmers (and game companies in general) have realized that about 90% of the code they write takes up roughly 10% of the total CPU/GPU time.
In this 90%, they can be fairly wasteful with their choice of language and how tightly they bound their algorithms. (There are even game companies that write the bulk of this logic in LISP.) In the last 10% of code, performance is critical. This is the code that takes up 90% of the CPU and GPU to execute. This is the code that must be (and still is) carefully hand optimized, tuned, and tuned again.
However, this is all sort of moot because on current generation consoles, memory is at a huge premium. Most console developers will simply not touch STL (for example) with a 30 foot pole. The performance characteristics of the STL are not well known (in the specific sense), and neither are the memory requirements.
Don't kid yourself, it's still not the compiler writers that are making games more optimal during the life of a console. A simple example is GTA3 to GTA3: SA. It's not like the PS3 suddenly grew 3X the memory... And yet GTA3:SA is dramatically more rich in terms of both total content as well as content running at any given time. And although I'm too lazy to look up other examples to dispute your claim that games don't get better over the lifecycle of a console, rest assured there are a very large number.
Anyone care to comment where a card like this Geforce will be REQUIRED?
The newer shader features are only physically possible on newer hardware (ie, older hardware lacks the capabilities to perform the specific operations).
And there are new games that come out every day that would prefer to use newer and newer vertex and pixel shader features. No one requries them yet because people such as yourself refuse to upgrade an no one wants to cut a significant number of people from their market share.
To be fair, if we were charging you guys by the transistor, you'd find our price-per is pretty fair in comparison to other goods you purchase. For example, an Athlon64 3200 has about 105.9 million transistors and retailed for about $250 within a month of release. By comparison, a geForce 6800 has about 220M transistors (sorry, it's a PDF, all I could find), and retails for about $500. Twice the transistors, twice the price.
(Also note the 220M transistors does NOT include the memory subsytem, while the 105.9M transistors does include the L1 and L2 cache.)
Yes, a grand is a lot of money for a video card. Especially for an end user. But there are already games that will take advantage of this. (For example, Doom III's ULTRA setting requires a video card with 512M of ram).
This card is also useful for those who want a card with the memory of a high-end Quadro (workstation graphics card), but don't want to spend $1700-2200.
No, PCI express only helps the bottleneck, it absolutely does not remove it.
Consider the rate at which I can access data from memory on board. The latency involved is in the dozens of cycles.
Going across PCI express, the latency involved is in the hundreds of cycles.
This doesn't sound like a lot, but when you consider that I might be reading from up to 12 textures at the same time, the latency differences add up in a ridiculous hurry. Consider that I might invoke the fragment processor 200 million times in the same frame. If I'm doing 12 texture reads in each of those 200 million invocations, I'm looking at the difference between frames/second and seconds/frame.
What PCI express *is* really good for is (ab)using the GPU as a massively parallel general purpose processor. For more info, check out the developer site on nvidia.com. (For example, really cool effects like cloth simulation and water surface caustics that would otherwise have been prohibitively expensive).
The benefit of PCI express is its full duplex-ness. Now I can simulate data on the GPU *and* get it back in a reasonable timeframe.
Re:Don't pre-judge the controller, folks
on
PlayStation 3 Unveiled
·
· Score: 2, Informative
No, that would be a waste of resources, and would cause ugly tearing on all televisions due to the nature of interlaced TV. Imagine the worst case, where every frame you are alternating a clear to black or white. If you draw at 60 hz, you get this extremely ugly image that is black and white striped. If you limit to 30, you get exactly what you want: solid white followed by solid black.
It's true that newer televisions (read: HD) will update at 60 hz, but games are not taking full advantage of this yet, in the general case.
Typically, blackouts such as the one that struck the northeast US and Canada a while back are caused by a combination of mechanical relays using outdated settings, grossly inadequate and inappropriate responses by the power stations, and devastatingly little information getting to those who need it.
Offtopic to be sure, but the cause of the blackout in the northeast was actually a problem that shows up in lots of redundant systems (as shown in this simple basic program):
10 One grid failed 20 Another grid tried to take on the additional load caused by the failure of the previous grid 30 The demands were too great for the additional grid to take on 40 Additional grid fails 50 GOTO 20
Care has to be taken in redundant systems to ensure that a catastrophic failure in one place does not lead to a cascading failure throughout the entire network.
In this case, it would've been better for the network to realize that a cascade was in progress and it was therefore better to drop power to the offending power stations rather than continue to ask others for help. Had the system passed this information along with the help request, (in programming a simple decrementing counter is sufficient) the power grid could've quickly realized that a cascade was in progress and could've cut its losses.
Re:Don't pre-judge the controller, folks
on
PlayStation 3 Unveiled
·
· Score: 2, Informative
Oh please.
On modern wireless controllers, there is no such thing as wireless lag. Do the math.
And single frame precision? Gee.. Modern console games limit framerates to 30 fps. That means each frame is ~33 miliseconds. You honestly believe that controllers lag for anywhere near 33 ms?
At a recent computer expo (COMDEX), Bill Gates reportedly compared the computer industry with the auto industry and stated "If GM had kept up with technology like the computer industry has, we would all be driving twenty-five dollar cars that got 1000 miles to the gallon.
In response to Mr. Gates' comments, General Motors issued the following press release (by Mr. Welch himself, the GM CEO). If GM had developed technology like Microsoft, we would all be driving cars with the following characteristics:
1. Every time they repainted the lines on the road, you'd have to buy a new car.
2. Occasionally your car would just die on the motorway for no reason, and you'd have to restart it. For some strange reason, you'd just accept this, restart and drive on.
3. Occasionally, executing a manoeuvre would cause your car to stop and fail to restart and you'd have to re-install the engine. For some strange reason, you'd just accept this too.
4. You could only have one person in the car at a time, unless you bought a "Car 95" or a "Car NT". But then you'd have to buy more seats.
5. Amiga would make a car that was powered by the sun, was twice as reliable, five times as fast, twice as easy to drive - but it would only run on five percent of the roads.
6. Macintosh car owners would get expensive Microsoft upgrades to their cars which would make their cars go much slower.
7. The oil, engine, gas and alternator warning lights would be replaced with a single "General Car Fault" warning light.
8. People would get excited about the "new" features in Microsoft cars, forgetting completely that they had been available in other cars for many years.
9. We'd all have to switch to Microsoft gas and all auto fluids but the packaging would be superb.
10. New seats would force everyone to have the same size butt.
11. The airbag system would say "Are you sure?" before going off.
12. If you were involved in a crash, you would have no idea what happened.
13. They wouldn't build their own engines, but form a cartel with their engine suppliers. The latest engine would have 16 cylinders, multi-point fuel injection and 4 turbos, but it would be a side-valve design so you could use Model-T Ford parts on it.
14. There would be an "Engium Pro" with bigger turbos, but it would be slower on most existing roads.
15. Microsoft cars would have a special radio/cassette player which would only be able to listen to Microsoft FM, and play Microsoft Cassettes. Unless of course, you buy the upgrade to use existing stuff.
16. Microsoft would do so well, because even though they don't own any roads, all of the road manufacturers would give away Microsoft cars free, including IBM!
17. If you still ran old versions of car (ie. CarDOS 6.22/CarWIN 3.11), then you would be called old fashioned, but you would be able to drive much faster, and on more roads!
18. If you couldn't afford to buy a new car, then you could just borrow your friends, and then copy it.
19. Whenever you bought a car, you would have to reorganise the ignition for a few days before it worked.
20. You would need to buy an upgrade to run cars on a motorway next to each other.
I agree. When you've gone to four years of post-secondary education, followed by four grueling years of medical school to understand *all* of the risks, side-effects and possible benefits, and then gone on and done clinical work for a minimum of two years and up to twelve years, you should be able to insert whatever materials you wish into your own body presuming no perceived liabilities to others.
In all honesty, what you're proposing is lunacy. Even if you majored in biology in college, the amount of information you "know" about your body is insignifant in comparison to someone who's halfway through their first semester of medical school. My long-time girlfriend is finishing up her second year of medical school. Her and her friends estimated that they covered one college semester's worth of material per class every two weeks.
At any given time, they had 5 classes. So basically it was like a full load of college courses every two weeks.
But hey, you probably know enough about your body and our collective genetic material from your 30 minutes on google to diagnose and treat yourself.
Hmm... Maybe I have been missing something by not watching this show.
Re:FFT's on GPU's?
on
GPU Gems 2
·
· Score: 3, Interesting
There's a shortcut to a sample for this over at NVIDIA's develope r website. I looked into this briefly, and I was pretty impressed with the performance... The GPU always outperforms the CPU, and in most cases the improvement is a factor of 1.5-2.0.
Not as high as I would expect, but I expect this will increase over time.
Re:How inclusive is the book?
on
GPU Gems 2
·
· Score: 1
In general, all GPU-esque books will be applicable to all manufacturers that support the required shader model. All modern cards (current top of the line NVIDIA and ATI) support shader model 2.0. NVIDIA's top of the line also support shader model 3.0.
I believe the next ATI card is supposed to support Shader model 3.0, so you should be okay in the near-term.
Re:Audio processesing using the GPU
on
GPU Gems 2
·
· Score: 1
I'm gonna have to disagree with you about SLI...
SLI actually provides a very significant performance increase over a single GPU solution. In actual applications (HL2, S.T.A.L.K.E.R.), an SLI configuration gains approximatly 90% over a single GPU. This is not a "marginal" win.
Deferred shading isn't really dependent on the version of hardware you are using. It's more a question of whether it provides value.
The entire reason behind doing deferred shading (in games) is that lighting computations per-pixel--especially when you start using HDR--are extraordinarily expensive. Deferring the shading of these fragments until you are sure they will be visible saves the GPU a ton of work.
To briefly explain what deferred shading is (for those who aren't graphics programmers)... Deffered shading is a technique where you lay down the entire scene in two passes. The first pass renders the entire scene but with all color writes disabled. This allows modern cards to draw data at about 2x the normal rate (plus you can generally avoid any shading--except those that do depth replacement--which provides an additional speed increase to this pass). The second pass is then rendered using the full / normal technique. The benefit is that since the depth buffer has already been filled, the staggering amount of graphics hardware devoted to rejecting fragments that are hidden is used to full advantage. This allows for some serious speed increases, especially if the shading of visible surfaces is very complex.
The downside of this technique (and maybe what the parent was trying to get at) is that if your shaders are not particularly complex, than this technique is really not much of a win... In fact it can be slower than standard one-pass solutions in that respect.
Perhaps I misunderstood RMS' position on this. From reading "Free but shackled," (as linked in the parent to my post) I get the impression that he is complaining that pieces of Open Office are written in Java but require other pieces of Java that are not available in the GNU/Java implemntation, rather they are only available in the SUN Java implementation.
He then seems to complain about the fact that having a free piece of software which relies on other non-free software somehow makes the first piece of software not as good a piece of open source software.
My belief (as I tried to state above), is that this view is lunacy. The major value of my code being open sourced in the first place is that someone else can figure out how I did the interesting bits. The fact that I require a non-free library to skip over low-level, uninteresting details is irrelevant to the real value of my code being available for others to look through.
My point is that my decision to make the code freely available in the first place is the value in this situation. "You" shouldn't complain because "I" decided to use a piece of closed-source software as a dependency. If it bothers you so much that I did so, then the source code is available for you to change it. But if you want people to continue to open source their software, you need to cut them some friggin slack.
Is the point of my original post a bit clearer now?
The source code is available for free. You can look at it, peek at it, poke it and prod it with a stick.
And then, since you know how all of the algorithms work, you can go reimplement it in another language if you so choose.
Frankly, if I were developing a piece of OSS (of which I've released a few), I'd be pretty pissed if people chastised me for my choice of language.
The source code is there. If you don't like the language I used, then fork and port it.
But get off your ludicrous soap box about how I should make sure to use "open" everything. I've fulfilled whatever "moral obligation" you perceive by making the source code available.
Anything else is just a temper tantrum on your part.
Now white headphones are becoming as ubiquitous as cell phones.
Amazing, isn't it? And that's despite the fact that there are quite a few better, cheaper mp3 players available. (Better meaning longer battery life + better user interface + more audio formats supported). For example, the Rio Karma or the IRiver anything.
Great. How's that working out for you? Have those nasty and irresponsible rumors about Windows computers being infested with spyware and viruses dried up yet in the face of your awe-inspiring ability to ship patches?
To be fair, if Apple had 90% of the market share, you'd have ridiculuous security problems too. I mean, what's the fun of finding an exploit that can affect 30 users? 30 users isn't even enough for a good DDoS attack.
There's actually a staggering amount of performance to be gained out of doing stuff on the GPU... Anything that can be thought of as a massively parallel application will work pretty well there.
For example, FFTs can be done on the GPU at roughly 1.5-2x the speed of doing them on the CPU. (Of course, doing them on an FPGA will still trounce the GPU performance by--I believe--a factor of ~8.) But given a few more GPU generations, I believe this margin will be decreased signficantly.
There's a demonstration and whitepaper on this over here.
Right now, I do not believe there are any general-purpose software packages available. That being said, the article I referenced is a discussion on exactly that topic.
Which means that right now, you have to do a little bit of leg work yourself in terms of getting the data to and from the GPU (in textures). I can find out if there are any toolkits later today and let you know, though.
Slashdot Mirror
No, that's simply not true. What has happened is that game programmers (and game companies in general) have realized that about 90% of the code they write takes up roughly 10% of the total CPU/GPU time.
In this 90%, they can be fairly wasteful with their choice of language and how tightly they bound their algorithms. (There are even game companies that write the bulk of this logic in LISP.) In the last 10% of code, performance is critical. This is the code that takes up 90% of the CPU and GPU to execute. This is the code that must be (and still is) carefully hand optimized, tuned, and tuned again.
However, this is all sort of moot because on current generation consoles, memory is at a huge premium. Most console developers will simply not touch STL (for example) with a 30 foot pole. The performance characteristics of the STL are not well known (in the specific sense), and neither are the memory requirements.
Don't kid yourself, it's still not the compiler writers that are making games more optimal during the life of a console. A simple example is GTA3 to GTA3: SA. It's not like the PS3 suddenly grew 3X the memory... And yet GTA3:SA is dramatically more rich in terms of both total content as well as content running at any given time. And although I'm too lazy to look up other examples to dispute your claim that games don't get better over the lifecycle of a console, rest assured there are a very large number.
No, not all banks are http://en.wikipedia.org/wiki/FDIC>federally insured.
That's why you should always only go with banks or CUs that claim to be covered by the FDIC.
And there are new games that come out every day that would prefer to use newer and newer vertex and pixel shader features. No one requries them yet because people such as yourself refuse to upgrade an no one wants to cut a significant number of people from their market share.
Here are some examples:
Unreal 3
S.T.A.L.K.E.R.
To be fair, if we were charging you guys by the transistor, you'd find our price-per is pretty fair in comparison to other goods you purchase. For example, an Athlon64 3200 has about 105.9 million transistors and retailed for about $250 within a month of release. By comparison, a geForce 6800 has about 220M transistors (sorry, it's a PDF, all I could find), and retails for about $500. Twice the transistors, twice the price.
(Also note the 220M transistors does NOT include the memory subsytem, while the 105.9M transistors does include the L1 and L2 cache.)
Yes, a grand is a lot of money for a video card. Especially for an end user. But there are already games that will take advantage of this. (For example, Doom III's ULTRA setting requires a video card with 512M of ram).
This card is also useful for those who want a card with the memory of a high-end Quadro (workstation graphics card), but don't want to spend $1700-2200.
No, PCI express only helps the bottleneck, it absolutely does not remove it.
Consider the rate at which I can access data from memory on board. The latency involved is in the dozens of cycles.
Going across PCI express, the latency involved is in the hundreds of cycles.
This doesn't sound like a lot, but when you consider that I might be reading from up to 12 textures at the same time, the latency differences add up in a ridiculous hurry. Consider that I might invoke the fragment processor 200 million times in the same frame. If I'm doing 12 texture reads in each of those 200 million invocations, I'm looking at the difference between frames/second and seconds/frame.
What PCI express *is* really good for is (ab)using the GPU as a massively parallel general purpose processor. For more info, check out the developer site on nvidia.com. (For example, really cool effects like cloth simulation and water surface caustics that would otherwise have been prohibitively expensive).
The benefit of PCI express is its full duplex-ness. Now I can simulate data on the GPU *and* get it back in a reasonable timeframe.
No, that would be a waste of resources, and would cause ugly tearing on all televisions due to the nature of interlaced TV. Imagine the worst case, where every frame you are alternating a clear to black or white. If you draw at 60 hz, you get this extremely ugly image that is black and white striped. If you limit to 30, you get exactly what you want: solid white followed by solid black.
It's true that newer televisions (read: HD) will update at 60 hz, but games are not taking full advantage of this yet, in the general case.
Offtopic to be sure, but the cause of the blackout in the northeast was actually a problem that shows up in lots of redundant systems (as shown in this simple basic program):
10 One grid failed
20 Another grid tried to take on the additional load caused by the failure of the previous grid
30 The demands were too great for the additional grid to take on
40 Additional grid fails
50 GOTO 20
Care has to be taken in redundant systems to ensure that a catastrophic failure in one place does not lead to a cascading failure throughout the entire network.
In this case, it would've been better for the network to realize that a cascade was in progress and it was therefore better to drop power to the offending power stations rather than continue to ask others for help. Had the system passed this information along with the help request, (in programming a simple decrementing counter is sufficient) the power grid could've quickly realized that a cascade was in progress and could've cut its losses.
Oh please.
On modern wireless controllers, there is no such thing as wireless lag. Do the math.
And single frame precision? Gee.. Modern console games limit framerates to 30 fps. That means each frame is ~33 miliseconds. You honestly believe that controllers lag for anywhere near 33 ms?
That's an eternity to an SOL signal.
I guess not everyone has seen this. I thought it was kinda funny.
(From Here
At a recent computer expo (COMDEX), Bill Gates reportedly compared the computer industry with the auto industry and stated "If GM had kept up with technology like the computer industry has, we would all be driving twenty-five dollar cars that got 1000 miles to the gallon.
In response to Mr. Gates' comments, General Motors issued the following press release (by Mr. Welch himself, the GM CEO).
If GM had developed technology like Microsoft, we would all be driving cars with the following characteristics:
1. Every time they repainted the lines on the road, you'd have to buy a new car.
2. Occasionally your car would just die on the motorway for no reason, and you'd have to restart it. For some strange reason, you'd just accept this, restart and drive on.
3. Occasionally, executing a manoeuvre would cause your car to stop and fail to restart and you'd have to re-install the engine. For some strange reason, you'd just accept this too.
4. You could only have one person in the car at a time, unless you bought a "Car 95" or a "Car NT". But then you'd have to buy more seats.
5. Amiga would make a car that was powered by the sun, was twice as reliable, five times as fast, twice as easy to drive - but it would only run on five percent of the roads.
6. Macintosh car owners would get expensive Microsoft upgrades to their cars which would make their cars go much slower.
7. The oil, engine, gas and alternator warning lights would be replaced with a single "General Car Fault" warning light.
8. People would get excited about the "new" features in Microsoft cars, forgetting completely that they had been available in other cars for many years.
9. We'd all have to switch to Microsoft gas and all auto fluids but the packaging would be superb.
10. New seats would force everyone to have the same size butt.
11. The airbag system would say "Are you sure?" before going off.
12. If you were involved in a crash, you would have no idea what happened.
13. They wouldn't build their own engines, but form a cartel with their engine suppliers. The latest engine would have 16 cylinders, multi-point fuel injection and 4 turbos, but it would be a side-valve design so you could use Model-T Ford parts on it.
14. There would be an "Engium Pro" with bigger turbos, but it would be slower on most existing roads.
15. Microsoft cars would have a special radio/cassette player which would only be able to listen to Microsoft FM, and play Microsoft Cassettes. Unless of course, you buy the upgrade to use existing stuff.
16. Microsoft would do so well, because even though they don't own any roads, all of the road manufacturers would give away Microsoft cars free, including IBM!
17. If you still ran old versions of car (ie. CarDOS 6.22/CarWIN 3.11), then you would be called old fashioned, but you would be able to drive much faster, and on more roads!
18. If you couldn't afford to buy a new car, then you could just borrow your friends, and then copy it.
19. Whenever you bought a car, you would have to reorganise the ignition for a few days before it worked.
20. You would need to buy an upgrade to run cars on a motorway next to each other.
Wish I had the mod points to rate the parent +5 funny. :-P
I agree. When you've gone to four years of post-secondary education, followed by four grueling years of medical school to understand *all* of the risks, side-effects and possible benefits, and then gone on and done clinical work for a minimum of two years and up to twelve years, you should be able to insert whatever materials you wish into your own body presuming no perceived liabilities to others.
In all honesty, what you're proposing is lunacy. Even if you majored in biology in college, the amount of information you "know" about your body is insignifant in comparison to someone who's halfway through their first semester of medical school. My long-time girlfriend is finishing up her second year of medical school. Her and her friends estimated that they covered one college semester's worth of material per class every two weeks.
At any given time, they had 5 classes. So basically it was like a full load of college courses every two weeks.
But hey, you probably know enough about your body and our collective genetic material from your 30 minutes on google to diagnose and treat yourself.
I disagree. If there were no anonymity, then the Great Internet Fuckwad Theory wouldn't be true... But it is!
(Anonymity of course being an integral part to the equation).
Make sure to speak in italics to ensure that the message is received.
Oh, wait.
(ok, other than to see the girl's middrifts)
Hmm... Maybe I have been missing something by not watching this show.
There's a shortcut to a sample for this over at NVIDIA's develope r website. I looked into this briefly, and I was pretty impressed with the performance... The GPU always outperforms the CPU, and in most cases the improvement is a factor of 1.5-2.0.
Not as high as I would expect, but I expect this will increase over time.
In general, all GPU-esque books will be applicable to all manufacturers that support the required shader model. All modern cards (current top of the line NVIDIA and ATI) support shader model 2.0. NVIDIA's top of the line also support shader model 3.0.
I believe the next ATI card is supposed to support Shader model 3.0, so you should be okay in the near-term.
I'm gonna have to disagree with you about SLI...
SLI actually provides a very significant performance increase over a single GPU solution. In actual applications (HL2, S.T.A.L.K.E.R.), an SLI configuration gains approximatly 90% over a single GPU. This is not a "marginal" win.
Deferred shading isn't really dependent on the version of hardware you are using. It's more a question of whether it provides value.
The entire reason behind doing deferred shading (in games) is that lighting computations per-pixel--especially when you start using HDR--are extraordinarily expensive. Deferring the shading of these fragments until you are sure they will be visible saves the GPU a ton of work.
To briefly explain what deferred shading is (for those who aren't graphics programmers)... Deffered shading is a technique where you lay down the entire scene in two passes. The first pass renders the entire scene but with all color writes disabled. This allows modern cards to draw data at about 2x the normal rate (plus you can generally avoid any shading--except those that do depth replacement--which provides an additional speed increase to this pass). The second pass is then rendered using the full / normal technique. The benefit is that since the depth buffer has already been filled, the staggering amount of graphics hardware devoted to rejecting fragments that are hidden is used to full advantage. This allows for some serious speed increases, especially if the shading of visible surfaces is very complex.
The downside of this technique (and maybe what the parent was trying to get at) is that if your shaders are not particularly complex, than this technique is really not much of a win... In fact it can be slower than standard one-pass solutions in that respect.
Perhaps I misunderstood RMS' position on this. From reading "Free but shackled," (as linked in the parent to my post) I get the impression that he is complaining that pieces of Open Office are written in Java but require other pieces of Java that are not available in the GNU/Java implemntation, rather they are only available in the SUN Java implementation.
He then seems to complain about the fact that having a free piece of software which relies on other non-free software somehow makes the first piece of software not as good a piece of open source software.
My belief (as I tried to state above), is that this view is lunacy. The major value of my code being open sourced in the first place is that someone else can figure out how I did the interesting bits. The fact that I require a non-free library to skip over low-level, uninteresting details is irrelevant to the real value of my code being available for others to look through.
My point is that my decision to make the code freely available in the first place is the value in this situation. "You" shouldn't complain because "I" decided to use a piece of closed-source software as a dependency. If it bothers you so much that I did so, then the source code is available for you to change it. But if you want people to continue to open source their software, you need to cut them some friggin slack.
Is the point of my original post a bit clearer now?
This is such a ludicrous point of view.
The source code is available for free. You can look at it, peek at it, poke it and prod it with a stick.
And then, since you know how all of the algorithms work, you can go reimplement it in another language if you so choose.
Frankly, if I were developing a piece of OSS (of which I've released a few), I'd be pretty pissed if people chastised me for my choice of language.
The source code is there. If you don't like the language I used, then fork and port it.
But get off your ludicrous soap box about how I should make sure to use "open" everything. I've fulfilled whatever "moral obligation" you perceive by making the source code available.
Anything else is just a temper tantrum on your part.
Now white headphones are becoming as ubiquitous as cell phones.
Amazing, isn't it? And that's despite the fact that there are quite a few better, cheaper mp3 players available. (Better meaning longer battery life + better user interface + more audio formats supported). For example, the Rio Karma or the IRiver anything.
Good to see that 'trendy' is alive and well.
A real server wouldn't be running Mac OS X...
Well at least we agree on one thing.
[rimshot] Thank you folks, I'll be here all week.
Great. How's that working out for you? Have those nasty and irresponsible rumors about Windows computers being infested with spyware and viruses dried up yet in the face of your awe-inspiring ability to ship patches?
To be fair, if Apple had 90% of the market share, you'd have ridiculuous security problems too. I mean, what's the fun of finding an exploit that can affect 30 users? 30 users isn't even enough for a good DDoS attack.
There's actually a staggering amount of performance to be gained out of doing stuff on the GPU... Anything that can be thought of as a massively parallel application will work pretty well there.
For example, FFTs can be done on the GPU at roughly 1.5-2x the speed of doing them on the CPU. (Of course, doing them on an FPGA will still trounce the GPU performance by--I believe--a factor of ~8.) But given a few more GPU generations, I believe this margin will be decreased signficantly.
There's a demonstration and whitepaper on this over here.
Right now, I do not believe there are any general-purpose software packages available. That being said, the article I referenced is a discussion on exactly that topic.
Which means that right now, you have to do a little bit of leg work yourself in terms of getting the data to and from the GPU (in textures). I can find out if there are any toolkits later today and let you know, though.