ATI Havok GPU physics apparently not as dead as we thought

[dreddfunk]

Whatever solution is implemented, there would be serious drawbacks for consumers (us) if it were not: a) hardware agnostic, and, b) vendor agnostic. By (b), I mean a solution that is not directly controlled by any of the principal hardware vendors. I.e., the solution has to be able to be run on all hardware, and it should not be controlled by any of the hardware vendors.

The second point seems to be what is really at issue here: control of the physics implementation standard by any particular vendor would work inevitably to undermine competition. Why wouldn't the in-control vendor optimize the implementation to run best on their own hardware, at the expense of other vendors? This holds for either nvidia, AMD, Intel.

Advanced 3d games and GPU production exploded when two vendor- and hardware-agnostic standards (DirectX and OpenGL) allowed content providers (game developers) to become fully independent from hardware providers (GPU companies).

The same thing has to happen for physics to really take off. As consumers, we should be clamoring that either PhysX or Havok be set free from their hardware-vendor parents.

I agree with those that criticize AMD for not having any viable solution and for the marketing double-speak they use to hide their shortcomings. I also agree with those that criticize NVIDIA for trying to foist an inherently anti-competitive physics model (a vendor controlled implementation) on the gaming industry.

If you really care about physics in the long term, you have to decry both practices, because both practices retard physics development.

 

[Munky]

First of all, stop rambling on about GPU-based physics as hardware and CPU-based physics as software. They are all software-based solutions, except that the software runs on different hardware.

Cutting the Nvidia marketing BS aside, how do they plan on supporting PhysX via OpenCL and DX11 when at present it relies on CUDA? They will either have to abandon CUDA and use one of the other cross-platform standards, or have a CUDA layer on top of the other standards to interface with PhysX. Neither of those options sounds more appealing that having a vendor-independent physics API which isn't owned by NV.

 

[konakona]

Originally posted by: Wreckage

Originally posted by: BFG10K
I agree with Ben; the ideal solution is for Microsoft to define a physics standard which then forces anyone that wants to be a major player to support it. DirectX (and OpenGL to a lesser extent) has been one of the best things to happen to PC gaming.

A Havok/PhysX war won?t be good for consumers.

You basically support a Microsoft monopoly then.

Competition is good, it will result in a better product. Physx could work with OpenGL, OpenCL and DirectX. While a DirectX solution would only with DirectX and only on MS products. PhysX works with every game console and can work on many operating systems. Havok could do the same as well.

competition is good when they compete under one standard, not mutually exclusive standards that cause nothing but trouble to consumers. I am sure americans scoff at the globally accepted mks system due to their strong belief in competition. competition is good huh? :roll:

 

[Munky]

Also, what tangible PhysX effects have you seen in games other than extra crap on the screen? For example, if you blow up a building, does the actual geometry deform in a way that the player can interact with it?

 

[aka1nas]

Originally posted by: instantcoffee

Currently, Havok is the most widely adopted middleware for physics. Featuring over 200 AAA game titles and then some lower budget ones. Over 100 developers have signed up with Havok. Intel is the largest GPU maker (Nvidia is largest for the discreet GPU market), while ATI is the third largest. Intel is a heavy player and owns Havok. Microsoft, another big player, have a unique deal with Havok:

Not a single one of the previous software-based Havok titles are relevant as they won't be redone to use a hardware-accelerated version of Havok (especially if this new version is based off of Havok FX). Of the major licensed engines, only Source is still using Havok, with UE3 and Gamebryo now supporting PhysX at the engine level.

 

[chizow]

Originally posted by: munky
First of all, stop rambling on about GPU-based physics as hardware and CPU-based physics as software. They are all software-based solutions, except that the software runs on different hardware.

