Project Offset will be Larrabee Exclusive

It's been officially confirmed by one of the developers in the Project Offset Team (Paul Tozour) that Project Offset will be exclusive to a "select Intel-based platform".

From Project Offset's Forum:

"Right now, I can only pass on the official word:

Offset will be exclusive to select Intel-based platforms.

We look forward to being able to discuss more details in the future."

What this means is that Project Offset has been specifically designed to run only on Larrabee - utilizing every bit of the massive VPU to do graphics and physics that are traditionally impossible without heavy tweaking on the DirectX API.

But how is this game important? It's only one game. And more importantly - why is Project Offset a key player in the success of Larrabee?

Project Offset is firstly a game development tool / package with its own engine and secondly a game, much like the Unreal 3 Engine. Ageia employed the same strategy with its Physx and while its card has not been much of a success, the strategy worked - at the time of this post, there are 100 over games supporting Physx, with the majority of them based on Unreal engine. Intel has bought everything they need to own a game engine outright - first, they bought Havok, and early this year (February 2008), they bought Project Offset.

Larrabee was seen as a saviour for Project Offset's developers -- they were constantly wrestling with the DirectX API to get the effects they desire. They have also worked very closely with other renowned developers in the field to try and solve some of the problems they encountered but none came up with any good answers. This simply proves that there are more developers hitting the walls of limitations imposed by the DirectX API than we previously thought. Larrabee frees them of this struggle and gives them the freedom to implement anything they could imagine. While it is easy to see that the whole game industry is behind DirectX at the moment, you are completely restricted to the feature set it gives you. Even with the shaders becoming more powerful, it is nowhere near the prowess, flexbility and maturity of x86. Perhaps you could be arguing that nVidia's CUDA could accomplish the same thing. Maybe. But nVidia hasn't bought / started to develop its own game engine yet. Yes, they have the Unreal 3 Engine which uses Physx but it's bound by DirectX. A quick visit to the CUDA forum can confirm that no one has even started working on a custom graphics engine based on CUDA. So on the one hand, we have a plethora of DirectX games - almost every game engines out there are based on this API. Smaller game studios simply buy games engines to create games. We exclude these from the equation as they will adopt which ever standards the underlying engine relies on. So this leaves us with the major players - those who are creating their own engines and sell them for a profit. They're the ones who're being limited by the DirectX API at the moment. They're the ones hitting the walls of creativity set by nVidia, ATI / AMD and Microsoft. They spend years coming out with techniques that utilize the API to do forefront, eye-popping graphics engines. Imagine if they're thrown a life line. Imagine the day they don't have to trick the API to perform something clever. That's where Larrabee comes in.

Don't be fooled by the statement made by the architect of GTX 280. He said they've considered creating something like Larrabee but found that it's not a viable design. That could be true a few years ago or even now, but by next year, nVidia could be heading down an opposite path but ending up with the same design as Larrabee. GTX 280 contains a fair bit of general purpose cores, which sets it apart from the generations before. Larrabee's design is basically the natural progression of GTX 280.

Come next year, I wouldn't be surprised if nVidia's successor to the GTX 280 is somewhat similar to Larrabee - except perhaps the most obvious: it is not x86.

In any case, Intel's strategy at this point is nothing to scoff at - they've built a solid foundation for Larrabee. If anything, they're ahead of nVidia/CUDA at this stage of the game.

For those who are interested, reading through Project Offset's developer blogs and forums will give you an insight into the life as a graphics engine developer.

Using PHP Script as a Plugin

A discussion in my QuickPHP forum has resulted in this new idea where PHP Script can simply be used to create a plugin. Rather than the conventional DLL plugins, we simply get the host to call into the PHP script and get the results back from it.
Of course, a DLL plugin has its advantages (i.e. compiled and runs faster), but in cases that require you to allow your user to configure part of your software with great flexibility, instead of using INI / XML files, a PHP file is definitely not a bad idea. That would bridge the chasm between a DLL plugin and a simple config file. What's more - you only need to deploy the php DLL file (e.g. php5ts.dll) along your software and that's it! You get PHP's powerful regular expression out of the box!
In the discussion, I suggested that PHP could be used to implement the entire Apache's mod_rewrite module, without the need for an external INI file with an input and output regular expression. Users would simply need to write PHP script to manipulate the client request info and return it back to the server. This also means that QuickPHP's mod_rewrite functionality could be so much more powerful than Apache's. In fact, I think one main PHP file is all I need - the main file, in turn could simply call into other modules to work its magic if it's required. If QuickPHP_ReqMod.php is not found, QuickPHP reverts back to its basic mode. No additional DLLs - no unnecessary memory usage.