Brian's Brain

Per last Wednesday's post, I wanted to clarify that I don't necessarily see non-graphics applications as the lone route to success for GPU suppliers going forward. Granted, as I've noted on numerous occasions, serious game-players whose frame quality and update rate expectations necessitate high-end discrete graphics processors are a diminutive (and shrinking) slice of the overall PC user pie. Granted, mainstream 3D graphics-leveraging applications that aren't games are few and far between, in spite of many years' worth of market experiments and GPU suppliers' investments. And granted, the Windows Vista 'Aero' UI and its Windows Presentation Foundation, which could have driven the awareness of varying GPU capabilities to popular consciousness, were intentionally neutered so that they could run on low-end Intel integrated graphics core logic chipsets.

But early indications from this week's Microsoft PDC (Professional Developers Conference) confirm my earlier suspicion that the upcoming Windows 7 and DirectX 11 API will more extensively and efficiently leverage the GPU (I'll be at Microsoft's Windows Hardware Developers Conference next week, so stay tuned for more on this topic). Apple has similar plans for upcoming OS 10.6 (aka 'Snow Leopard'). For now, I keep mentally returning to Google Earth (which I most recently mentioned in conjunction with the 2007 SIGGRAPH) as the 'poster child' of a mainstream non-gaming application whose 'user experience' is heavily dependent on available GPU resources (as well as the downstream bandwidth of the user's Internet access 'pipe'). And speaking of Apple, yesterday Google released a version of the program for use on the iPhone and iPod touch, tapping (pun intended) into the platforms' formidable graphics resources. My brief experimentation to date on my 2^nd-generation iPod touch renders (pun ditto) me quite impressed with what Google's pulled off; among other things, as Adam Engst points out, the program's developers shrunk the 110 MByte PC application footprint down to less than 9 MBytes.

Returning the focus to PC graphics for the remainder of this post, I'm enjoying watching the architecture implementation difference of opinion between AMD/ATI and Nvidia over the past few product family generations. Back in late 2007 when AMD was briefing me on the soon-to-be-introduced Radeon HD 3870, I remember that I tossed out the following question at the end of the telecon:

Have you considered putting two GPUs on a single add-in card?

In retrospect, I'm not sure why I blurted out that particular query...perhaps I was remembering ATI's first attempt at such a product (2000's Rage Fury MAXX, derived from two Rage 128 Pro chips). Or perhaps I was mentally extrapolating the then-existent CrossFire approach to linking multiple single-GPU graphics cards. Regardless, I knew I'd hit pay dirt when my query was met by a lengthy pregnant pause on the other end of the line, followed by a chuckle and a succinct 'great question...stay tuned for more on that' response from the AMD spokesperson.

'Stay tuned' came a few months later, in the form of the Radeon HD 3870 HD X2. Numerous reviews of the card reached a near-unanimous conclusion; it paced (and in some cases surpassed) the features and performance of Nvidia's single-GPU GeForce 8800 series, often also at a lower price tag than the competitor's alternative. AMD's extended the dual-GPU winning streak with mid-August's Radeon HD 4870 X2, which favorably compares to Nvidia's GeForce 9800 series and more modern GeForce GTX 280 and 260.

Here's why I find the dual-vs-single GPU-per-board dogma difference between AMD and Nvidia so interesting; AMD has gotten to each new foundry process node more quickly than its primary competitor the past few years, which translates to inherent improvements in die size, performance, and power consumption. Right now, for example, the entire Radeon HD 4000 series is fabricated on a 55 nm lithography, whereas the GeForce GTX 280 and 260 still rely on 65 nm.

Next, couple the process differential with the fact that Nvidia's leading-edge chips have substantially higher per-die transistor counts than does a single Radeon HD 4870. And finally, consider the exponential yield loss impact of each linear increment in die size. Now tell me which is a lower-cost path to a given performance threshold, assuming that the application is amenable to parallel processing; two 55 nm-fabricated ICs operating in tandem, or one monster 65 nm chip?

This situation reminds me of two x86 circumstance parallels, ironically both involving AMD and Intel, but with different conclusions in each case. I'm reminded first of AMD's largely successful competition against Intel's Itanium CPU, by instead advocating multiple Opteron processors. Conversely, I recall how Intel waited until the second turn of its 45 nm process node to migrate to a greater-than-two-core single-die CPU, relying until then on a dual-die (each die containing a dual-core processor) single-package approach, whereas AMD attempted (and largely failed) to make the leap to four cores at 65 nm with Barcelona and Phenom.