Sure, I guess we can ignore firmly established and defined terminologies for whatever you think is appropriate. Kinda like how hardware vs. software with relation to graphics, audio, networking, RAID, etc. all make the clear distinction of hardware meaning discrete hardware ASICs compared to software meaning the CPU. Or we can just stick to those established definitions and terminologies and refer to gpu vs. cpu as hardware vs. software physics for simplicity's sake.

Cutting the Nvidia marketing BS aside, how do they plan on supporting PhysX via OpenCL and DX11 when at present it relies on CUDA? They will either have to abandon CUDA and use one of the other cross-platform standards, or have a CUDA layer on top of the other standards to interface with PhysX. Neither of those options sounds more appealing that having a vendor-independent physics API which isn't owned by NV.

Being the software guru you are, you should have no trouble cutting through the Nvidia marketing BS. What makes you think DX10-compliant shaders are in any way reliant or strictly tied to CUDA? What do you think PhysX was using to interface Ageia's hardware before it was ported to CUDA? What API is used to interface those very same shaders in current games? What makes you think Nvidia shaders or PhysX won't be compatible with OpenCL or DX11? It should be obvious, software is easily modified to extract and expose the benefits of hardware, so as long as the hardware is compatible with whatever API standards being discussed, that's all that really matters. Which brings us back to the fact Nvidia has repeatedly stated CUDA and PhysX will fully support both OpenCL and DX11.

You can Google the NV blurbs about support, but if you want to cut through the marketing feel free to read:

OpenCL vs proprietary standards discussed on AT
DX11 compute shaders discussed on AT

While Derek avoids discussing Physx (probably intentionally, being a hot button topic and all), he clearly states CUDA is compatible with OpenCL and that DX11 is a strict superset of DX10 with the only major difference in hardware requirements being tesselation hardware.

 

[josh6079]

Originally posted by: munky
Also, what tangible PhysX effects have you seen in games other than extra crap on the screen?

Lower frame rates.

That's the nature with increasing game immersion though.

 

[Munky]

Originally posted by: chizow
Being the software guru you are, you should have no trouble cutting through the Nvidia marketing BS. What makes you think DX10-compliant shaders are in any way reliant or strictly tied to CUDA?

Being the software guru that I am, I can tell you that CUDA is nothing more than a software API that provides a C-like interface to the GPU hardware capabilities. PhysX is implemented via CUDA, and neither have anything to do directly with DX10.

What do you think PhysX was using to interface Ageia's hardware before it was ported to CUDA?

They sure as hell didn't use CUDA.

What API is used to interface those very same shaders in current games? What makes you think Nvidia shaders or PhysX won't be compatible with OpenCL or DX11? It should be obvious, software is easily modified to extract and expose the benefits of hardware, so as long as the hardware is compatible with whatever API standards being discussed, that's all that really matters. Which brings us back to the fact Nvidia has repeatedly stated CUDA and PhysX will fully support both OpenCL and DX11.

Which brings me back to my point that OpenCL makes CUDA redundant and unnecessary for a physics API implementation, whether it's PhysX or Havok, or something else. Unless Nvidia is willing to port PhysX to that open standard instead of CUDA, it will still be limited to their proprietary HW, which will leave them at exactly the same position they're in already.

 

[Modelworks]

Originally posted by: aka1nas

Originally posted by: thilan29

Originally posted by: chizow
The conclusion then was the same as now, PhysX is capable of everything Havok is on all the same hardware while the same cannot be said of Havok in relation to PhysX.

Is PhysX actually more capable or is the hardware that it's run on more capable? (ie. would GPU accelerated Havok be similar in capability to PhysX or is Havok not able to simulate many effects that PhysX can?)

It's moot as GPU-accelerated Havok doesn't exist yet.

Actually it does exist and existed years before PhysX ever was a product.
It was abandoned at the time because GPU were too slow to be of any value compared to just using the cpu.

If you want proof that Havok can and will use the GPU when it is beneficial just wait a few days. I can't say more due to NDA but this week is going to get very interesting for hardware physics.


