Issues with CUDA

[Scali2]

You don't know ANYTHING about how it will perform, no one does, so stop acting like an 8400GS isn't going to cut it. The amount of vector calculus that goes into processing something like specular lighting alone is a monstrous amount of mathematics; there is no way even the most complicated of dynamic physical systems could have as much math as graphical processing. Think about how little information needs to be processed: particle shape, mass, x/y/z acceleration, x/y/z velocity. Now take that versus something like applying specular lighting, one of MANY special effects, to the graphics:
http://en.wikipedia.org/wiki/Specular_highlight
Yeah, draw your own conclusions.

The main problem with physics is that in theory 'everything affects everything'.
You have this recursive chain of events. You solve the acceleration/velocity of one object, and then that results in a new force that is affecting all touching objects.
So the main challenge is to forward the results from one body to the next...
The PhysX PPU was designed more or less like a network switch, where packets with results could quickly be transferred to other processing elements. People who judge the PPU by its MFLOPS rating are sorely missing the point.
CPUs are weak at physics because they have a very low number of concurrent threads. They will have to process the physics system mostly in a linear fashion, iterating the results over and over again, until the system is assumed to be in a converged state.

Now, Cuda actually fits this bill nicely, because the Parallel Data Cache will allow results to quickly be forwarded to other threads, giving an effect similar to the PhysX PPU. So the whole idea of doing physics with Cuda makes a lot of sense (even with as little as 16 to 32 shaders at a time... I believe the PPU only had about 20 processing units aswell).
ATi's GPUs don't seem to be that lucky.

 

[AnnoyedDragon]

Know what, I actually have work to do. I don’t have the time to argue about this but I keep getting sucked in, because if I don’t reply you will automatically assume the contents of your last response must have been correct. Because that is what it is all about isn’t it? Assumptions. Making claims and disproving them based on ‘assumptions’. You want to believe an 8400GS with only 16 shader units will offer better performance than current CPUs? Fine, go look at the CUDA physics tech demos I posted elsewhere in this forum and come to your own conclusions. See what 128 unified shaders can do on a high end card then think what 16 on a budget card can achieve.

The sheer number of times I have repeated myself only to receive the response “I don’t care about politics” shows no amount of repetition is going to help, we’re not seeing the situation in the same way. I have to drop out of this to get some work done, I’m running the risk of everyone making the assumption I am saying this to avoid answering questions but what can you do? I’ll be here all week if I don’t put a stop to it now.

I sincerely hope the future of CUDA is as rose coloured as you make it out to be, because if I’m right it isn’t going to make the splash in game play physics that most people are hoping.

 

[pxc]

People who judge the PPU by its MFLOPS rating are sorely missing the point.

Not really. Rigid body collisions and fluid dynamics systems are solvable by sets of equations, a very math heavy task. That's why it's not a CPU's strong point with usually just a single general SIMD execution unit per core. While the GFLOPS rating doesn't tell you exactly how fast it can solve particular cases, it gives a rough estimation of the horsepower behind the chip's SIMD engine/execution units.

As the G7x shows, there are factors that made it a poor GPGPU performer. That's an exception though.

It would be nice to see some apples to apples comparisons besides the gimped demos Ageia made to showcase the PhysX PPU. I posted in another thread here how the software PhysX library doesn't even use more than 50% of each core (with neither core close to pegged) on a dual core CPU duing heavy collision effects in Cell Factor, even in low resolution with graphics quality turned down. PhysX on the PC was obviously optimized more for the PPU.

 

[Scali2]

You want to believe an 8400GS with only 16 shader units will offer better performance than current CPUs? Fine, go look at the CUDA physics tech demos I posted elsewhere in this forum and come to your own conclusions.

Where did you post them, and what kind of tech demos are we talking about?
Anyway, the point of hardware acceleration is not always that the hardware is faster, but rather that the CPU is freed and available for other duties.
This is especially important in games, where physics isn't the only thing the CPU has to do.

The sheer number of times I have repeated myself only to receive the response “I don’t care about politics” shows no amount of repetition is going to help, we’re not seeing the situation in the same way.

Wow, you figured that out already? Geez, you're slow.
You might want to work a bit on your attitude. It seems that in your view of the world it isn't possible that someone else has a different opinion, and may actually have put a lot of thought in that opinion, and has valid reasons and arguments to back it up.

I sincerely hope the future of CUDA is as rose coloured as you make it out to be, because if I’m right it isn’t going to make the splash in game play physics that most people are hoping.

You still don't seem to get that I never said anything about the success Cuda and/or PhysX may or may not have on the market, but rather that I support nVidia enabling this technology for us. That's why I'm a tech guy, and you're not. You're more concerned with politics. Reminds me of all those linux/opensource zealots. They care more about politics, licenses and utopia than reality and technology aswell.
I've actually went into detail on various aspects of the technology various times (take my previous post for example), but you just ignore all that stuff altogether. Clearly you don't want to discuss technology. In fact, you probably can't even discuss the technology, because you don't have a good grasp of it yourself. You're just here whining about ATi all the time. Who cares about ATi? They don't have this technology, end of story.

 

[Scali2]

Not really. Rigid body collisions and fluid dynamics systems are solvable by sets of equations, a very math heavy task.

