NVIDIA's Linux Fate

Just like everyone else on the globe, I heard/read/watched Linus telling NVIDIA, in absolutely no uncertain terms, that they were bad Linux citizens. At first I thought Linus was telling them that they were "number one!!!" but sadly this turned out not to be the case.

The topic came up from someone in the audience who was trying to get NVIDIA's Optimus tech working on a Linux notebook. This is a bit of a different bird than NVIDIA's usual discrete GPU market, as this requires co-operation between onboard (or on-die) video adapters, the discrete graphics card and the northbridge to turn off the accelerated GPU when not in use. To my knowledge only Windows 7 drivers can accomplish this, and Linux doesn't quite understand the management architecture to leverage it. The open-source Bumblebee Project appears to be doing a great job of trying to set ACPI & BIOS flags to accomplish the same thing, but the entire effort could be greatly accelerated with NVIDIA's help. While NVIDIA has more-or-less sanctioned the Bumblebee project by releasing installers that work with Bumblebee, they haven't contributed to it directly.

Linux called NVIDIA's lack of Linux support the "exception rather than the rule," and extended that comment to mention that "NVIDIA been one of the worst trouble spots" in kernel support and the "single worst company we've ever dealt with." This of course was punctuated with the infamous line: "so NVIDIA, f**k you." He didn't actually speak in astrisks, I'm just experimenting with censorship.

Linus, of course, just "like[s] being outrageous at times... [because] people who get offended should be offended." It was probably meant to be a thrown gauntlet more than a haymaker, and I can definitely see why. I've been a big advocate of NVIDIA, even with their proprietary stance on GPU drivers and increasingly as the nouveau driver has increased its feature parity. These kind of ACPI hacks however are not the same as keeping tight control over intellectual property tied to their GPU hardware. Given how good drivers are the true value behind discrete graphics cards, I understand not wanting to open-source them to competitors ("Hey AMD! Here's how we did tessalation!"). Controlling power management within the OS kernel is a different matter however - and everyone benefits (including NVIDIA) with broader support. What's the barrier to entry of AMD creating something similar that idled the discrete GPU when no accelerated calls were being made? For that matter, what's to stop Microsoft from coming up with a vendor-agnostic solution that does the same thing? It seems not unlike what OS X Lion is doing right now...

NVIDIA's response basically focused on the fact that they permit Bumblebee to co-exist, their proprietary GPU drivers still offer fantastic performance and support (which they do) and they are one of the largest contributors to Linux on ARM. In short: they don't feel like Optimus Linux support is worth doing right now. However there are signs that even this isn't working well - NVIDIA just lost a quarter million dollar GPU deal due to poor MIPS support.

NVIDIA, this is a great time to step up and contribute the solution to the Linux kernel. Show your competitive edge continues to be broad platform support, otherwise people may meander elsewhere.

Post script: If you're interested in getting a sense of how crazy GPU/graphics driver development is on Linux, read Jasper St. Pierre's post on The Linux Graphics Stack. Terrific outline on the steps a polygon goes through to get to your monitor.

Intel Killing the VPU?

I had faintly heard grumblings of Intel loathing Nvidia, but I didn't really put 2 and 2 together until listening to Gordon Mah Ung on this week's No BS Podcast.

Good ole' Gordo spelled out why Nvidia ultimately acquired AGEIA - because Intel deep-sixed Havok's use of GPU's that had been in development for several years. While Havok was an independent company they worked with both ATI and Nvidia to support GPU processing of their physics API. Once Intel bought them the interoperability was tossed in the trash. I'm sure this was a pretty big dig at the GPU makers.

So Nvidia purchases the #2 player in the market to ensure this doesn't happen again. Let's see who enjoys the #1 spot in shipping titles during Christmas of '08.

Make a VPU Socket Already! Get It Over With!

My lands. If the floating point unit took this long to become mainstream I'd be using a Core 2 Duo with a math co-processor still.

Not to go all Halfhill or anything, but it has appeared that a vector co-processor or VPU's on-die were an immediate need for at least the past two or three years. Both Nvidia and AMD are bringing GPU's closer to the CPU, and it at once appeared that AMD's multi-core platform has included VPU/FPU/integer math/memory controller/CISC/RISC/misc./bacon&swiss together to take many types of tasks and integrate them under one die's roof.