I have used Havok for work for nearly 7 years. I like PhysX too, but Havok is just a much more mature product. It has been around longer and because of that has had time to grow and evolve.

 

[Modelworks]

Originally posted by: chizow

Simple enough comparison, just look at the titles they list that use software PhysX and Havok. Do any of them stand out over the other? Now compare that to the titles that do have GPU accelerated PhysX. Is there a substantial improvement compared to the software physics? Based on those comparisons my conclusion is the same as it was months ago as I stated earlier: PhysX is capable of everything Havok is on all the same hardware while the same cannot be said of Havok in relation to PhysX

And that is why you should not just use things like spec sheets to compare the two.
Havok isn't as easy to compare because they made the mistake, or at least I think it was a mistake, to break down the product into categories. It was cheaper for developers at the time to purchase just what they needed vs having to pay for features they didn't.

There really is nothing that PhysX can do that Havok cannot and vice versa. When it comes down to it I would use Havok over PhysX because of the ease of use. PhysX is getting better, but it is not there yet. Havok is also supported fully in the major content creation apps for games and that alone makes it a priority over PhysX for most of the developers.

If PhysX can get Autodesk on board, then they could gain tons of market share. Autodesk has said that while they are interested in PhysX , it is the customer that decides where they put their resources. The problem with that is that the way things are done in PhysX and Havok are different enough that studios don't want to re-train to use it when what they have already works. So for now Autodesk is not going to implement it into the product line. And that means that developers will stick with what works the easiest for them.

 

[Modelworks]

Originally posted by: aka1nas

Originally posted by: instantcoffee

Currently, Havok is the most widely adopted middleware for physics. Featuring over 200 AAA game titles and then some lower budget ones. Over 100 developers have signed up with Havok. Intel is the largest GPU maker (Nvidia is largest for the discreet GPU market), while ATI is the third largest. Intel is a heavy player and owns Havok. Microsoft, another big player, have a unique deal with Havok:

Not a single one of the previous software-based Havok titles are relevant as they won't be redone to use a hardware-accelerated version of Havok (especially if this new version is based off of Havok FX). Of the major licensed engines, only Source is still using Havok, with UE3 and Gamebryo now supporting PhysX at the engine level.

They don't have to be re-done. That is one thing they did do right in Havok. They made sure that each version remained compatible in the API. The only real difference between the versions is in how inverse kinematics is calculated and that is very easy to adapt to a GPU.

Only Source ? It is still used by Gamebryo and UE3. Even Blizzard is using it in Diablo 3 and Starcraft 2. It is up to the developer who purchases the license to decide what they will use. Most developers do not purchase a engine and use it for the physics, sound, graphics, networking, etc. They purchase what they need to produce the best end result from different sources and combine them into the final product.

So the renderer might be gamebryo but the sound is Miles.



It is also supported in the major content creation applications at a very high level. PhysX is just physics. But Havok also has behavior.
I can not only create things that use physics but can also give them their own AI without ever leaving the API.

If I use PhysX then I would still have to use Havok to do the AI and pass arguments back and forth between the two API. More work for the same result.

 

[chizow]

Originally posted by: munky
Being the software guru that I am, I can tell you that CUDA is nothing more than a software API that provides a C-like interface to the GPU hardware capabilities. PhysX is implemented via CUDA, and neither have anything to do directly with DX10.

No, PhysX is implemented via [insert whatever API needed for it to be implemented]. PhysX is not reliant on CUDA at all, CUDA just so happens to be Nvidia's programming language for their own GPGPUs necessitated by the absence of a suitable alternative.

Again, being the hardware guru that you are, this should be obvious seeing how many different instances this holds true in application, right now, on the PC in both hardware and software form, on all 3 consoles, and in the past with Ageia's PPU. This will be no different with DirectX 11 as we already know Nvidia DX10 and higher parts will be compatible with DX11 compute shaders. Whether Nvidia accomplishes that via CUDA wrapper or direct bridge remains to be seen.

