Difference between CUDA, PhysX and Compute Shader?
Members - Reputation: 978
Posted 22 November 2012 - 05:19 PM
What is the difference between CUDA, PhysX and Compute Shader? In my mind I think of them as three different things, but then again it is propably 3 ways of running code on the same hardware, right? What I got so far is that CUDA and PhysX are products of nVidia. Compute Shader is a DirectX standard implemented on newer GPUs.
I got the CUDA basics down, kernel, mem allocations, copy array back and forth etc... Is PhysX then a wrapper ontop of CUDA? And how does the compute shader fit in to this?
Someone set me straight please ;) small pseudo code is much appreciated!
Crossbones+ - Reputation: 2773
Posted 22 November 2012 - 05:28 PM
PhysX is a physics engine developed originally by ageia and later acquired and maintained by nvidia and doesn't really have anything to do with GPGPU technologies. There is however an implementation of PhysX which can be run on the GPU with the use of CUDA, but this of course only works on nvidia cards.
Edited by Radikalizm, 22 November 2012 - 05:29 PM.
Crossbones+ - Reputation: 8165
Posted 22 November 2012 - 09:30 PM
The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.
- Pessimal Algorithms and Simplexity Analysis
Moderators - Reputation: 27690
Posted 23 November 2012 - 03:34 AM
Games Middlware/Engines APIs Drivers HardwareCUDA, D3D/DirectCompute and OpenCL are all "GPGPU" APIs that communicate with the drivers. Whatever happens on the other side of the driver is irrelevant, but yes, they all make use of the same hardware.
Crossbones+ - Reputation: 4515
Posted 23 November 2012 - 06:21 AM
No, and yes. They generally both run on the same kind of hardware in your computer, the GPU. But that is only half of the truth.
So CUDA and Compute Shader are two different things (hardware)? But both are GPGPU technologies?
CUDA ("Compute Unified Device Architecture") is not really a GPU API. It is vNidia's API/architecture for running compute tasks (whatever they are) on nVidia devices (whatever they are). This includes GPUs, but it also includes e.g. non-GPU Tesla racks. CUDA is also the backbone of OpenCL on nVidia cards (OpenCL on nVidia is secretly transformed into CUDA by the compiler) much like Cg is the backbone for OpenGL shaders on nVidia.
OpenGL 4 compute shader functionality and its DirectX counterpart are likely also secretly transformed into CUDA on nVidia systems. This is not documented anywhere, but it's my bet that this is just what happens (it's at least plausible). These are a vendor-independent compute task (not graphics!) API built into the DirectX and OpenGL graphics APIs. They are not required to, but factually use the same hardware (shader units in the GPU) as the graphics pipeline.
That's true, it uses the exact same shader units on the same GPU(s), just with a different API and language (though in reality it's still a bit more complicated, as the driver config panel lets you dedicate GPUs for graphics and for compute tasks, so if you have more than one card and dedicate one to compute tasks, it may be "generally the same" but "factually different ones").
Maybe CUDA uses the same SMs as Compute Shader but it is approched differently in software?
OpenCL (first mentioned by Bacterius above) is a different beast insofar as it has a greatly different design philosophy. Incidentially, it runs on the GPU on your computer too, but that is not necessarily so.
OpenCL is a framework for running compute tasks on "some hardware". It is not exactly specified what that hardware is, or even whether it is homogenous. For example, it is in principle entirely allowable to have tasks run on the CPU, the GPU, or a special "accelerator card". Or, a combination of these, all at the same time.
So much for the theory. In practice, OpenCL runs on your graphics card if you have a nVidia or AMD/ATI graphics card in your computer, and on the CPU otherwise, if you're lucky (or, not at all). And if you want to share objects (e.g. images) between OpenCL and OpenGL without doing an explicit round-trip, you must create the CL context from a valid GL context, which necessarily means they run on the same GPU.
AMD has released a SSE-accelerated CPU implementation of OpenCL as part of their computing SDK some years ago, and Intel has been talking about it, though I've never seen it being real (did they release something in the mean time?). Those are in any case not normally present on an end-user computer, though.
PhysX, as already explained above, is a totally different thing. As the name gives away, it does "physics" (such as simulating rigid bodies), it does not do "general computation". Insofar it is something that's much more "high level".
Edited by samoth, 23 November 2012 - 06:29 AM.
Members - Reputation: 978
Posted 23 November 2012 - 06:44 AM
I get the feeling Compute Shader is just a wrapper for all GPGPU technologies.....
So there is no point in learning CUDA for game programming? CUDA is hardware specific and excludes users with ATI/Intel hardware?
In layer term:
Compute Shader <- Higher level API
CUDA <- Lower level API
Crossbones+ - Reputation: 4515
Posted 23 November 2012 - 07:09 AM
If you want to crunch numbers and don't want to depend on one vendor, use OpenCL.
If you just want to add "some special calculation and simulation" to your graphics and you make DX11 hardware a minimum spec, you're good with using compute shader. Otherwise, use OpenCL, which works fine (with 99% of its features) on DX10 class hardware.
Or, just do the calculations in the vertex/pixel shader, if the structure of the data and the nature of the calculations allows for it. For most people, most of the time, that's just good enough, and it's the least painful.
If you just want to write a "game with some physics", you probably want to use an already functioning and tested physics engine, preferrably one that doesn't run on only one specific hardware vendor. Bullet is an example of such a thing.
Really, if this is your goal, use something that already works. It's by no means a trivial task to write your own physics engine.
Edited by samoth, 23 November 2012 - 07:11 AM.
Members - Reputation: 1058
Posted 24 November 2012 - 01:26 PM
PhysX is just NVidias physics engine. Usually it is run on the CPU unless a CUDA capable product is present (NVidia GPU's, Aeigx PPU's [later manufactured by NVidia] and the NVidia Tesla lineup). The bullet physics library can also do this with both CUDA products and OpenCL products (Again, all NVidia products with CUDA are supported under OpenCL although I think bullet puts priority on CUDA on NVidia hardware).
CUDA and OpenCL themselves are just libraries for running parallel code and maths. It just happens to be that a graphics card is the perfect environment for this although there are other options (physics processors, rare now but they are also perfect, thats just one alternate). OpenCL can run on a much broader range of hardware than CUDA but CUDA can be faster (some things OpenCL still manages to do quicker though). OpenCL can also software emulate most of the functionality it would use a GPU for but I dont think its advisable to do so.
Compute shaders I don't know much about but I believe they are just used for programming extra graphics effects in.