Originally posted by: BenSkywalker
Someone pulled this back up, so it seems people think there is some validity to it.
First off Shippy's book- MS never saw anything about Cell, they saw the roadmap with an overview. The functional units are VERY different between the two platforms. Saying they share common elements is akin to comparing a Volts powerplant with a Veyron because they both use sparkplugs. Anyone that needs verification simply throw some OoO at each and see what happens. The book is getting a lot of coverage as they are trying to sell it, the chips really aren't that close.
Another angle from that factor- Cell IP was established as a joint venture between IBM, Toshiba and Sony. Sony can do whatever they want for themselves with Cell IP including evolving it and spreading it into more and more devices(which they have started doing) and they can evolve it on their own quite seperate from IBM at their own discretion. They have full control over what they do with the IP. They are not IBM's customers, Intel giving Sony a x86 license for free with no royalties involved is what it would take for Intel to reach financial PARITY with what Sony already has.
The most important factor in this discussion about the details found in this book is that IBM is not, nor have they ever been nVidia. Some people may be surprised to hear that, but it is the honest truth. They are two different companies. Two different sets of people. Really. IBM, even if they did hand MS over something very close to Cell(which they didn't at all, just used some elements from the POWER architecture on both chips) that would have nothing to do with the choice to go with Larrabee in the PS4.
On to Larrabee. People just seem to be brushing aside the general theme of the utterly staggering technical issues with using a Ray Tracer in real time so I guess we will throw down some numbers so people can get an idea of what we are dealing with.
1920x1080= 2,073,600 - Number of Pixels
265,420,800= Amount of texel data needed for base filtering and AF
1,061,683,200= Number of rays needed to be processed with 4xAA with 0 bounces per frame
63,700,992,000= Rays per second to maintain 60Hz
A 100 core Larrabee would need to be running at 637MHZ to handle an empty scene at the settings console devs are going to be looking for. That is with no shaders at all, not even any polygons. You will need a 100 core Larrabee running at 637MHZ to drive in essence a fillrate test. This is assuming Larrabee were absolutely perfect, never missing a potential clock cycle anywhere.
So with these huge amounts of resources needed for trivial rasterization what possible upside is there to ray tracing?
Utilizing a ray trace approach allows you to reduce the amount of time spent processing shader effects by a rather large amount. Due to the nature of the rendering method ray traced approaches will only render what is actually visible, when you are dealing with individual shaders of enormous complexity computing any of them that aren't visible can be a staggering increase in workload and increase your actual render times by orders of magnitude. Ray tracing also handles direct lighting considerably better then rasterization and with significantly reduced workload for superior results. In off line rendering these factors are huge, for obvious reasons and some not so obvious. Because of the precission utilized scenes are built with all data for the scene available at all times. Overdraw, the portions of the scene which is being rendered even though it can not be seen at all, can push over 100 in certain cases. Taking these factors into account, the pros of ray tracing are obvious and from a computational standpoint very significant for off line rendering.
For real time rendering, things change- a lot. I asked previously about Dreamworks using occlusion culling as it is a very, very simple way to reduce huge portions of overdraw workload from the computational intensity involving 3D rendering. They don't use it or anything like it for most of their tasks for reasons of necessity to their given goals. If you could download a patch that would increase Crysis performance by 400% but you may see a seem on a poly edge once every few hours in the game, you probably would- off line rendering is built to make sure you never see that rendering error. Accuracy is FAR more important then speed, Ray Tracing in this environment is a very viable approach.
Real time rendering is an entirely different beast. There are so many different ways that developers reduce overdraw, and ATi and nVidia have both supported additional features in hardware for many years, that it is a rather simple approach and trivial in implementation time. Our general 3D pipeline approach for many years now has been BSP(binary space partitioning) and it lends itself quite nicely to numerous approaches at removing non visible surfaces from final rendering workloads. It does take a bit more on the resource end for scene setup then ray tracing- but that is a very small portion of the rendering workload.
On a realistic level now, seeing overdraw levels higher then 2x being handled by rasterizers in terms of final render workload is rather infrequent. Back to front sorts on scene data(not difficult to implement) eliminate the overwhelming majority of the workload. So for real time in order for Ray Tracing to be equal to rasterization the shader workload on the amount of overdraw it is computed on needs to be greater then the amount of additional workload it requires to handle basic rendering via ray tracing versus rasterization. We are not remotely close to that now. That also ignores actual parity in overall IQ.
While Ray Tracing is superior in direct lighting, and it can be superior for indirect lighting(it is an exponential increase in computational power for each 'bounce' you add) it is horrid at diffuse. This is why a great deal of people moved away from Ray Tracing years ago even in the off line world(Radiosity is VASTLY superior for diffuse, but we are at least decades away from seeing that approach real time at rasterizer speeds, at least decades). There isn't a great way around this using ray tracing currently, it is simply a trade off to be had for rasterization versus ray tracing.
Overall quality being roughly equal, ray tracing is not remotely close to being viable yet, nor does it appear to be. Intel, rather mistakenly, assumed that once nVidia and ATi came closer to the process limitations that they have always been fighting, they would cease to scale performance anywhere near their former rate. They were quite mistaken. If ATi and nV will run into this at some point remains to be seen, but Intel looked at the situation much as you would expect a CPU maker to, additional die space available and potential clock speed for a given build process. What they failed to take into account was ATi and nV keep finding ways to do the same things with less resources, and they haven't stopped this yet. CPUs don't get to cut corners or 'cheat'- GPUs do everything they can do to do exactly that(as long as the end result looks right) and they continue to get better and better at it.
Ray tracing may, at some point, become a better evolutionary path then rasterization, but we aren't even close to that point yet. Inel made a bad call on when they thought we would be at the point where a switch was ideal, if they were right it would have been worth billions to them, and getting in the game a bit early is better for them then being a bit too late, but the viability of their approach isn't on the horizon anytime soon. When we start to see GPU generations only offer performance improvements comparable to new CPU offerings that will be the point where ray traced solutions can start to reel in what GPUs are capable of.
