That statement I disagree with a lot less. I think your attempts to predict where the industry will be in 8 years are pretty wild though.
It's not that I didn't understand what you meant, but that I couldn't possibly agree with a statement that was completely false. You should try and say what you mean. I assure you again that I am not being pedantic.
You also needn't concern yourself with being compared to Terra. This is at worst a mildly interesting discussion.
Okay then, I guess a little clarification is all that I needed. And as for perdicting CPUs for the next 4-8 years, there was a typo in my post. I meant to say "if there is not a huge technological breakthrough", meaning that things continue to improve at the pace they are right now. If Intel meets its goal of 64 cores in 2010, however, then we might not need a GPU at that point. Unless, of course, a better but more resource-intensive way to do graphics is dsicovered (raytracing is one of these, so a raytracing GPU might become a reality someday), new display technologies increase resolution, or larger games demand more polygons to be drawn at once.
you are aware that raytracing graphics are generally more realistic than shader graphics. Also raytracing can do some things that shader graphics cannot, such as multiple refrelections.
Yes, I am aware of that. I am not, however, aware of how your statment has anything at all to do with what we are talking about.
Apparently you didn't try the demo I linked - the quality is pretty dang good, even if the resolution is really low. The framerates are tolerable, the scene is pretty amazing, the curved surfaces are really curved, that kind of thing. And raytracing is pretty dang parallelizable - POV-Ray (a non-realtime raytracer with much, much higher quality!) gets like 99% improvement from one CPU to two. Thus, I think in the days of quad/octal/many-core CPUs, doing realtime raytracing at "modern" resolutions will be entirely practical.
It might be practical someday. Actually, it will be practical someday. But it isn't right now, and won't be for at least a few more years.
Also, raytracing really has nothing to do with my original logic argument, which should have stated:
If a CPU can do physics efficiently, then it can do shader graphics efficiently.
A CPU cannot do shader graphics efficiently.
Therefore, it cannot do physics efficiently.
Premise two is obvious. Premise one is provided by substitution, since we know that shader graphics ~ physics when it comes to required processng type/power.
Adding specific-purpose *PUs to a computer seems counterproductive when you could put in more generalized units. For example, the APU and PPU and GPU could all be implemented as floating-point units, with an integer-based unit or two to control the whole mess. Then if you've got a more strategy-based game (Half-Life 3?) you can dedicate more resources to the AI; with a more action-based game like the one the PPU makers are showing off you can allocate for physics; and Myst Eleven can have uber leet graphics. Thus, the application devs decide what is most important for good gameplay, rather than (indirectly) you by what hardware you buy. With a common high-speed bus (like HyperTransport) on your system, you could plug in an upgrade module that makes every game faster, rather than just ones that use the [ACGP]PU.
That's a good idea. Too bad we don't have it right now. Until we do, I agree with the poster below you in that a PPU can at least work as a temporary solution while we wait for 16-core processors.
EXACTLY what i was thinking. Before the world of 3D accelerators, all gfx computations were done on the cpu. But the OP completely ignored this fact since it is detremental to his/her argument. Also the demo scene is awash with amazing looking gfx and physics demos which use ONLY the cpu. These demos sometimes also use most of the effects we see on gfx cards, such as texture filtering, bump/normal mapping, realistic water, Anti-aliasing etc. There are also numerous demos which use raytracing engines to provide hyper realistic reflections/refractions/caustics and true spherical geometry (i.e real curves and spheres NOT made from polygons). Again entirely done on the CPU. But the single biggest killer of the OPs point is a little game from 2000, called OUTCAST which was rendered ENTIRELY ON THE CPU. This game had a voxel generated landscape, with high polygon characters (for the time), and effects such as triliniear filtering, bump mapping, anti-aliasing and depth of field.
Also if the CPU cannot do physics calculations then how the hell did the Havoc/Novodex API's run? Exactly. They are software physics engines calculated with the CPU. PhysX is based on the novodex engine.
While its true that the CPU cannot match the PPU for the shear number of physics calculations per second. Saying a CPU cannot do it at all is just plain retarded.
Please read revised argument above.
There is nothing wrong with people asking for physics calculations to be done on the extra core of a cpu because hardly any games out there actually take advantage of the extra processing power of dual core setups. So the extra core is sitting there idle when it COULD be put to use doing extra physics calculations. Nothing wrong with wanting that. Not to mention that all dual core cpu's are 64bit. So they will be even faster on a 64bit OS with a properly written software physics API, closing the gap with the PPU again.
No, there's nothing wrong with it. But is it really worth the trouble when we have technology to do 30 times better? If you have 30,000 objects do those extra 1,300 really matter that much?
It's like the current situation with fuel-efficient cars. Hybrid cars give you an extra 10-20 MPG. That's probably enough to extend oil reserves for another 5-10 years. But is it really worth it when we have the technology (now = coal > ethanol, 2012 = nuclear > hydrogen) to virtually eliminate oil usage?
One problem I dont like about PPU's that nobody has mentioned, and dooms them in my eyes, is that apparantly they introduce another latency loop. That is why you typically LOSE frames with a PPU, even if it's just a few after heavy optimization by Ageia, over not using one at all (even if you might get better physics with it on, you still get a slightly SLOWER framerate).
Because the CPU has to send data to the PPU (over a slow external bus, at least compared to the internal speeds of chips) and then wait to get it back. There's just no way around this additional game instruction loop that slows you down.
That is why I prefer physics on a CPU. You dont have that latency because it's internal. I'd rather have less physics than latency.
AGEIA has pretty much solved that problem with updated drivers. Also, some of the latency is caused by extra load on the GPU - something that will occur with CPU physics as well.
As well I harken to Carmack's complaint: It isn't clear that large amounts of physics make a game better, in fact, they make a game easy to "break" (tons of boulders that can realistically roll anywhere sounds great..until you get randomly accidentally stuck behind them). Carmack has been correct so far in predicting a lot of the problems a PPU would have, such as making games run slower.
You're just being ignorant. You don't want to pay for a PPU, so you are trying to convince yourself that it would make the game worse anyway. Realistic physics = realistic game = better game. Which would you prefer? That a rolling boulder crushes and kills you? Or that you pass right through the rolling boulder as if it wasn't there?
Physics are "politically correct", like AI, but they are vastly overblown. The physics in half life 2 certainly aren't very impressive in practice, despite claims to the contrary. They were "meh" after 5 minutes. They're ok. They didn't make the game.
Thanks for supporting my argument. You just denounced physics that were rendered by a CPU.
I apologize if my earlier post implied that EE's are less intelligent than CS folk. I dont think either is smarter at all. I was just saying that generally we hardware enthusiasts are relatively ignorant about the programming that makes all the hardware go. Just as people who focus much more on software are relatively ignorant to how that software is being implemented at a hardware level. Thus arguing for one architecture over another without considering things on both a hardware and software level is flawed.
But that's the way it has always been and always will be in information technology. When we need faster performance, the hardware gets upgraded, then the software is developed to utillize that hardware. Developers usually don't try to improve the efficiency of their code since the hardware provides more than enough headroom anyway.
ANNOYING AS HELL
Your lack of meaningful comments tells me that you didn't read the post. How can it be annoying if you didn't read it?