So Many Cores, So Little Time

My new work laptop is a ThinkPad W510... a Core i7 Q 720 at 1.6GHz. It has four hyperthreaded cores which /proc/cpuinfo allows me to monitor as eight... meaning my system monitor looks awesome.

Now I'm at the bleeding edge (I guess) of hardware, as now everything requires the latest drivers. I had to manually acquire the firmware for my wireless NIC from Intel directly, then build the Linux wireless drivers from source and install them. Luckily the process was surprisingly easy... it was just that I had to track down and download kernel sources, the GCC build chain, firmware and the wireless driver package without Internet access on the laptop. Still, once that was done the Linux wireless source configure/build/install was quick and easy.

I also had to go directly to NVIDIA's beta driver portal and get the very latest binary drivers for the GPU as well... the console itself was being corrupted by display errors. Again, not hard to fix, just another step.

In the age of everything "just working" on Linux distros I was glad to see that the ancient art of configure/make/make install is still being practiced... in fact it works better than ever.

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.

AMD's Multi-Core Not Just Multiple Cores

Hopefully this will put an end to my incessant postings on this topic. It appears AMD is indeed developing a processor with vector units, and using them in their actual processor pipeline instead of using it just for graphics processing. This means their CPU will be able to crunch straight-line algorithms much easier (like Folding@Home) by virtue of a unit on-die that caters to that type of processing.

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.

GPU - The Next FPU?

What was the difference between a 468/SX and a 486/DX2? The additional floating point processor. Hellz yeah.

In the budding days of personal computers and 486 goodness, CPU's were strictly integer machines. Floating point math was simply too much for the little chicklets that didn't even need active cooling. I recall that back in the olden days of ISA cards and SIMS you could purchase separate FPU's that you could hammer into your brute-force socket... this granted you massive power that your Excel spreadsheets never previously dreamed of.

I recall how up-in-arms everyone was that Quake actually demanded a freakin' FPU. Who'd id think we were, Rockafeller?

Now that graphics cards have become cheap, plentiful and pretty freakin' powerful vector processing has become all the rage. Projects like BrookGPU and GPGPU have made it (relatively) easy to create userspace apps run on a GPU just as it would a CPU. This means your GeForce 7800 could work on certain serialized tasks, crunching numbers while it remained idle between SecondLife sessions.

Of course, GPU's are just good for vector processing, which means only a certain type of algorithms are really suited for it. You don't need to look much farther than critiques of IBM's Cell architecture to see how people feel about a rash of vector processing units versus a CPU that can span and branch effectively.

It was interesting to see that Nvidia and Havok have teamed up to offload physics to the GPU. Bear in mind this doesn't work with an actor's physics since it branches and can't be effectively streamlined or predicted, but does extremely well with cloth and particle physics.

Nvidia could be realizing that Ageia's physics accelerator is a more than vaporware, and is stepping up their offering to get into that product space. However, from the specs it appears that only Ageia's PhysX (*groan*) will be able to handle physics asynchronously. Although, I guess if you run physics calculations like shaders you could send multiple calculations down each pipe on the graphics card itself.

Should be interesting to see how the space pans out. The GPU is quite a hoss nowadays, and needs extremely fast access to memory, so it may not be incorporated as a side-by-side processor or on-die any time soon. But still... one has to wonder if multiple fast vector units are the next big thing to go on a proc.