Stream computing
AMD is making it clear they're not going to cede the burgeoning GPGPU market to NVIDIA's G80, and the company's pre-launch press materials tout the 2900's usefulness in high-performance computing applications. In particular, there's a sort of software component to the new GPU that hasn't gotten much attention in any of the launch coverage, and indeed I hadn't seen news of it anywhere before coming across it in AMD's press materials.
The R600 is an extremely wide VLIW/SIMD design that relies heavily on a special software layer to dynamically manage its large volume of parallel execution resources. This software layer is called the Accelerated Computing Software Stack, and it includes both compile-time and run-time components. The compile-time component is a set of stream extensions for C/C++ and a math library that AMD calls ACML (probably for Accelerated Computing Math Library). These tools allow coders to write stream computing (or "data parallel") code in C and C++for both the R600 and AMD's multicore GPUs.
This code isn't run natively on the AMD/ATI hardware, but instead it's passed to a runtime component called the Compute Abstraction Layer (CAL), which sits between the programmer and both the multicore CPU and the GPU and appears to contain a just-in-time (JIT) compiler that dynamically translates the code for either x86 or CUDA before passing it on to the appropriate piece of hardware.
The GPU's CTM assembler interface is itself covered by another hardware abstraction layer (HAL) that appears to reside within the CAL. Third party developers can write to either the CAL or the HAL, depending on whether they need to talk only to the GPU (via the HAL, as in the case of display drivers and some HPC applications) or to both the CPU and GPU (via the CAL, for generic "stream processing").
The CAL and HAL portions of ACSS are complex yet integral parts of the driver for the R600 family, and I'd bet money that together they're one of the bottlenecks that's holding back the system from achieving its full potential on gaming benchmarks. It appears that on all of the benchmarks run so far, both DX9 and DX10, all of the graphics calls are going to the CAL via the DirectX and OpenGL CAL bindings, where they're dynamically farmed out to the available stream computing resources on the GPU. If the CAL/HAL stack, which is a brand new piece of software that probably has quite a bit of optimization overhead left in it, doesn't do its job optimally, then the graphics code that's running on it won't be able to get peak performance out of the hardware.
People who really want to max out the R600 will write directly to the GPU hardware using CTM, bypassing the ACSS entirely. This is probably behind AMD's recent promise to open source the R600 drivers—they may be hoping that developers will step up and use CTM to write card-specific drivers that are fully optimized, game-console-style, so that all of the R600's potential can be unlocked.
It could also be the case that AMD themselves will write OpenGL and DirectX drivers that run directly on the GPU using CTM.
At any rate, using a runtime component to dynamically divide up a workload among a highly parallel architecture that runs at a lower clockspeed (the R600 approach) sounds a lot harder to me than writing directly to a narrower but faster architecture (the G80 approach). I think that this is why the HD 2000 series hasn't dethroned the G80 at the very top of the graphics heap, but it hasn't even tried. The highest-end card announced today is the $399 ATI Radeon 2900 XT, a part that falls well below NVIDIA's top-of-the-line card in both price and performance. The 2900 XT isn't reaching its peak potential with its current software stack, so throwing more GDDR3 and more clockspeed at it for a boutique $1,000 card wouldn't buy it enough performance to stand up to the high-end G80.
