Slide 23 of 26, I've seen it elsewhere but this is one of the many links that popped up by simply searching "PhysX source $50". Glancing over some of your other replies, this takes care of most of the irrelevance.
In fact, no it does not. Read the slide a little more carefully. The listed prices are for PhysX SDK, not the physX core's source code. In other words, the slide shows that you can get compiled tools to develop on PhysX for free, or you can purchase the source code SDK for $50,000. It does not give the buyer the source code to PhysX itself.
You could substitute PhysX for DirectX in that sentence verbatim, thanks for proving my point. The difference is of course Microsoft would just laugh at you if you asked for their source code.
Actually, no, you cannot. Applications developped on DirectX will run on ANY modern hardware. Applications developped on PhysX will ONLY run on nvidia hardware. It's a subtle difference, I know, but it is the defining difference of this point. Also, developing on PhysX is only free if you do not intend to make use of the source code-version SDK. If you do, it's $50,000 to license it.
Again, the source code is irrelevant unless AMD was planning to integrate it into an engine or their own API, but we all know they don't have anything on either of those fronts. They're not porting anything because they have nothing to port, all they need to do is write a driver for their hardware for the existing API and piggy-back the efforts of others. Again, from an earlier post the progression from hardware to software would look like:
Everything else is in-place, all AMD needs to do is make their hardware compatible with prevaling API and everything else should take care of itself. In this case, PhysX source would only be relevant for those dealing directly with the API and middleware, and AMD has no control over any of those factors so the source is irrelevant.
How do you propose AMD make their hardware compatible with nvidia's proprietary API? You can't install the nvidia driver for use with an AMD graphics card, it doesn't work. Nvidia have even gone so far as to disable their own GPUs from accelerating PhysX if an AMD GPU is even detected in the system. In order to accelerate PhysX, the PhysX application core would need to be written into AMD's drivers. Short of reverse engineering the nvidia drivers (which I'm fairly sure is illegal), they would have to port nvidia's PhysX core, and in order to port something, you need to have the original source code. Nvidia owns the source code to the PhysX core, therefore AMD would have to license it, et cetera. I believe we've gone through this point before.
PhysX is the #1 SDK in production, but GPU acceleration is obviously going to be an uphill struggle due to the strong industry focus on consoles. As such, features like GPU PhysX are going to be value-add for the PC only which means any dev house would have to weigh the pros and cons of adding such a feature. Most will not due to the additional development cost, which is why Nvidia's TWIMTBP program helps with development, but as each title that uses PhysX releases, that increases the chance more will in the future as the tech gains momentum.
The whole point of AMD's movement to make physics acceleration an open source matter is not only to promote compability, but also to avoid an extreme amount of time put into a proprietary physics engine for just this reason. With open source standards available, the graphics companies do not have to worry about developing their hardware physics engines - DirectCompute or OpenCL will take care of it through any potential number of physics APIs in the future. Bullet is only the beginning.
I also disagree with your notion that GPU-accelerated physics will be a value-add feature only. I believe that as open-source physics processing solutions become more available, we are going to see a large increase in the number of games released with advanced physics. At the moment, PhysX is still a turn-off to developers for the simple reason that it is still proprietary to nvidia.
As for the nonsensical scenario you brought up about revoking licenses and hardware coming under scrutiny....I think you'd have to cross that bridge of AMD supporting PhysX before donning the tin foil hat. Not to mention licensing agreements are put in place for just that reason, to prevent any arbitrary revocation of license.
A license agreement is a document drafted by licenser to the licensee, to be agreed to by the licensee. In order to license PhysX from nvidia, nvidia can potentially put anything they want to in that document, including reserving the right to break the agreement at any time. If, as you say, all nvidia wants is to further the physics acceleration market with PhysX, then why have they not ported it to DX11 or OpenCL and made the core open source?
Yes apparently AMD is going to come through with a groundbreaking revelation that redefines what we know about physics if they ever get their hands on that source code. Much easier than just providing a driver for their hardware.
Your sarcasm is lost, as it comes from a misinterpretation. Not only does nvidia not sell the PhysX core source code, but even if they did, they would charge more than $50,000 for it. When I said groundbreaking, I meant simply that PhysX has the potential to be a groundbreaking piece of hardware/software cooperation (as seen in the few games that actually do use it), if nvidia would simply get their claws out of its stomach and allow it to become an open source standard.
That might actually make sense if DirectCompute was open source in any way, but its not, its a standard proprietary to Microsoft. Nvidia is simply supporting all standards and API unapologetically without disingenuous excuses. Some companies produce solutions, some produce excuses.
Microsoft does not make GPUs. The DirectCompute source was built by microsoft, that is true, but it is designed to allow any graphics card with compute shaders to perform tasks other than simple graphics. There's a fine difference between PhysX here. The tools to develop for PhysX are free, but even the source code for those tools is not - nvidia is charging $50,000 for it. As well, PhysX acceleration was specifically written to operate only on nvidia GPUs - point being, AMD does not have a choice here. They cannot support PhysX because they do not have access to the API source code, and nvidia is not going to write a driver that accelerates PhysX on AMD's GPUs just because they can.
Actually comparing CAL to CUDA doesn't look like fanboy-ism, it reeks of it. Honestly I haven't seen CAL mentioned in at least a year when referring to GPGPU. Go to any GPGPU developer forum and compare the two and see how people who actually use the tools react to the comparison.
CUDA isn't dead, in fact its growing, adapting and improving. It was never just an API, it was Nvidia's top-to-bottom GPGPU compute architecture. The progression I detailed is ALL encompassed within CUDA, from the hardware to the middleware. What's next for CUDA? How about integration into one of the most popular production IDE with Visual Studio, which will provide a one-stop debugger and compiler for Nvidia hardware for all relevant API: CUDA C, OpenCL, DirectCompute, Direct3D, and OpenGL.
No company is perfect. CAL was a flop in terms of performance. I have a GTX 285 in my gaming rig, and I know how many more PPD I get in GPU2 folding than I do in any 4000 series radeon. However, to promote healthy competition in hardware and in the spirit of growing the industry, standards need to be in place, whether they be open source or not. DirectX is an excellent example of a standard which is not open source, and yet also encourages the industry to grow. In this way, DirectX encourages the graphics market to improve, while favoring neither AMD or nvidia, or even Microsoft for that matter.
Once again, Nvidia is providing solutions for their hardware that interested parties actually want and will put to good use. What's AMD doing? Oh right, doing another interview criticizing Nvidia.....
Any criticism coming from AMD is warranted, until nvidia shows that they are willing to move toward standardizing their APIs without requiring AMD (or other companies) to pay for or license them.
Ya its the heart of Nvidia's heterogenous computing model, except they don't plan to have much use for more than a few x86 CPU cores if all goes according to their plans.
No it won't be obsolete, but its role will be vastly diminished to the point its just a tiny beating heart in a vastly undersized body feeding a massive GPU for a brain (again according to Nvidia's heterogenous computing model).
I seem to recall a certain statement about tin-foil hats... this is much further in the future than physics acceleration APIs are.
Again already been down this path of hypocrisy. AMD clearly has no problems supporting closed and proprietary standards (see: DirectX, Direct Compute and Havok). These lies only go so far, especially when AMD embarassingly backpedaled on their endorsement of Havok, probably after coming to the revelation Intel has no interest whatsoever in providing GPU acceleration to anyone before Larrabee is ready (and maybe never for competitors).
You don't see anything potentially unsettling for AMD in this scenario? Maybe nvidia really wouldn't use the licensing of PhysX to AMD in a manner that would undermine AMD's efforts, but if you were on AMD's board of directors, would you take that chance? By licensing PhysX from nvidia, they are allowing PhysX to become the standard, and when it does, AMD's GPU production is entirely at nvidia's mercy.
Again, completely unsubstantiated fearmongering. Not only do you put far too much importance on physics over 3D capability driving sales, all AMD would have to do to avoid any such fictitious release roadblock would be to simply pull PhysX support and launch their product. Or more than likely, just launch their product, claim support for said feature, then play catch up some point down the line with hastily applied driver updates.
I don't even know where to begin with this paragraph.
If AMD adopts PhysX now, the software developer adoption rate of PhysX to do physics acceleration could very well become a standard, hence the assumption that in 2 years' time, 50% of all new releases would use the PhysX library. AMD's graphics cards could have the rendering power of god himself, but if they can't do PhysX, they're sunk.
They can't break the license agreement with nvidia, and then patch PhysX support in afterward. That would quite literally be breaking the law. They signed an agreement, broke it, and then continued to implement a proprietary standard anyway? Nvidia would sue them so fast you wouldn't even know what happened.
No the point of open source is so that you have some control over the content of the standard so that you're not at an arbitrarily imposed disadvantage. After that, provided they're running the same API, the faster hardware wins.
Provided they're running the same API, the faster hardware wins?
You just summed up why PhysX is hurting customers. AMD can't run the same API unless nvidia licenses the PhysX source code to them, or nvidia actually writes a PhysX API for AMD's GPUs themselves. Either way, AMD loses.
For CUDA the reason is obvious, people actually used it so the API libraries have built up and evolved over time with numerous apps developed for it. Porting CUDA and its runtimes to OpenCL and DirectCompute make a lot more sense than re-inventing the wheel. In fact, with tools like Nexus, it shouldn't be much more difficult than simply debugging and recompiling the output to whatever target API you choose.
I never said anywhere that PhysX or CUDA should be outright abolished. What I said is that the release of vendor-neutral tools makes proprietary APIs obsolete. If nvidia were to port PhysX to OpenCL, then there is no problem whatsoever, as the APIs are then no longer proprietary. AMD could support it without licensing it, and everything moves forward as normal. Unfortunately, that is exactly what nvidia is not doing - they are continuing to develop PhysX as a proprietary standard.
As for the guarantee....no there is no guarantee, especially if a vendor doesn't provide a driver for their own hardware for that API. <----***hint important point hint ****
You seem to be referring to PhysX as though it is a standard. AMD can't write a driver for an API they don't have access to. Your "important point" is, in fact, gibberish in this regard.
You can make the point again and it wouldn't make you any more correct. They don't need the PhysX source code, all they need to do is write a driver for their own hardware for the API backend needed for PhysX acceleration, CUDA. Would they potentially need Nvidia's support to write that driver? Maybe, but again there's no need to cross that hypothetical bridge because its clearly a question that has not been posed. That's the problem, its the question that's never asked.
You just conceded to my argument with this paragraph. AMD would need nvidia's help to write a driver for PhysX, meaning, they need to license the PhysX core in order to understand exactly how it works in order to reproduce it on their hardware.
Yes I'm well aware of the history and already detailed it in an earlier post. They acquired the IP to further their GPGPU efforts and sell their hardware, all that other irrelevance you wrote makes no sense. The only way PhysX gains traction is if its install-base increases, meaning more hardware supports it. In the long-term I see Nvidia leveraging this technology to get their hardware into the next-gen consoles, at which point the technology will be truly ubiquitous in games and we'll truly see it integrated seamlessly across multiple platforms.
Sony had to license PhysX from nvidia to put it in the PS3. They couldn't simply write a driver for it and say "oh look, we have hardware PhysX acceleration!" Why do you think it's going to be any different for AMD?
The only way the technology becomes supported by more hardware at present is when other companies license the tech from nvidia. In order to support it, AMD would have to do the same thing, and I think you know where this train of thought is going.
Yes its obvious you're unfamiliar with the timeline when you ask questions why Nvidia chose to develop on CUDA or why they didn't just conveniently port it to API and standards that didn't exist yet. Not even going to bother with some of the common fallacies I glanced over in there.
Where did I ask why nvidia chose to develop CUDA? I only pondered why instead of allowing PhysX to be open source to promote growth, they kept it proprietary and only accelerated by their own GPUs unless another company chose to request to license it. I also said nothing about porting PhysX or CUDA to OpenCL immediately after they acquired the PhysX technology. The point I was (and am) making is that now that the free standards are available in the forms of DirectX 11 and OpenCL, nvidia is still keeping their technology proprietary, and getting other companies to license it from them.
Why would Nvidia need to demonstrate anything when all of their actions up until the driver lockout have been more than honorable? Again, follow the progressions in the links from my first post and compare what Nvidia said and did to what AMD said and did. Nvidia holds all the cards now, they have no reason to offer PhysX on a platter in light of the negative press and publicity generated by AMD in the press.
Nvidia does not hold all the cards, and that is precisely why they are holding onto PhysX as tightly as they can (and going against the open source initiative in doing so). They may be assisting in the development of OpenCL, but they are also devoting most of their resources to the furthering of PhysX, even when there are vendor-neutral APIs available.
Consider also how delayed their GT300 is going to be behind the Radeon 5000 series. I believe the motivating factor behind nvidia not wanting to port PhysX to a vendor-neutral API is that nvidia's R&D screwed up and are way behind AMD. They are therefore looking for as many ways to stall AMD's sales as they can.
Again you seem to be ignoring what's occurring in reality. You also conveniently ignore the fact Nvidia also supports the same standards, and currently better than AMD mind you. You keep claiming Nvidia's introduction of innovative, value-add features somehow hurts the consumer, but that's clearly false as it benefits anyone that purchases their hardware, which is again, the overwhelming majority by any metric.
I'm sure I'd enjoy it more if I was actually debating someone familiar with the material being discussed. As it is now its more like fact checking and correcting a lot of assumptions and misinformation.
We're discussing the ramifications of PhysX acceleration in the near to medium future, and you're calling your points "fact"? It hasn't happened yet, therefore everything by both you and I is opinion. You're entitled to your opinion, but please, don't try to push it as fact. That's frankly an insult to my intelligence.
The big thing I'm seeing here that you don't seem to understand is what an SDK is. SDK stands for Standard Development Kit. It is a set of tools used to develop software for a platform. The PhysX SDK is for game developers to develop and compile code that will run on PhysX compatible cards. Of course Nvidia is going to make that available, if they don't no game manufacturers can actually utilize the technology. The thing is though, the SDK does not in any way shape or form allow AMD to develop a card that will run PhysX. PhysX is more than just software, it's also in the hardware. Could AMD reverse engineer it and make their own cards compatible? Probably, yes. However that would open them up to a whole host of legal issues and Nvidia would sue them to death, thus their only option would be to license the rights to produce PhysX hardware from Nvidia. This would make it so that, as bean has rightly stated many times before, Nvidia would be able to inspect AMD hardware before release, potentially delay the release of AMD hardware and refuse to renew the license at any time thus screwing AMD if PhysX ever became dominant in games. For AMD to put their product in a position of being reliant on their main competitor would be a very stupid business move and the only people it would benefit would be Nvidia itself as they would essentially have control of all future AMD products.
In fact, no it does not. Read the slide a little more carefully. The listed prices are for PhysX SDK, not the physX core's source code. In other words, the slide shows that you can get compiled tools to develop on PhysX for free, or you can purchase the source code SDK for $50,000. It does not give the buyer the source code to PhysX itself.
Unbelievable. Give me a single reason I should continue on with someone who argues so dishonestly? Your failure to acknowledge such a simple fact, that the PhysX source is available for $50K, can only be taken as extreme dishonesty or profound ignorance.
Just in case you weren't sure which slide I was referring to and the relevant portions I went ahead and highlighted them for you.....
That slide is directly from Nvidia, but if you google the exact paramaters I stated "PhysX Source $50" and see what other hits you get. You'll find many more from interested parties who either know from experience or inquiry that the SDK source code costs $50K.
As for semantics, there is a compiled Binary SDK with GUI tools that is free to use, and there is the source code SDK (includes compiler, debugger, whatever else) that costs $50K. There isn't some extra super sekret handshake SDK, that's all there is lol.
Anyways, until we can get by this hurdle there's really no reason for me to continue arguing with you. As I stated in my last reply, debating with someone who clearly isn't familiar with the material and is unwilling to acknowledge simple facts is about as gratifying as banging your head against the wall lol. :banghead:
The big thing I'm seeing here that you don't seem to understand is what an SDK is. SDK stands for Standard Development Kit. It is a set of tools used to develop software for a platform. The PhysX SDK is for game developers to develop and compile code that will run on PhysX compatible cards.
The acronym "SDK" is actually commonly acknowledged as an abbreviation for "Software Development Kit". You got the bolded portion right, but that's about the extent of it. SDK is just software used to create more software. By that definition alone, you're clearly incorrect in trying to limit its scope to a single application along the hardware to software progression I've already listed a few times.
Unbelievable. Give me a single reason I should continue on with someone who argues so dishonestly? Your failure to acknowledge such a simple fact, that the PhysX source is available for $50K, can only be taken as extreme dishonesty or profound ignorance.
Just in case you weren't sure which slide I was referring to and the relevant portions I went ahead and highlighted them for you.....
That slide is directly from Nvidia, but if you google the exact paramaters I stated "PhysX Source $50" and see what other hits you get. You'll find many more from interested parties who either know from experience or inquiry that the SDK source code costs $50K.
As for semantics, there is a compiled Binary SDK with GUI tools that is free to use, and there is the source code SDK (includes compiler, debugger, whatever else) that costs $50K. There isn't some extra super sekret handshake SDK, that's all there is lol.
Anyways, until we can get by this hurdle there's really no reason for me to continue arguing with you. As I stated in my last reply, debating with someone who clearly isn't familiar with the material and is unwilling to acknowledge simple facts is about as gratifying as banging your head against the wall lol. :banghead:
On that very page you linked, the acronym "SDK" appears so many times, I simply cannot put polite words to this. If you haven't noticed that that slide is giving information on the PhysX SDK (not PhysX itself), then I simply don't know what more I can tell you. You're convinced of all your arguments based on a false belief which you are refusing to acknowledge even though I and Ardichoke have both pointed it out.
On that very page you linked, the acronym "SDK" appears so many times, I simply cannot put polite words to this. If you haven't noticed that that slide is giving information on the PhysX SDK (not PhysX itself), then I simply don't know what more I can tell you. You're convinced of all your arguments based on a false belief which you are refusing to acknowledge even though I and Ardichoke have both pointed it out.
HAHAHAH. All you two have proven is that there's no point in arguing with people who choose food-related pseudonyms. It seems you're both hung up on the acronym SDK, which isn't surprising since your definition is conflicted and inaccurate to begin with. Its simply software that is used to create more software. Apply that to the context of the source code SDK and it still applies and holds true.
HAHAHAH. All you two have proven is that there's no point in arguing with people who choose food-related pseudonyms. It seems you're both hung up on the acronym SDK, which isn't surprising since your definition is conflicted and inaccurate to begin with. Its simply software that is used to create more software. Apply that to the context of the source code SDK and it still applies and holds true.
That is exactly the point we are making - an SDK is simply software to facilitate making more software. It is not the source code to the PhysX engine itself. This means that other companies cannot purchase the PhysX core in order to port it or tinker with it.
Your argument is in conflict with itself. I suggest you re-read Ardichoke's post describing what an SDK is and is not - it might clarify some things for you.
This is quickly devolving into personal attacks. Let's be a little more gentlemanly, eh?
There's nothing personal from my standpoint, his unwillingness to acknowledge such simple (and trivial) facts like the PhysX Source SDK being available for $50K can only be interpreted as dishonesty or profound ignorance.
That is exactly the point we are making - an SDK is simply software to facilitate making more software. It is not the source code to the PhysX engine itself. This means that other companies cannot purchase the PhysX core in order to port it or tinker with it.
Wrong again, the source code SDK isn't just the HL source code, it also includes additional software tools to facilitate debug and compile, which again, satisfies the requirements of an SDK by the correct definition.....
Chizow, you sound like you are defending the definition of an SDK, is that the case? Everybody seems to know that definition, I don't think that is in question.
What is on debate is this.. Can AMD use that to make PhysX run on their cards? Answer is no.
Yep, the source is $50K as I'm pretty sure I've already mentioned, but you would only need the source if you wanted to integrate it into your own tools, recompile it for whatever reason for perhaps target hardware.
This was the crux of your argument against AMD. You said they could purchase the source code to PhysX itself for $50,000 and then make their hardware accelerate it using the code. I believe I have shown that the source code to the PhysX core is, in fact, not available for sale from nvidia. I never contested that the SDK is there:
The SDK is free, this is 100% true. However, the SDK only makes it easier to write code that interacts with the PhysX core, whose source is owned by nvidia, and has to be licensed (even if it's licensed for free) by other companies in order to run at the hardware level.
Chizow, you sound like you are defending the definition of an SDK, is that the case? Everybody seems to know that definition, I don't think that is in question.
What is on debate is this.. Can AMD use that to make PhysX run on their cards? Answer is no.
No I'm pointing out the selective application of SDK for the PhysX binary SDK vs. the PhysX source code SDK. They're both "SDK", which was a continuous point of contention that's clearly inaccurate.
As for whether AMD can use it to make PhysX run on their cards, again, they wouldn't have to, the API is there, the binaries are there, they would just need to write a driver for their own hardware to interface the API. This is no different than them writing a driver for OpenCL or DirectCompute.
This was the crux of your argument against AMD. You said they could purchase the source code to PhysX itself for $50,000 and then make their hardware accelerate it using the code. I believe I have shown that the source code to the PhysX core is, in fact, not available for sale from nvidia.
And I've shown time and again you're clearly wrong, the source code is available for purchase. Why you continue to cling to this bit of misinformation is beyond me.
The only reason you would need it is if you wanted to port or compile to a different target API or hardware. But AMD wouldn't even need to go that far unless they wanted to port PhysX to OpenCL or DirectCompute for their own hardware, all they would have to do to circumvent those steps is to write a CUDA driver for their own hardware. Yes it might involve help from Nvidia or the aid of an additional SDK, but it'd be CUDA's SDK, which again brings me back to the point the emphasis on PhysX's source is irrelevant to begin with.
No I'm pointing out the selective application of SDK for the PhysX binary SDK vs. the PhysX source code SDK. They're both "SDK", which was a continuous point of contention that's clearly inaccurate.
As for whether AMD can use it to make PhysX run on their cards, again, they wouldn't have to, the API is there, the binaries are there, they would just need to write a driver for their own hardware to interface the API. This is no different than them writing a driver for OpenCL or DirectCompute.
And I've shown time and again you're clearly wrong, the source code is available for purchase. Why you continue to cling to this bit of misinformation is beyond me.
The only reason you would need it is if you wanted to port or compile to a different target API or hardware. But AMD wouldn't even need to go that far unless they wanted to port PhysX to OpenCL or DirectCompute for their own hardware, all they would have to do to circumvent those steps is to write a CUDA driver for their own hardware. Yes it might involve help from Nvidia or the aid of an additional SDK, but it'd be CUDA's SDK, which again brings me back to the point the emphasis on PhysX's source is irrelevant to begin with.
It doesn't matter which source code AMD would need from nvidia, the point here is that they can't simply write a PhysX driver without having at least some of nvidia's proprietary code. AMD would need to license it from nvidia, which would make them responsible to nvidia for all future products they make which accelerate PhysX. This isn't a position AMD wants to be in, which is a point I've made again and again.
It doesn't matter which source code AMD would need from nvidia, the point here is that they can't simply write a PhysX driver without having at least some of nvidia's proprietary code. AMD would need to license it from nvidia, which would make them responsible to nvidia for all future products they make which accelerate PhysX. This isn't a position AMD wants to be in, which is a point I've made again and again.
Once again, I don't see how this can be made any more obvious. If AMD wanted to support PhysX on their hardware natively, they could take 2 approaches:
1) Use the existing PhysX binaries, runtimes and API (CUDA) that are already in place on the PC and just write their own CUDA driver for their hardware. As Dave Hoff said, porting runtimes and drivers between the API in question, DC, OpenCL, CUDA, is "trivial" given how similar they are. Given their minimalistic approach, this would make the most sense, IF they wanted to support PhysX of course.
2) Use the PhysX source code SDK and whatever API SDK of their choosing (OpenCL, DirectCompute, CAL lol) to port and compile PhysX for that API and their own hardware. This is no different than the process used to port PhysX from the PC to the 360, PS3, Wii, iPhone...and of course GeForce GPUs.... In this case, any licensing concerns would be agreed upon according to the licensing agreement and AMD would be in control of their own PhysX implementation.
Both are viable paths that would work from different ends of the problem to come to a similar resolution, but obviously it takes a willing party to get there. But as we all know, AMD would rather feed the press with disingenuous reasons for why they won't support PhysX while leaving their customers to fend for themselves with hacks and workarounds.
Once again, I don't see how this can be made any more obvious. If AMD wanted to support PhysX on their hardware natively, they could take 2 approaches:
1) Use the existing PhysX binaries, runtimes and API (CUDA) that are already in place on the PC and just write their own CUDA driver for their hardware. As Dave Hoff said, porting runtimes and drivers between the API in question, DC, OpenCL, CUDA, is "trivial" given how similar they are. Given their minimalistic approach, this would make the most sense, IF they wanted to support PhysX of course.
Dave Hoff has pointed out that it would be easy for nvidia to port their existing APIs to OpenCL. AMD cannot just do it on their own, as they do not have access to the PhysX or CUDA source codes.
2) Use the PhysX source code SDK and whatever API SDK of their choosing (OpenCL, DirectCompute, CAL lol) to port and compile PhysX for that API and their own hardware. This is no different than the process used to port PhysX from the PC to the 360, PS3, Wii, iPhone...and of course GeForce GPUs.... In this case, any licensing concerns would be agreed upon according to the licensing agreement and AMD would be in control of their own PhysX implementation.
The PhysX source code SDK is not the same thing as the source code to the PhysX core. The source code SDK is, simply put, the developer tools for PhysX, in pre-compiled form, to allow portability to any developing environment. It does not contain any usable code toward porting PhysX itself to other hardware.
Both are viable paths that would work from different ends of the problem to come to a similar resolution, but obviously it takes a willing party to get there. But as we all know, AMD would rather feed the press with disingenuous reasons for why they won't support PhysX while leaving their customers to fend for themselves with hacks and workarounds.
In fact, neither way is viable because in either scenario, nvidia needs to port it themselves or give AMD their source code. This would require that they either make their sources open, or license it to AMD. The latter is not desirable to AMD, which is why they currently don't support PhysX.
Dave Hoff has pointed out that it would be easy for nvidia to port their existing APIs to OpenCL. AMD cannot just do it on their own, as they do not have access to the PhysX or CUDA source codes.
Wrong, he's simply ducking or avoiding the question that isn't explicitly asked, it would be just as easy to port it from CUDA as it would be to port it to CUDA. That's the beauty of software and reverse engineering. Erwin Coumans affirms this in his interview with TechLegion, also saying porting between the 3 API would be "trivial".
The PhysX source code SDK is not the same thing as the source code to the PhysX core. The source code SDK is, simply put, the developer tools for PhysX, in pre-compiled form, to allow portability to any developing environment. It does not contain any usable code toward porting PhysX itself to other hardware.
LMAO, I see the problem here. You're inventing some additional abstraction layer in your mind. As the slide I linked clearly stated and as I've repeated numerous times, the PhysX Source Code SDK includes the High-Level source code which is written in any one of the prevailing high-level programming languages in use today, most commonly C or some derivative.
This code is then compiled to output in binary, which is then translated into machine code by the driver for target hardware. There is no additional step, there's the compiled free PhysX SDK binaries and there's the $50K PhysX Source Code SDK that includes the HL source code and debugging tools and software. That's it, there's no super sekret Nvidia martian source code language covered in green anti-AMD kryptonite.....
In fact, neither way is viable because in either scenario, nvidia needs to port it themselves or give AMD their source code. This would require that they either make their sources open, or license it to AMD. The latter is not desirable to AMD, which is why they currently don't support PhysX.
Nvidia really doesn't need to do either, at some point AMD needs to be responsible for support of their own hardware. I've outline the two ways they could make it happen. The impetus isn't on Nvidia, they've created a value-add feature on their hardware and fully support it free of charge.
Wrong, he's simply ducking or avoiding the question that isn't explicitly asked, it would be just as easy to port it from CUDA as it would be to port it to CUDA. That's the beauty of software and reverse engineering. Erwin Coumans affirms this in his interview with TechLegion, also saying porting between the 3 API would be "trivial".
LMAO, I see the problem here. You're inventing some additional abstraction layer in your mind. As the slide I linked clearly stated and as I've repeated numerous times, the PhysX Source Code SDK includes the High-Level source code which is written in any one of the prevailing high-level programming languages in use today, most commonly C or some derivative.
This code is then compiled to output in binary, which is then translated into machine code by the driver for target hardware. There is no additional step, there's the compiled free PhysX SDK binaries and there's the $50K PhysX Source Code SDK that includes the HL source code and debugging tools and software. That's it, there's no super sekret Nvidia martian source code language covered in green anti-AMD kryptonite.....
Nvidia really doesn't need to do either, at some point AMD needs to be responsible for support of their own hardware. I've outline the two ways they could make it happen. The impetus isn't on Nvidia, they've created a value-add feature on their hardware and fully support it free of charge.
At this point, it's clear to me you're not making the distinction properly between the Software Developer's Kit and the actual product itself. There's no point in continuing this debate until you do a little more research to educate yourself properly in the aspects of software development.
Once again, I don't see how this can be made any more obvious. If AMD wanted to support PhysX on their hardware natively, they could take 2 approaches:
1) Use the existing PhysX binaries, runtimes and API (CUDA) that are already in place on the PC and just write their own CUDA driver for their hardware. As Dave Hoff said, porting runtimes and drivers between the API in question, DC, OpenCL, CUDA, is "trivial" given how similar they are. Given their minimalistic approach, this would make the most sense, IF they wanted to support PhysX of course.
2) Use the PhysX source code SDK and whatever API SDK of their choosing (OpenCL, DirectCompute, CAL lol) to port and compile PhysX for that API and their own hardware. This is no different than the process used to port PhysX from the PC to the 360, PS3, Wii, iPhone...and of course GeForce GPUs.... In this case, any licensing concerns would be agreed upon according to the licensing agreement and AMD would be in control of their own PhysX implementation.
Both are viable paths that would work from different ends of the problem to come to a similar resolution, but obviously it takes a willing party to get there. But as we all know, AMD would rather feed the press with disingenuous reasons for why they won't support PhysX while leaving their customers to fend for themselves with hacks and workarounds.
You're making the same debunked arguments over and over again going round and round in circles. AMD cannot just up and use PhysX because Nvidia owns the patent on it and would sue them into the dirt if they did. You seem to not understand how patents work. The basis of this whole thing boils down to this one simple FACT.
PhysX is a patented middleware program to simulate Physics. The key word there being patented. This means that to even make a compatible clone of it, AMD has to LICENSE THE RIGHTS TO DO SO from the owner, aka NVidia. This would mean that Nvidia could exert power over AMDs products and drivers in that they could refuse to license them, they could slow down their releases by requiring they inspect all new cards or drivers before release or they could do a number of other things to screw AMD over using the license for their proprietary, patented technology. That would be a monumentally stupid business decision on AMDs part whereas developing an open source physics API, while it won't allow them to put a stranglehold on the market like a proprietary API would, will advance physics acceleration on any graphics card without the need for licensing. In the end PhysX screws everyone except NVidia whereas Bullet provides a level playing field that can move the industry forward.
As for the SDK argument, buying an SDK or even the source for an SDK does NOT mean you have the RIGHTS to make a clone of a PATENTED system. Just because you buy the SDK for .NET doesn't mean that you have the rights to create your own API that does exactly what .NET does but does it on OSX then distribute it. If you did so the patent holder (Microsoft) would have legal justification to sue you. Not only that but they would HAVE to sue you to maintain their patent as the US legal system, in their infinite wisdom, has determined that if patent holders don't maintain and defend their patents it's grounds for them losing said patent. PhysX is no different than .NET in this regard. Buying the SDK only gives you tools to develop for the platform, not the RIGHTS to develop your own system to run PhysX or to put PhysX into any driver you haven't been licensed to put it into. If AMD did so, Nvidia would be forced to C&D them and/or sue them otherwise they would risk losing their patent on PhysX.
You can continue to try and argue against the aforementioned facts if you want, your arguments are getting stale though and have been thoroughly debunked by both myself and bean. I, for one, am sick of running around in circles with you pointing out the flaws in the same couple arguments you keep making. Additionally, there are no winners in Internet arguments. Ever. So hows about just leaving it at that and moving on to something we can have a constructive discussion on?
At this point, it's clear to me you're not making the distinction properly between the Software Developer's Kit and the actual product itself. There's no point in continuing this debate until you do a little more research to educate yourself properly in the aspects of software development.
Nah, its obvious you're hiding behind an incorrect interpretation or limitation of what you think an SDK is or should be. You seem to think the inclusion of "SDK" in reference to "Source Code" means its not the actual, fo'real source code and its somehow the fakie Bizarro source code. Got it.
I've already clearly shown simply satisfying the requirements of "SDK" by no means disqualifies an SDK from also including the source code. They're clearly not mutually exclusive, as the Source Code SDK includes the HL source code along with additional software tools to facilitate debugging and integration for whatever target API intended.
But you're right, its probably best to leave it at that until you've updated your frame of reference and better familiarize yourself with the material. Your inability to digest and get past these trivial details and facts makes it pointless to continue.
In any case, if you're interested in better understanding the "basics of software development", you can probably start by posting such a simple inquiry here:
Those guys are actually knowledgeable and mostly friendly, until you repeatedly demonstrate an unwillingness to acknowledge simple facts and realities.....
I glanced over your reply and it seems it focuses on licensing and PhysX's proprietary nature. I haven't ignored any of it, there's undoubtedly some agreements and concessions that need to be made by AMD and its very possible that ship has sailed given AMD's very public criticisms of PhysX in the press. I simply haven't covered them in detail because I already mentioned it in earlier posts:
The gist of those links is that Nvidia has offered to support efforts to get PhysX to run on AMD hardware. But AMD declined for clearly disingenuous reasons and here we are today. Obviously any attempt at porting PhysX to AMD hardware would be accompanied by the appropriate licensing concerns but these obstacles clearly aren't prohibitive given the fact PhysX is fully supported on a wide variety of hardware platforms including all 3 major consoles.
Yes, I don't know what an SDK is. I only have a degree in computer science. Clearly I'm ignorant as to the business of software development. I usually refrain from making the following statement as I generally find that both sides of an argument usually have some merit to them. In this case though I can find none in yours. You're wrong and I have better things to do with my time than to try and point out all the ways in which your arguments are flawed, devoid of facts and proof or just plain bullshit. If lordbean wants to continue trying to point out the errors in your logic to you, more power to him, but I'm through beating my head against the brick wall of ignorance you have built around yourself.
Yes, I don't know what an SDK is. I only have a degree in computer science. Clearly I'm ignorant as to the business of software development.
Thanks for the background info, that doesn't change the fact your unabbreviated definition of the acronym "SDK" is incorrect. It just would've been -2 points or whatever on your way to that CS degree in perhaps Intro to Software Development 100. Not to say it isn't a noble or grandiose aspiration, if we could all hope to create new standards each time we touched an SDK!
he manually edited a binary file? I'd be amazed to see someone actually do that.
Mondi may not post much as of late but he has been around a long time. He is also extremely knowledgeable as well as creative. I have no doubt that he manually edited a binary file. We have had several talented people here who have done such things.
Mondi may not post much as of late but he has been around a long time. He is also extremely knowledgeable as well as creative. I have no doubt that he manually edited a binary file. We have had several talented people here who have done such things.
I'm not questioning his creativeness or how knowledgeable he is. There were some people that I went to college with whom I saw do amazing feats of coding genius which made me question my worth as a human being. I've never seen anyone edit a binary executable by hand though. Forgive me but I'm skeptical that he did this without breaking anything while actually expanding functionality especially on a graphics driver which tends to be in the tens to hundreds of megabyte range. I find it far more believable that he tweaked an inf or ini file to get windows to load the driver properly. inf/ini file != driver.
Comments
In fact, no it does not. Read the slide a little more carefully. The listed prices are for PhysX SDK, not the physX core's source code. In other words, the slide shows that you can get compiled tools to develop on PhysX for free, or you can purchase the source code SDK for $50,000. It does not give the buyer the source code to PhysX itself.
Actually, no, you cannot. Applications developped on DirectX will run on ANY modern hardware. Applications developped on PhysX will ONLY run on nvidia hardware. It's a subtle difference, I know, but it is the defining difference of this point. Also, developing on PhysX is only free if you do not intend to make use of the source code-version SDK. If you do, it's $50,000 to license it.
How do you propose AMD make their hardware compatible with nvidia's proprietary API? You can't install the nvidia driver for use with an AMD graphics card, it doesn't work. Nvidia have even gone so far as to disable their own GPUs from accelerating PhysX if an AMD GPU is even detected in the system. In order to accelerate PhysX, the PhysX application core would need to be written into AMD's drivers. Short of reverse engineering the nvidia drivers (which I'm fairly sure is illegal), they would have to port nvidia's PhysX core, and in order to port something, you need to have the original source code. Nvidia owns the source code to the PhysX core, therefore AMD would have to license it, et cetera. I believe we've gone through this point before.
The whole point of AMD's movement to make physics acceleration an open source matter is not only to promote compability, but also to avoid an extreme amount of time put into a proprietary physics engine for just this reason. With open source standards available, the graphics companies do not have to worry about developing their hardware physics engines - DirectCompute or OpenCL will take care of it through any potential number of physics APIs in the future. Bullet is only the beginning.
I also disagree with your notion that GPU-accelerated physics will be a value-add feature only. I believe that as open-source physics processing solutions become more available, we are going to see a large increase in the number of games released with advanced physics. At the moment, PhysX is still a turn-off to developers for the simple reason that it is still proprietary to nvidia.
A license agreement is a document drafted by licenser to the licensee, to be agreed to by the licensee. In order to license PhysX from nvidia, nvidia can potentially put anything they want to in that document, including reserving the right to break the agreement at any time. If, as you say, all nvidia wants is to further the physics acceleration market with PhysX, then why have they not ported it to DX11 or OpenCL and made the core open source?
Your sarcasm is lost, as it comes from a misinterpretation. Not only does nvidia not sell the PhysX core source code, but even if they did, they would charge more than $50,000 for it. When I said groundbreaking, I meant simply that PhysX has the potential to be a groundbreaking piece of hardware/software cooperation (as seen in the few games that actually do use it), if nvidia would simply get their claws out of its stomach and allow it to become an open source standard.
Microsoft does not make GPUs. The DirectCompute source was built by microsoft, that is true, but it is designed to allow any graphics card with compute shaders to perform tasks other than simple graphics. There's a fine difference between PhysX here. The tools to develop for PhysX are free, but even the source code for those tools is not - nvidia is charging $50,000 for it. As well, PhysX acceleration was specifically written to operate only on nvidia GPUs - point being, AMD does not have a choice here. They cannot support PhysX because they do not have access to the API source code, and nvidia is not going to write a driver that accelerates PhysX on AMD's GPUs just because they can.
No company is perfect. CAL was a flop in terms of performance. I have a GTX 285 in my gaming rig, and I know how many more PPD I get in GPU2 folding than I do in any 4000 series radeon. However, to promote healthy competition in hardware and in the spirit of growing the industry, standards need to be in place, whether they be open source or not. DirectX is an excellent example of a standard which is not open source, and yet also encourages the industry to grow. In this way, DirectX encourages the graphics market to improve, while favoring neither AMD or nvidia, or even Microsoft for that matter.
Any criticism coming from AMD is warranted, until nvidia shows that they are willing to move toward standardizing their APIs without requiring AMD (or other companies) to pay for or license them.
I seem to recall a certain statement about tin-foil hats... this is much further in the future than physics acceleration APIs are.
You don't see anything potentially unsettling for AMD in this scenario? Maybe nvidia really wouldn't use the licensing of PhysX to AMD in a manner that would undermine AMD's efforts, but if you were on AMD's board of directors, would you take that chance? By licensing PhysX from nvidia, they are allowing PhysX to become the standard, and when it does, AMD's GPU production is entirely at nvidia's mercy.
I don't even know where to begin with this paragraph.
If AMD adopts PhysX now, the software developer adoption rate of PhysX to do physics acceleration could very well become a standard, hence the assumption that in 2 years' time, 50% of all new releases would use the PhysX library. AMD's graphics cards could have the rendering power of god himself, but if they can't do PhysX, they're sunk.
They can't break the license agreement with nvidia, and then patch PhysX support in afterward. That would quite literally be breaking the law. They signed an agreement, broke it, and then continued to implement a proprietary standard anyway? Nvidia would sue them so fast you wouldn't even know what happened.
Provided they're running the same API, the faster hardware wins?
You just summed up why PhysX is hurting customers. AMD can't run the same API unless nvidia licenses the PhysX source code to them, or nvidia actually writes a PhysX API for AMD's GPUs themselves. Either way, AMD loses.
I never said anywhere that PhysX or CUDA should be outright abolished. What I said is that the release of vendor-neutral tools makes proprietary APIs obsolete. If nvidia were to port PhysX to OpenCL, then there is no problem whatsoever, as the APIs are then no longer proprietary. AMD could support it without licensing it, and everything moves forward as normal. Unfortunately, that is exactly what nvidia is not doing - they are continuing to develop PhysX as a proprietary standard.
You seem to be referring to PhysX as though it is a standard. AMD can't write a driver for an API they don't have access to. Your "important point" is, in fact, gibberish in this regard.
You just conceded to my argument with this paragraph. AMD would need nvidia's help to write a driver for PhysX, meaning, they need to license the PhysX core in order to understand exactly how it works in order to reproduce it on their hardware.
Sony had to license PhysX from nvidia to put it in the PS3. They couldn't simply write a driver for it and say "oh look, we have hardware PhysX acceleration!" Why do you think it's going to be any different for AMD?
The only way the technology becomes supported by more hardware at present is when other companies license the tech from nvidia. In order to support it, AMD would have to do the same thing, and I think you know where this train of thought is going.
Where did I ask why nvidia chose to develop CUDA? I only pondered why instead of allowing PhysX to be open source to promote growth, they kept it proprietary and only accelerated by their own GPUs unless another company chose to request to license it. I also said nothing about porting PhysX or CUDA to OpenCL immediately after they acquired the PhysX technology. The point I was (and am) making is that now that the free standards are available in the forms of DirectX 11 and OpenCL, nvidia is still keeping their technology proprietary, and getting other companies to license it from them.
Nvidia does not hold all the cards, and that is precisely why they are holding onto PhysX as tightly as they can (and going against the open source initiative in doing so). They may be assisting in the development of OpenCL, but they are also devoting most of their resources to the furthering of PhysX, even when there are vendor-neutral APIs available.
Consider also how delayed their GT300 is going to be behind the Radeon 5000 series. I believe the motivating factor behind nvidia not wanting to port PhysX to a vendor-neutral API is that nvidia's R&D screwed up and are way behind AMD. They are therefore looking for as many ways to stall AMD's sales as they can.
If you bothered to actually read my points, you'd learn why.
We're discussing the ramifications of PhysX acceleration in the near to medium future, and you're calling your points "fact"? It hasn't happened yet, therefore everything by both you and I is opinion. You're entitled to your opinion, but please, don't try to push it as fact. That's frankly an insult to my intelligence.
The big thing I'm seeing here that you don't seem to understand is what an SDK is. SDK stands for Standard Development Kit. It is a set of tools used to develop software for a platform. The PhysX SDK is for game developers to develop and compile code that will run on PhysX compatible cards. Of course Nvidia is going to make that available, if they don't no game manufacturers can actually utilize the technology. The thing is though, the SDK does not in any way shape or form allow AMD to develop a card that will run PhysX. PhysX is more than just software, it's also in the hardware. Could AMD reverse engineer it and make their own cards compatible? Probably, yes. However that would open them up to a whole host of legal issues and Nvidia would sue them to death, thus their only option would be to license the rights to produce PhysX hardware from Nvidia. This would make it so that, as bean has rightly stated many times before, Nvidia would be able to inspect AMD hardware before release, potentially delay the release of AMD hardware and refuse to renew the license at any time thus screwing AMD if PhysX ever became dominant in games. For AMD to put their product in a position of being reliant on their main competitor would be a very stupid business move and the only people it would benefit would be Nvidia itself as they would essentially have control of all future AMD products.
Just in case you weren't sure which slide I was referring to and the relevant portions I went ahead and highlighted them for you.....
http://rz3ovw.bay.livefilestore.com/y1pGf-TVoa3yRsHCFlp_GMGHVRUh17FnDNcFAYG0IRRc4-9M57F-OmES0ze7C76oy7-GspbYmZld03vyOu6Tj4U0nXfVLhnz_hN/PhysX%20pricing.jpg
That slide is directly from Nvidia, but if you google the exact paramaters I stated "PhysX Source $50" and see what other hits you get. You'll find many more from interested parties who either know from experience or inquiry that the SDK source code costs $50K.
As for semantics, there is a compiled Binary SDK with GUI tools that is free to use, and there is the source code SDK (includes compiler, debugger, whatever else) that costs $50K. There isn't some extra super sekret handshake SDK, that's all there is lol.
Anyways, until we can get by this hurdle there's really no reason for me to continue arguing with you. As I stated in my last reply, debating with someone who clearly isn't familiar with the material and is unwilling to acknowledge simple facts is about as gratifying as banging your head against the wall lol. :banghead:
On that very page you linked, the acronym "SDK" appears so many times, I simply cannot put polite words to this. If you haven't noticed that that slide is giving information on the PhysX SDK (not PhysX itself), then I simply don't know what more I can tell you. You're convinced of all your arguments based on a false belief which you are refusing to acknowledge even though I and Ardichoke have both pointed it out.
That is exactly the point we are making - an SDK is simply software to facilitate making more software. It is not the source code to the PhysX engine itself. This means that other companies cannot purchase the PhysX core in order to port it or tinker with it.
Your argument is in conflict with itself. I suggest you re-read Ardichoke's post describing what an SDK is and is not - it might clarify some things for you.
I'm doing my best to be nothing but.
Wrong again, the source code SDK isn't just the HL source code, it also includes additional software tools to facilitate debug and compile, which again, satisfies the requirements of an SDK by the correct definition.....
Chizow, you sound like you are defending the definition of an SDK, is that the case? Everybody seems to know that definition, I don't think that is in question.
What is on debate is this.. Can AMD use that to make PhysX run on their cards? Answer is no.
This was the crux of your argument against AMD. You said they could purchase the source code to PhysX itself for $50,000 and then make their hardware accelerate it using the code. I believe I have shown that the source code to the PhysX core is, in fact, not available for sale from nvidia. I never contested that the SDK is there:
As for whether AMD can use it to make PhysX run on their cards, again, they wouldn't have to, the API is there, the binaries are there, they would just need to write a driver for their own hardware to interface the API. This is no different than them writing a driver for OpenCL or DirectCompute.
And I've shown time and again you're clearly wrong, the source code is available for purchase. Why you continue to cling to this bit of misinformation is beyond me.
http://rz3ovw.bay.livefilestore.com/y1pGf-TVoa3yRsHCFlp_GMGHVRUh17FnDNcFAYG0IRRc4-9M57F-OmES0ze7C76oy7-GspbYmZld03vyOu6Tj4U0nXfVLhnz_hN/PhysX%20pricing.jpg
The only reason you would need it is if you wanted to port or compile to a different target API or hardware. But AMD wouldn't even need to go that far unless they wanted to port PhysX to OpenCL or DirectCompute for their own hardware, all they would have to do to circumvent those steps is to write a CUDA driver for their own hardware. Yes it might involve help from Nvidia or the aid of an additional SDK, but it'd be CUDA's SDK, which again brings me back to the point the emphasis on PhysX's source is irrelevant to begin with.
It doesn't matter which source code AMD would need from nvidia, the point here is that they can't simply write a PhysX driver without having at least some of nvidia's proprietary code. AMD would need to license it from nvidia, which would make them responsible to nvidia for all future products they make which accelerate PhysX. This isn't a position AMD wants to be in, which is a point I've made again and again.
1) Use the existing PhysX binaries, runtimes and API (CUDA) that are already in place on the PC and just write their own CUDA driver for their hardware. As Dave Hoff said, porting runtimes and drivers between the API in question, DC, OpenCL, CUDA, is "trivial" given how similar they are. Given their minimalistic approach, this would make the most sense, IF they wanted to support PhysX of course.
2) Use the PhysX source code SDK and whatever API SDK of their choosing (OpenCL, DirectCompute, CAL lol) to port and compile PhysX for that API and their own hardware. This is no different than the process used to port PhysX from the PC to the 360, PS3, Wii, iPhone...and of course GeForce GPUs.... In this case, any licensing concerns would be agreed upon according to the licensing agreement and AMD would be in control of their own PhysX implementation.
Both are viable paths that would work from different ends of the problem to come to a similar resolution, but obviously it takes a willing party to get there. But as we all know, AMD would rather feed the press with disingenuous reasons for why they won't support PhysX while leaving their customers to fend for themselves with hacks and workarounds.
Dave Hoff has pointed out that it would be easy for nvidia to port their existing APIs to OpenCL. AMD cannot just do it on their own, as they do not have access to the PhysX or CUDA source codes.
The PhysX source code SDK is not the same thing as the source code to the PhysX core. The source code SDK is, simply put, the developer tools for PhysX, in pre-compiled form, to allow portability to any developing environment. It does not contain any usable code toward porting PhysX itself to other hardware.
In fact, neither way is viable because in either scenario, nvidia needs to port it themselves or give AMD their source code. This would require that they either make their sources open, or license it to AMD. The latter is not desirable to AMD, which is why they currently don't support PhysX.
LMAO, I see the problem here. You're inventing some additional abstraction layer in your mind. As the slide I linked clearly stated and as I've repeated numerous times, the PhysX Source Code SDK includes the High-Level source code which is written in any one of the prevailing high-level programming languages in use today, most commonly C or some derivative.
This code is then compiled to output in binary, which is then translated into machine code by the driver for target hardware. There is no additional step, there's the compiled free PhysX SDK binaries and there's the $50K PhysX Source Code SDK that includes the HL source code and debugging tools and software. That's it, there's no super sekret Nvidia martian source code language covered in green anti-AMD kryptonite.....
http://rz3ovw.bay.livefilestore.com/y1pGf-TVoa3yRsHCFlp_GMGHVRUh17FnDNcFAYG0IRRc4-9M57F-OmES0ze7C76oy7-GspbYmZld03vyOu6Tj4U0nXfVLhnz_hN/PhysX%20pricing.jpg
Nvidia really doesn't need to do either, at some point AMD needs to be responsible for support of their own hardware. I've outline the two ways they could make it happen. The impetus isn't on Nvidia, they've created a value-add feature on their hardware and fully support it free of charge.
At this point, it's clear to me you're not making the distinction properly between the Software Developer's Kit and the actual product itself. There's no point in continuing this debate until you do a little more research to educate yourself properly in the aspects of software development.
You're making the same debunked arguments over and over again going round and round in circles. AMD cannot just up and use PhysX because Nvidia owns the patent on it and would sue them into the dirt if they did. You seem to not understand how patents work. The basis of this whole thing boils down to this one simple FACT.
PhysX is a patented middleware program to simulate Physics. The key word there being patented. This means that to even make a compatible clone of it, AMD has to LICENSE THE RIGHTS TO DO SO from the owner, aka NVidia. This would mean that Nvidia could exert power over AMDs products and drivers in that they could refuse to license them, they could slow down their releases by requiring they inspect all new cards or drivers before release or they could do a number of other things to screw AMD over using the license for their proprietary, patented technology. That would be a monumentally stupid business decision on AMDs part whereas developing an open source physics API, while it won't allow them to put a stranglehold on the market like a proprietary API would, will advance physics acceleration on any graphics card without the need for licensing. In the end PhysX screws everyone except NVidia whereas Bullet provides a level playing field that can move the industry forward.
As for the SDK argument, buying an SDK or even the source for an SDK does NOT mean you have the RIGHTS to make a clone of a PATENTED system. Just because you buy the SDK for .NET doesn't mean that you have the rights to create your own API that does exactly what .NET does but does it on OSX then distribute it. If you did so the patent holder (Microsoft) would have legal justification to sue you. Not only that but they would HAVE to sue you to maintain their patent as the US legal system, in their infinite wisdom, has determined that if patent holders don't maintain and defend their patents it's grounds for them losing said patent. PhysX is no different than .NET in this regard. Buying the SDK only gives you tools to develop for the platform, not the RIGHTS to develop your own system to run PhysX or to put PhysX into any driver you haven't been licensed to put it into. If AMD did so, Nvidia would be forced to C&D them and/or sue them otherwise they would risk losing their patent on PhysX.
You can continue to try and argue against the aforementioned facts if you want, your arguments are getting stale though and have been thoroughly debunked by both myself and bean. I, for one, am sick of running around in circles with you pointing out the flaws in the same couple arguments you keep making. Additionally, there are no winners in Internet arguments. Ever. So hows about just leaving it at that and moving on to something we can have a constructive discussion on?
I've already clearly shown simply satisfying the requirements of "SDK" by no means disqualifies an SDK from also including the source code. They're clearly not mutually exclusive, as the Source Code SDK includes the HL source code along with additional software tools to facilitate debugging and integration for whatever target API intended.
But you're right, its probably best to leave it at that until you've updated your frame of reference and better familiarize yourself with the material. Your inability to digest and get past these trivial details and facts makes it pointless to continue.
In any case, if you're interested in better understanding the "basics of software development", you can probably start by posting such a simple inquiry here:
http://www.gamedev.net/community/forums/forum.asp?forum_id=31
Those guys are actually knowledgeable and mostly friendly, until you repeatedly demonstrate an unwillingness to acknowledge simple facts and realities.....
I glanced over your reply and it seems it focuses on licensing and PhysX's proprietary nature. I haven't ignored any of it, there's undoubtedly some agreements and concessions that need to be made by AMD and its very possible that ship has sailed given AMD's very public criticisms of PhysX in the press. I simply haven't covered them in detail because I already mentioned it in earlier posts:
http://www.bit-tech.net/news/hardware/2008/12/11/amd-exec-says-physx-will-die/1
http://www.tgdaily.com/content/view/38392/118/
http://www.extremetech.com/article2/0,2845,2324555,00.asp
http://www.bit-tech.net/custompc/news/602205/nvidia-offers-physx-support-to-amd--ati.html
The gist of those links is that Nvidia has offered to support efforts to get PhysX to run on AMD hardware. But AMD declined for clearly disingenuous reasons and here we are today. Obviously any attempt at porting PhysX to AMD hardware would be accompanied by the appropriate licensing concerns but these obstacles clearly aren't prohibitive given the fact PhysX is fully supported on a wide variety of hardware platforms including all 3 major consoles.
This is like a novel.
mondi once manually edited my video driver to fix the support for my obscure motherboard.
Mondi may not post much as of late but he has been around a long time. He is also extremely knowledgeable as well as creative. I have no doubt that he manually edited a binary file. We have had several talented people here who have done such things.