They sure as hell didn't use CUDA.

Right, more proof that PhysX isn't reliant on CUDA.

Which brings me back to my point that OpenCL makes CUDA redundant and unnecessary for a physics API implementation, whether it's PhysX or Havok, or something else. Unless Nvidia is willing to port PhysX to that open standard instead of CUDA, it will still be limited to their proprietary HW, which will leave them at exactly the same position they're in already.

OpenCL doesn't make CUDA redundant as PhysX support will most likely come in the form of a simple wrapper given how similar the two are. If development shifts from CUDA to OpenCL, that's one less translation layer needed which certainly simplifies things. Again, all that anyone who keeps harping about PhysX being closed or proprietary should care about is that its not actually closed or proprietary and is in fact fully compatible and supported by the very same open standards they're advocating.

After that its no longer Nvidia's responsibility to ensure their middleware is compliant with every other IHVs HW, especially when there's palpable evidence those IHVs are actively blocking PhysX support on their HW. At some point the burden falls upon those other IHVs to bring their own HW to compliance with any standards and related software if their truly interested in support. If not, well, then that's their choice too, but they'll certainly have to come up with a better excuse than "we don't want to support closed and proprietary standards" when their customers wonder why their HW doesn't support PhysX when its perfectly capable.

 

[chizow]

Originally posted by: Modelworks
And that is why you should not just use things like spec sheets to compare the two.
Havok isn't as easy to compare because they made the mistake, or at least I think it was a mistake, to break down the product into categories. It was cheaper for developers at the time to purchase just what they needed vs having to pay for features they didn't.

Actually I was referring to actual games that use both SDKs. I listed the effects to show they both support the same features that developers expect from a physics tool set as it seems some people aren't exactly sure what kind of features are available with CPU physics.

There really is nothing that PhysX can do that Havok cannot and vice versa. When it comes down to it I would use Havok over PhysX because of the ease of use. PhysX is getting better, but it is not there yet. Havok is also supported fully in the major content creation apps for games and that alone makes it a priority over PhysX for most of the developers.

You mean similar capabilities via software acceleration right? Because I'm pretty sure Havok still can't do any of the GPU accelerated PhysX features like the more advanced soft body, cloth and water simulations seen in hardware PhysX titles.

They don't have to be re-done. That is one thing they did do right in Havok. They made sure that each version remained compatible in the API. The only real difference between the versions is in how inverse kinematics is calculated and that is very easy to adapt to a GPU.

I think he means older titles will need to be retrofitted with manually added physics effects. This is similar to the situation with PhysX where the existing library of software PhysX titles did not benefit at all from Nvidia's GPU PhysX launch in August. I believe they've stated going forward that the PhysX SDK will allow for automatic scaling of effects based on hardware, which makes the most sense given the multi-platform nature of most games now.

 

[wlee15]

Demos of Havok runing through OpenCL under ATI hardware. (But apparantly the demos run well via multi-core CPU)

http://gamevideos.1up.com/video/id/24095

http://gamevideos.1up.com/video/id/24096

http://gamevideos.1up.com/video/id/24092

Courtesy of this post http://forum.beyond3d.com/show...p=1279829&postcount=20

 

[thilanliyan]

Originally posted by: chizow
You mean similar capabilities via software acceleration right? Because I'm pretty sure Havok still can't do any of the GPU accelerated PhysX features like the more advanced soft body, cloth and water simulations seen in hardware PhysX titles.

In that link you gave describing the Havok features, it said something about "Havok Cloth" so maybe it can do it.

 

[BFG10K]

Originally posted by: chizow

I think he means older titles will need to be retrofitted with manually added physics effects. This is similar to the situation with PhysX where the existing library of software PhysX titles did not benefit at all from Nvidia's GPU PhysX launch in August.

