Hardware-Accelerated Browsers: Not Likely To Be Graphics Vendors' Saviors
As Rick Nelson noted in his recent week-ending blog post, concisely summarizing several previous news writeups published by EDN, last week was (stimulated by Nvidia’s commensurate GPU Technology Conference) filled with technically interesting news related to graphics processor acceleration of functions that might otherwise run completely in software on a host CPU. Those of you who remember my admittedly somewhat scathing critique of Nvidia from a month-plus back might, after reading Rick’s words, have been confused by my summary of the reasons for the company’s current problems:
Integrated graphics cores within core logic chipsets are increasingly able to adequately tackle the majority of computer users’ needs, in part because silicon capabilities have evolved faster than traditional 3-D software has evolved to harness those capabilities, in part because pixel- and polygon-performance-demanding apps haven’t expanded beyond the gaming niche, and in part because Nvidia’s been largely unsuccessful in ‘mainstreaming’ its general-purpose GPU aspirations with the possible exception of video encoding (and other processing) acceleration apps.
Wasn’t Rick, in fact, showcasing ‘general-purpose GPU’ opportunities? Indeed he was, but the key word present in my analysis and missing from Nvidia and its partners’ announcements was mainstream. With all due respect to my engineering readership, neither a Matlab accelerator from MathWorks or a simulation time reduction engine from Ansys, nor even the conceptually similar simulation acceleration demonstration from Agilent earlier this year, will generate sufficient mass market GPGPU (general-purpose graphics processor) application demand to ensure Nvidia’s continued fiscal health. Neither was anything else showcased at the show, judging from my perusal of others’ writeups (here’s more coverage…full disclosure: I wasn’t personally at the conference), capable of kick-starting the discrete GPU business back to life to any substantive degree.
Supercomputer-class processing may cultivate sensationalist headlines, and it may be highly profitable on a per-GPU unit basis, but it doesn’t ship many units. And given how slowly the supercomputer market evolves away from traditional hardware and software approaches, those few units won’t begin shipping very quickly, either. The only broadly applicable GPGPU capability that’s here-and-now and that I’ve yet come across in my many years of following this application space involves acceleration of video encoding and other image processing functions. As I pointed out in a recent cover story, I’m of the mindset that video processing in particular is applicable to a narrower set of consumers than the graphics vendors might wish would be the case. And in this and other GPGPU regards, the discrete GPU vendors are competing not only against dedicated graphics cores integrated within chipsets and CPUs, but also against the ever-increasing capabilities of the CPUs themselves.
Consider my recent briefings with AMD and Intel at the latter’s Developer Forum. I haven’t yet told you much about the latter’s upcoming Sandy Bridge microarchitecture-based CPU series, in part because NDA requirements preclude me from doing so at the present time. However, the demonstrations I auditioned included not only 3-D game showcases (intended to get across the message that the on-CPU graphics core was capable of hanging with modern mainstream discrete graphics boards) but also image processing applications which revealed a dramatic speed-up versus today’s Nehalem microarchitecture-based CPUs. Interestingly, Sandy Bridge doesn’t leverage graphics shaders to implement these functions, instead embedding a dedicated media processing engine.
AMD, similarly, vigorously talked up video processing in demonstrating the APU (accelerated processing unit, i.e. GPGPU) embedded within its first Bobcat-based Fusion CPU. The other GPGPU demo AMD had for me, not surprisingly, was a Platform Preview version of Microsoft’s Internet Explorer 9 web browser (whose planned existence was first publicly revealed around 10 months ago). IE9 (along with another key Microsoft application, the Silverlight web application framework) leverages the graphics processor to hardware-accelerate functions that previously executed in software on the GPU. Google’s Chrome and Mozilla’s Firefox are publicly in the process of implementing conceptually similar capabilities…I haven’t yet heard anything on Opera nor on Apple’s Safari browser, although given the latter’s enthusiastic OpenCL embrace, I’d wager that GPU leverage is a matter of when, not if. Although IE9 seems to be the furthest along in development versus its peers, it doesn’t expand its reach to encompass 3D-in-browser (i.e. WebGL) acceleration.
More generally, AMD tried to claim that its CPU’s integrated graphics ran IE9 dramatically faster than Intel’s latest graphics-in-core logic could, but I was skeptical upon initial viewing and, as I later wrote, the discrepancy I saw ended up being the result of out-of-date Intel graphics drivers versus any fundamental Intel hardware limitation. This outcome isn’t surprising to me, in spite of graphics vendor hype to the contrary, and it reflects my comment above that “’silicon capabilities have evolved faster than software has evolved to harness those capabilities.” No software developer in his or her right mind is going to craft an application that runs only on leading-edge hardware that constitutes only a narrow sliver of the computer user base at the time, unless the resultant revenue and profit projections justify the project. I’m reminded of the graphics vendors’ past promotions of the Windows Vista UI ‘eye candy’ as justification for both GPU upgrades of existing systems and high-end graphics selections for new system purchases…when as it turned out, a notable percentage of the complete ‘eye candy’ experience ran just fine on entry-level graphics hardware, and the software gracefully and automatically tailored its settings to match the CPU and GPU capabilities available to it.
Admittedly, part of the reason for the underwhelming reality behind the longstanding GPGPU promotion has to do with API uncertainty. Until recently, the most credible means of accessing GPU hardware for beyond-graphics acceleration was through vendor-proprietary ‘hooks’; CUDA for Nvidia, and AMD’s Stream. Just as few software developers will craft an application that targets only a leading-edge hardware platform niche, few developers will risk develop software that’s only applicable to one graphics vendors’ products. Fortunately, industry-standard OpenCL is gaining prominence, as is the DirectCompute API in Microsoft’s latest DirectX 11 suite.
There are plenty of other GPGPU opportunities besides video-processing and browser-function acceleration, mind you. For example, one of the other demos Intel showed me at IDF involved facial recognition matching of a subject in a given photo to that same visage in other already-archive images, a perfect application for the wide parallel multi-core DSP crunching capabilities of modern GPUs. Harnessing GPU hardware to assist in speedily system-scanning for viruses and other malware is another potential ‘killer app’ (ironically and more nefariously, GPUs have also shown themselves to be adept at acting as malware targets and potentially user-unsanctioned password recovery ‘engines’, as well as quickly cracking wireless LANs’, GSM cellular’s and other applications’ encryption keys). There are also opportunities with massively distributed processing systems such as Folding@Home. And although I’m not personally a big fan of physics processing on GPUs (nor are some of my peers), it remains a long-term possibility even if its short-term prospects are dubious. Still, the graphics vendors are going to have to start showing GPGPU ’steak’, not just more of the same ’sizzle’, or risk sooner-or-later irrelevance.