je_saist

*a low hiss his heard from in front of the mirror*

...puppeh...

oh... he will pay for this. the puppeh... will... pay.

the problem is Intel not having a clue?

Okay. It's well known that I'm not exactly numero-uno on Intel's favorites list. There's a reason I refer to their Graphics Accelerators as ... Graphics Accelerators. Intel, outside of Larrabee, doesn't actually make a Graphics Processing Unit. In all fairness, Larrabee wasn't a graphics processing unit either, just a Graphics Accelerator on Steroids... but with steroids like that you didn't need a GPU.

I'm not entirely sure what the issue is. My personal opinion, and it's based on what little information I could wring out of Television, GPU, and Tex, is that the old CoH graphics engine was making calls to several proprietary OpenGL extensions. The Ultra-Mode engine update brought a semi-re-write / clearing out of the older proprietary extensions, instead using a rendering path based on the Khronos reference specifications.

Just because a call is in the reference specification does not mean that it is in the graphics driver, or that it is implemented correctly in the graphics driver.

As I understand the situation at hand, Paragon Studios has a choice on support for these older chips. They can re-break the engine(s), and inject the proprietary extension calls back into graphics layer, and thus return the engine to it's old state of nobody knows that section of code actually does, so we have to have this section of code here to work around it and contain it's memory leak, but we need to have an extra section of code here to determine whether or not we actually need that black-box... and I hope I get the point across.

The other option is to hope the driver vendor steps up and fixes support for reference API calls. Now, Intel's gotten better at making sure their OpenGL drivers are reference specced. For many users though, they don't have the option of upgrading the drivers as newer Intel drivers won't recognize their hardware.

The big question on my mind is whether or not City of Heroes alone is enough to make Intel do what AMD did and work their own mobility program, releasing a basic reference driver that should install on the most common variants of hardware, at the possible expense of some advanced mobile features. Given that Intel is not exactly a partner now with Paragon Studios, I somewhat doubt they'll take this approach.

Not much as the performance and on-screen display of running a PhysX card on single cored Socket 754 and 939 Atlhon64 was pretty much matched by running a duel core 939 Athlon64. Back then City of Heroes didn't default with a renderthread -1 command, and it didn't leverage a multi-processor system by default. The game today does leverage SMP by default, granted with only two threads.

Now, it's been a while since I actually had an AGEIA PhysX card in hand. I sold mine off... a little bit after I had picked up my AM2 A64 6000. In my own testing back then, at least in CoH, the AGEIA card added pretty much nothing. Same was true with a 939 X2 4000. The PhysX add in card did... nothing. My personal opinion is that this lack of performance boost was largely due to CoH's engine architecture, as one of the Ghost Recon's I had on hand with AGEIA PhysX support did enable some extra fluff with the Physics Processor enabled.

Now, that being said, PhysX cards may still hold some future value. That value being found in OpenCL. We know that Nvidia's not about to release an OpenCL driver for the AGEIA PhysX PPU as Nvidia has been systematically trying to stomp the PPU into a grave since well... they bought AGEIA out.

However, the actual PPU itself is a rather simple chip-design: http://www.hexus.net/content/item.php?item=5492&page=2

It Might be possible to reverse engineer an OpenCL driver for the AGEIA PPU. For games that leverage OpenCL for physics, this would allow them to expose existing PPU's as viable physics processors getting around Nvidia's baby-like mine mine mine attitude and behavior.

This scenario probably won't happen for one very good reason: http://www.x.org/docs/AMD/ :: http://intellinuxgraphics.org/

The hardware data to write a driver, be it an OpenGL graphics driver or an OpenCL computational driver, is pretty much available for most AMD GPU's and Intel GPA's that are on the market. Why go through the work of reverse engineering a chip that actually didn't sell that well... when lots more gamers are more likely have an AMD / ATi graphics card on hand or in the Processor, or a Intel Graphics Accelerator on the mainboard or in the processor?

Oh trust me. I'm stockpiling my own collection of pictures.