From what I understand, this isn't the case with Havok. Existing Havok games should automatically see a benefit from hardware once a back-end is implemented. This is unlike older PhysX titles that gain nothing from hardware.

Of course we?d need to see if Havok?s hardware implementation actually delivers this in practice.

 

[aka1nas]

Originally posted by: BFG10K

Originally posted by: chizow

I think he means older titles will need to be retrofitted with manually added physics effects. This is similar to the situation with PhysX where the existing library of software PhysX titles did not benefit at all from Nvidia's GPU PhysX launch in August.

From what I understand, this isn't the case with Havok. Existing Havok games should automatically see a benefit from hardware once a back-end is implemented. This is unlike older PhysX titles that gain nothing from hardware.

Of course we?d need to see if Havok?s hardware implementation actually delivers this in practice.

This wasn't the case with Havok FX, though that may have been intentional by Havok to get developers to license the FX product separately.

 

[Munky]

Originally posted by: chizow
No, PhysX is implemented via [insert whatever API needed for it to be implemented]. PhysX is not reliant on CUDA at all, CUDA just so happens to be Nvidia's programming language for their own GPGPUs necessitated by the absence of a suitable alternative.

Again, being the hardware guru that you are, this should be obvious seeing how many different instances this holds true in application, right now, on the PC in both hardware and software form, on all 3 consoles, and in the past with Ageia's PPU. This will be no different with DirectX 11 as we already know Nvidia DX10 and higher parts will be compatible with DX11 compute shaders. Whether Nvidia accomplishes that via CUDA wrapper or direct bridge remains to be seen.

GPU-accelerated PhysX does require CUDA. From Nvidia's PhysX system software page:

http://www.nvidia.com/object/physx_9.09.0203_whql.html
Supports NVIDIA PhysX acceleration on GeForce via CUDA 2.0 for SDK versions 2.7.3, 2.7.2, 2.7.5, 2.8.0 and 2.8.1 (requires graphics driver v177.81 or later).

Right, more proof that PhysX isn't reliant on CUDA.

In those cases it also doesn't use NV hardware or any GPU-acceleration at all.

OpenCL doesn't make CUDA redundant as PhysX support will most likely come in the form of a simple wrapper given how similar the two are.

OpenCL is a cross-vendor API, and CUDA isn't. Once OpenCL matures, CUDA will be of as much importance to physics as the Cg language is to graphics shaders.

If development shifts from CUDA to OpenCL, that's one less translation layer needed which certainly simplifies things. Again, all that anyone who keeps harping about PhysX being closed or proprietary should care about is that its not actually closed or proprietary and is in fact fully compatible and supported by the very same open standards they're advocating.

That's a big IF, and given Nvidia's history, I don't see them jumping for joy at shifting from CUDA to OpenCL.

After that its no longer Nvidia's responsibility to ensure their middleware is compliant with every other IHVs HW, especially when there's palpable evidence those IHVs are actively blocking PhysX support on their HW. At some point the burden falls upon those other IHVs to bring their own HW to compliance with any standards and related software if their truly interested in support. If not, well, then that's their choice too, but they'll certainly have to come up with a better excuse than "we don't want to support closed and proprietary standards" when their customers wonder why their HW doesn't support PhysX when its perfectly capable.

What evidence is that? You think Ati is actively blocking support for NV's proprietary CUDA on their video HW?

 

[ViRGE]

Originally posted by: BFG10K

Originally posted by: chizow

I think he means older titles will need to be retrofitted with manually added physics effects. This is similar to the situation with PhysX where the existing library of software PhysX titles did not benefit at all from Nvidia's GPU PhysX launch in August.

From what I understand, this isn't the case with Havok. Existing Havok games should automatically see a benefit from hardware once a back-end is implemented. This is unlike older PhysX titles that gain nothing from hardware.

Of course we?d need to see if Havok?s hardware implementation actually delivers this in practice.