And now that Nvidia has wisely acquired AGEIA and their PhysX platform it seems a general purpose vector processing platform is getting closer. A standalone PhysX never took off on the consumer marketplace, and purchasing another Radeon or GeForce just for physics processing (as both AMD and Nvidia were touting at electronics expo's) never caught on either. But a generalized, open-platform physics API that takes advantage of unused GPU cycles would definitely catch on. Spin your GPU fan faster and get real-time smoke effects... sign me up.

Nvidia has been extremely forward-thinking with their Linux drivers, and I hope they continue to be trend setters with the PhysX API. The PhysX engine and SDK was made freely available for Windows and Linux systems prior to Nvidia's acquisition, but hardware acceleration currently only works within Windows. Since Nvidia is porting PhysX to their own CUDA programming interface, it seems entirely probable that the Linux API would plugin to Nvidia's binary-only driver. And why not release the PhysX API under GPL? They could port to CUDA (whose specification is already open, available and widely used) then reduce their future development efforts by letting a wide swath of interested engineers maintain the codebase as needed.

Widely available drivers, development kits and APIs will help drive hardware sales in an era where Vista w/ DirectX 10 adoption isn't exactly stellar. I won't invest in being able to run Crysis in DX10 under native resolution for a 22" LCD, but I will invest to get more particle effects or more dynamic geoms. At that point you're adding to the whole gameplay proposition instead of polishing up aesthetics, with continuously diminishing results.

Exactly How Many PCI-E Slots Does One Need?

I'm pretty much hammering this subject into the ground, but then again so are component makers.

Recently we saw Ageia's physics accelerator come to market as an add-on expansion card, astride your existing video accelerator and sound card. Next we saw the Killer NIC reviewed by IGN, a "network interface accelerator" which promises to offload the assembly of TCP and UDP packets to take load off the CPU. It's actually an embedded Linux instance, assembling your TCP stack instead of Windows. Windows just sends the Killer NIC raw datagrams, then the Killer NIC does all the work to disassemble the datagrams into bare signals over the wire.

Now there's supposedly an accelerator in the works, the Intia Processor, dedicated to nonplayer character AI acceleration. It would offload AI processing from the CPU and instead have a dedicated API for pathfinding, terrain adaptation and line-of-site detection.

So let's count the possible gaming accelerators here:

Sound (i.e. Sound Blaser X-Fi)

Video (i.e. NVIDIA GeForce)

Video (additional NVIDIA GeForce for SLI)

Physics (Ageia PhysX)

Networking (Killer NIC)

AI (Intia Processor)

So that eats at least six slots, but if you have double-wide video cards, more like eight. Oh yeah, and you'll spend nearly $1,500 on just the above hardware accelerators alone.

This is a cycle that repeats itself in the computer world, tho. Popular software algorithms become API's. API's become baked into hardware. The hardware becomes to inflexible and becomes firmware. The firmware isn't flexible so it goes into software. And on and on we go.

But this hasn't necessarily happened for OpenGL or graphics acceleration. Why? Because there you're not baking an API into silicon, you're using a different type of processing unit altogether to solve a different genre of problems. Multiple vector processing pipelines can streamline linear algorithms much more effectively that complex instruction set CPU's. The same analogy can be made for floating point units when they were introduced along side elder CPU's that could only handle integer math.

Not only that, we're looking at chip makers shy away from raw clock speeds and instead looking at cramming as many CPU cores as possible on a single die. This allows for every CPU stamped out of the factory to be a multiprocessor machine. Once API's become more threadsafe, this crazy specialized hardware will instead just be an API call sent to one of the four idle CPU's on someone's desktop.

I think the eventual result of this crazy hardwareization (feel free to use that one) is that people are going to want to fit their algorithms into one of three processing units: the CPU pool (by "pool" I mean a pool of processors upon which to dump your asymmetric threads), the VPU (vector processing unit) or the FPU. The CPU & FPU have already become as one but as any C/C++ programmer can attest to, the decision to use integer based math as opposed to floating point math still rests heavily on the programmer's mind.

Given people are already compiling & running applications on a GPU that have nothing at all to do with graphics, it's only a matter of time before chipset manufacturers come up with a way to capitalize on the new general purpose processing unit.