Where Are the Java Physics APIs?

If I'm going to try and port Deskblocks to Java then I'll need to find a native Java physics API. If my only choices are native libraries then it makes more sense just to stick to Qt 4 - I'd rather keep this entirely in the "compile once run anywhere domain." Managing native libraries with wrappers functions is just a pain in the butt.

I was surprised to see slim pickins for physics API. For 2D physics I just found Phys2D and for 3D physics I found JBullet, a port of the Bullet physics API. Both seem to be great projects, and both seem to be currently active. Indeed, I'll probably give Phys2D a try and see if I can use it. I guess I just expected an ODE port by now.

Java DeskBlocks

Right before I started my latest hacking-for-cash endeavor I was working on DeskBlocks, a physics sandbox rendered directly on the desktop. I was using Qt 4 for development, mostly so I could use ODE and refresh my C++ coding. One problem in development was that things would work perfectly fine in X11 - rounded edges, nice circles bouncing around, render speed was great - then things would work horribly in Windows. Or vice-versa. I could never get things to behave properly cross-platform.

With Java's big update, it's windowing toolkit now allows for translucent and shaped windows on platforms that support it. That means the rendering issues I had with Qt 4 may be solved with Java 6u10.

It makes me start thinking if I should move the project to Java instead. It appears there are Java bindings for ODE... so it just might work.

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.

Double Wires

Had to talk about this one. The same physics fun guy who brought us World of Sand has now given us something just as addictive - Double wires. Ever think you'd be badass as Spiderman? This lil' physics game shows that you, as a webslinger, would just result in an extended hospital stay.

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.