It's all relative. As pointed out earlier in this thread... The equations and amount of data processed for T&L are far larger than that of the average workload for physics.
Compared to T&L, physics actually consists of pretty simple equations. You represent rigid bodies with simple geometry like boxes and spheres, instead of using a full mesh (and use local refinement to parts of the mesh, if you want to get a triangle-perfect solution).

That's why it's not a CPU's strong point with usually just a single general SIMD execution unit per core. While the GFLOPS rating doesn't tell you exactly how fast it can solve particular cases, it gives a rough estimation of the horsepower behind the chip's SIMD engine/execution units.

Not entirely true.
A quadcore CPU actually has a reasonably high GFLOPS rating, but it's poor in physics because it cannot exploit its parallelism where it matters. A CPU gets its GLOPS mostly because of its high clockspeed and efficient SIMD units. So because of its linear speed more than its parallel speed.
Physics is a highly parallel problem... as I already tried to explain, your forces 'cascade' from one body to the next. Calculating the individual forces isn't that big of a deal, but doing them in parallel requires many SIMD units and an infrastructure that will quickly give them the correct input. The problem with a CPU is that it has to store results to memory, and read them back later, this severely limits the performance of the SIMD units. If they could run everything from L1-cache, they'd be many times faster.
That's where the PPU gets its performance from. The raw MFLOPS aren't very impressive compared to a modern CPU, and especially not compared to a GPU. But still it's the fastest physics solution we have. Wasn't that a tyre company's ad slogan? "Power is nothing without control".

As the G7x shows, there are factors that made it a poor GPGPU performer. That's an exception though.

Not sure what you're trying to say with that.
G7x doesn't have the parallel data cache, it's not designed to do any kind of GPGPU operations. GF8 and Cuda are the first of its kind.

It would be nice to see some apples to apples comparisons besides the gimped demos Ageia made to showcase the PhysX PPU. I posted in another thread here how the software PhysX library doesn't even use more than 50% of each core (with neither core close to pegged) on a dual core CPU duing heavy collision effects in Cell Factor, even in low resolution with graphics quality turned down. PhysX on the PC was obviously optimized more for the PPU.

This is nonsense. The CPU portion of the PhysX library wasn't even written by Ageia. Ageia simply acquired NovodeX when they developed their PPU, so they had an API for it (same as what Intel and nVidia are doing now. They have the hardware for physics, they just need an API). NovodeX was already a highly optimized physics library for multicore CPUs and consoles. I've used it myself at the time, and I can vouch that it hasn't been artificially limited on CPUs since being acquired by Ageia and adding PPU support. In fact, I may actually have a copy of an old NovodeX SDK somewhere, so you can compare the demos, most of them are the same.
Thing is that it's not that easy to get a multithreaded system efficient. Again, as I say, getting the input to the right cores at the right time is the problem. Even my own multithreaded code doesn't use all cores near 100%, simply because the calls to D3D screw that up. If I don't render anything, then I can get 100%.
If you could get a chart of PPU or GPU load, you'd see that its units weren't filled anywhere near 100% either. So it's not as simple as you think. PhysX is fair, believe me.

 

[bassman]

From the Nvidia forum on CUDA.

Ask the people using CUDA just how well that works.

If a GPU is used for emulation, it becomes a physics engine. It cannot be used for both at the same time. At best, you must switch in and out of "modes" while operating.

Take the GPU into physics, and you drop the SLI capability as well.

That's why the more successful CUDA programmers go for either a stand-alone engine like Tesla or a second graphics card. GeForce owners testing the CUDA waters are finding this out the hard way.

Where exactly is this quote from, Dragon? It's completely untrue.

If a GPU is used for emulation, it becomes a physics engine. It cannot be used for both at the same time.

CUDA and graphics processing runs just fine on one card. Run the particles or fluidsGL samples from the CUDA SDK if you don't believe me.

Take the GPU into physics, and you drop the SLI capability as well.

Enabling SLI "fuses" the GPUs at a low level in the driver, so CUDA applications only see one GPU. SLI doesn't prevent CUDA, and CUDA doesn't prevent SLI.

That's why the more successful CUDA programmers go for either a stand-alone engine like Tesla or a second graphics card. GeForce owners testing the CUDA waters are finding this out the hard way.

There are a few reasons CUDA developers are using a non-CUDA card for video, and none of them have to do with what's listed in your quote.
1) CUDA kernels running under Windows on a display adapter must complete within 5 seconds due to a watchdog in the GDI. 5 continuous seconds is a helluvalot of GPU computation; I doubt any forseeable game physics would use more than tens or hundreds of milliseconds at a time.
2) Cards used as display adapters use up a chunk of GPU memory for the display, and GPU memory is a very valuable resource for big computational problems. Game physics is NOT a big computational problem.

I use Tesla because the Tesla cards have 1.5GB of memory - not because you think I can't run video and CUDA at the same time. Again, CUDA and OpenGL (or DX) work just fine together. The CUDA toolkit even provides methods for passing data between CUDA and OpenGL/DX.

In other words it is possible that graphics and CUDA cannot be share on the same GPU, I have yet to get a solid confirmation on this. Nvidia says it can be done

You just got your solid confirmation. Stop spreading fud.

but then again they also said they were bringing CUDA to consoles…

Where did they say this?

 

[Scali2]

It's pretty quiet all of a sudden...

 

[silent-circuit]

It's pretty quiet all of a sudden...

So let it die. The whole thread was started due to misinformation and FUD spread by morons at another forum. Hopefully it's been dealt with.