Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    27
  • comments
    25
  • views
    6433

GPUPhysics: Finally got design document done

Sign in to follow this  
fortia

113 views

As I wrote yesterday, the design image for GPUPhysics was to be accompanied by a "design document" describing the different stages. Well, it's out there now (here). It's rather long, about 9 pages, but if anyone is interested, it's there... Updated the image as well.

Going to continue the framework implementation now.
Sign in to follow this  


2 Comments


Recommended Comments

Okay, so I'm a complete noob with using shaders and such - but my primary concern with something like this is as follows:

The GPU (in my applications, at least) is generally busy hammering away at graphical stuff. So - would it not bottleneck with the physics too? Though I guess if you're doing everything in the shaders you're not moving much of anything over from the CPU, so that bottleneck is gone.

That said, I can see the obvious advantages the GPU has over the CPU, being designed to be a floating-point cruncher.

I guess I don't have a question that you can answer - but like - rah. I don't know.

This post is now about a randomly chosen picture from my photobucket -



PICTURE RELATED.

Share this comment


Link to comment
Thanks for your comment, I've been waiting for someone to post something [smile].

Nice picture there! Was it inspired by the fact that I use my cat as my avatar [lol]?

>The GPU (in my applications, at least) is generally busy hammering away at
>graphical stuff. So - would it not bottleneck with the physics too? Though I
>guess if you're doing everything in the shaders you're not moving much of
>anything over from the CPU, so that bottleneck is gone.

>That said, I can see the obvious advantages the GPU has over the CPU, being
>designed to be a floating-point cruncher.

Here's how I think: Today many applications are limited in CPU power and not in GPU power. Also, as you say, it's a common bottleneck with transferring data and communicating with the driver (through an API such as DirectX or OpenGL). Besides the high floating-point precision in the GPU there is also the advantage that many shaders are run in parallell, and if you make use of this the right way you should be able to do the physics many times faster on the GPU then on the CPU. In fact, it's only about rendering 2-3 about 64x64 big quads (which enables you to process 64x64=4096 objects) on the screen using the physics shaders. You could process larger quads, which would allow a higher number of objects, but either way it's not much. And it leaves the CPU free to deal with other things like AI.

But of course, it all depends on your application and a little on how you organize your rendering engine. Some appz may not be suited for it.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!