Havok is statically compiled in to games, I don't see how that would be possible. The fact that PhysX (when configured to allow hardware acceleration) is not statically compiled is what has allowed NVIDIA to replace the backend.

Originally posted by: munky
In those cases it also doesn't use NV hardware or any GPU-acceleration at all.

Don't be so bull-headed, munky. You know what he means - there's nothing about PhysX that keeps it tied to CUDA, it can be ported again if NVIDIA wants to.

 

[BFG10K]

Originally posted by: ViRGE

Havok is statically compiled in to games, I don't see how that would be possible.

You could be right, though I have seen games with havok.dll files and similar, indicating the Havok code is a shared library being loaded at run-time.

If one were to replace the games? DLL with a system one that has a hardware back-end, any game that uses Havok like that could benefit. At least in theory, as there?s no concrete evidence of this working yet.

This is kind of like OpenAL on Vista to get hardware acceleration from Creative cards.

 

[chizow]

Originally posted by: munky
GPU-accelerated PhysX does require CUDA. From Nvidia's PhysX system software page:

http://www.nvidia.com/object/physx_9.09.0203_whql.html
Supports NVIDIA PhysX acceleration on GeForce via CUDA 2.0 for SDK versions 2.7.3, 2.7.2, 2.7.5, 2.8.0 and 2.8.1 (requires graphics driver v177.81 or later).

Yep, GPU-accelerated PhysX relies on CUDA now, a C-based language developed by Nvidia for lack of a suitable alternative, but PhysX isn't bound to CUDA in any way, shape or form. Again, as demonstrated in numerous applications and implementations today on the PC, consoles and Ageia PPU along with future support for OpenCL and DX11 GPU-accelerated PhysX.

In those cases it also doesn't use NV hardware or any GPU-acceleration at all.

And neither does CPU accelerated PhysX, yet CUDA isn't needed there, either.

OpenCL is a cross-vendor API, and CUDA isn't. Once OpenCL matures, CUDA will be of as much importance to physics as the Cg language is to graphics shaders.

LOL ya, its probably a good thing Nvidia chaired the standard, so that once OpenCL matures nothing about it should surprise them. Given its similarities to CUDA, I don't think that'll be a problem. Until then they'll just have to manage with CUDA I suppose. Certainly beats smoke and mirrors.

That's a big IF, and given Nvidia's history, I don't see them jumping for joy at shifting from CUDA to OpenCL.

Why wouldn't they? More developers writing apps for their hardware could only be a good thing for their GPGPU business. Not only do they enjoy a greater share of that market now, Nvidia parts have been shown to outperform ATI parts in GPGPU applications with few exceptions.

What evidence is that? You think Ati is actively blocking support for NV's proprietary CUDA on their video HW?

I guess you haven't been paying attention beyond AMD's claims about not supporting "closed and proprietary standards" with regard to CUDA and PhysX while of course, pushing their own preferred closed and proprietary standards in Havok and Stream/Brook+.

Does AMD block PhysX on Radeon development?
Why Won't ATI Support CUDA and PhysX
Nvidia offers PhysX support to AMD/ATI

and of course this gem where he details AMD's GPU physics strategy of "when it makes sense."

AMD says PhysX will die

Unfortunately for Godfrey and AMD, it looks as if there's a greater chance AMD will die before PhysX.

 

[chizow]

Originally posted by: BFG10K
From what I understand, this isn't the case with Havok. Existing Havok games should automatically see a benefit from hardware once a back-end is implemented. This is unlike older PhysX titles that gain nothing from hardware.

Of course we?d need to see if Havok?s hardware implementation actually delivers this in practice.

I don't think that's possible, as Havok isn't scalable beyond what's already coded into the game and limited by whatever physics/fidelity settings its shipped with. Meaning, just because I upgrade my CPU (or to a GPU-accelerated Havok library in the future), that doesn't mean Havok effects are going to scale dynamically to take advantage of that extra processing power. If anything, the existing effects will run faster or allow for additional effects up to the setting limits it shipped with. Retrofitting those effects would require additional content creation or at the very least a patch to increase its existing physics parameters. Manual editing of .ini and .dll files might work too, but I'm not overly optimistic.

 

[chizow]

Originally posted by: thilan29
In that link you gave describing the Havok features, it said something about "Havok Cloth" so maybe it can do it.

Actually wlee15's first link is more of what I'm referring to. So it does seem as if Havok has a GPU accelerated OpenCL client. The question now is when will we see it available for public consumption.

To give a good idea of what cloth simulations are being used in current games based on software Havok and PhysX, look at Assassin's Creed in Masyaf near Al Mualim's desk. You'll see two brotherhood banners there that would benefit immensely from hardware accelerated physics. All the character models would as well, especially Al Tahir with his robe/dress garb.

 

[BenSkywalker]

You basically support a Microsoft monopoly then.

MS sets the standards for PC gaming. They have no interest towards that end except to keep PC gaming as attractive as possible. It is in their best interest in that aspect of their business to look out for our best interests. If the enthusiast market pushed into Linux in droves and dropped MS completely, it would hurt their business considerably in the long run.

First of all, stop rambling on about GPU-based physics as hardware and CPU-based physics as software. They are all software-based solutions, except that the software runs on different hardware.

That is a very interesting hair you are splitting, and one I think pretty much everyone in the industry would take a very different view of. I guess if you have partioned off in your mind that GPUs are strictly for graphics I could see the logic, but seeing them as available dedicated vector co processor for certain tasks changes the scope of things. This, in essence, is what GPGPU is pushing from all the different companies involved.

Cutting the Nvidia marketing BS aside, how do they plan on supporting PhysX via OpenCL and DX11 when at present it relies on CUDA?

It doesn't rely on CUDA, it uses CUDA when there is a CUDA capable video card. PhysX will run on x86 just fine, without CUDA. It runs on the PPUs just fine, without CUDA. It runs on the Wii just fine, without CUDA. It runs on the PS3 just fine, without CUDA. At this point a trend should be noticeable, PhysX runs on more non CUDA hardware then it does CUDA hardware, it runs on more non CUDA platforms then ones that support it. I think nVidia might be able to figure out a way to get PhysX running on non CUDA parts using OpenCL. As far as abandoning CUDA, why would they? Optimal code path anyone?

Also, what tangible PhysX effects have you seen in games other than extra crap on the screen?

Good point, what the hell have I been thinking. Asking my graphics card to give me better graphics.... I mean really, if I was looking for better graphics I'd go out and buy a graphics card, no need to throw that on my graphics card

We aren't going to see more advanced physics used for gameplay until certain companies enter into a more enlightened state with their perspective on what can be done today. We also need to get rid of WinXP to be truly viable in the PC space(DX9 rolls over and dies when we throw loads of small batch geometry at it).

There are other points you raised, but I think Chizow has them covered. The biggest one is ATi refusing to allow their customers to have PhysX now. It was offered to them, they refused. This isn't anything resembling nVidia trying to keep a monopoly, they have already opened up their dev rel to getting PhysX on ATi hardware running, ATi stopped it. ATi is the reason ATi users don't have support for PhysX now and this entire conversation wouldn't be necessary. Then we could let the APIs battle it out on merit instead of politics.

 

[dreddfunk]

Just a question, why would it make sense for AMD to adopt PhysX as a standard implementation, with PhysX in the hands of Nvidia?

With a third-party in control of the implementation, they would have the incentive to make the implementation run as well as possible on all hardware. With one of the primary parties in control of the implementation, they have an incentive for all hardware to *run* the implementation, but they have little incentive for all hardware to run it *well*.

As long as the adoption of one standard or the other is used in service of driving GPU sales, consumers will suffer. The sooner an implementation is adopted that isn't tethered to GPU sales, the better off we will be.