Bullet on GPU

User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Re: DONE!!

Post by SteveBaker » Wed Sep 13, 2006 7:51 pm

Erwin Coumans wrote: With respect to multi-platform building, I can recommend adding CMake support, which I also do in Bullet. It automatically recognizes/finds Glut on Linux/Apple/Unix. Win32 glut lib is included with Bullet sources. CMake can autogenerate Makefiles, projectfiles (Xcode,KDevelop,MSVC) etc etc. You can still include manual makefiles obvious, having CMakeList.txt and Makefile is fine. In fact, in Bullet I ship with jamfiles too, to provide some choice ;-)
I'm not really in favor of any of those things - simply because the de-facto standard is the 'autotools' route. It's certainly not as nice for the developer/maintainer of the package - but for the end user, having anything other than this is a real pain.

I have a pretty well-stuffed Linux box with 100% of SuSE-professional's applications installed on it. When I grabbed Bullet, I couldn't build it because I didn't have Jam. So I had to download it, install that and THEN get Bullet compiled & installed. Adding extra steps like that is *DEATH* to OpenSourced games and such. I'm a passionate minimiser-of-end-user-dependencies - so I'll fight with automake/autoconfig just because 100% of people have it already.

However, I don't plan to release what I have as a separate package. When (if!) we all like it, it should be subsumed into Bullet and should therefore build with whatever Bullet uses (even though I disagree with that!).

Incidentally: Redistributing modified versions of GLUT is contrary to it's license terms - so nobody can fix bugs in it, etc. You might want to use 'freeglut' instead which uses an Xfree-style license that's almost identical to the Zlib license. freeglut is one of my projects - so I'm biassed - but right now, it's more stable than real GLUT and it has vastly better licensing terms. It's 100% GLUT compatible - so it's an easy change.

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: DONE!!

Post by Erwin Coumans » Wed Sep 13, 2006 8:13 pm

A cool, didn't realize you are developer / maintainer of freeglut !
http://freeglut.sourceforge.net/
SteveBaker wrote: When I grabbed Bullet, I couldn't build it because I didn't have Jam.
Are you sure? When you download Bullet it comes with Jam in subfolder jam-2.5. It includes a makefile.
I'll fight with automake/autoconfig just because 100% of people have it already.
I want to serve Unix/Linux users, but without ignoring Windows and Mac users. That's why I distribute autogenerated MSVC 6,7,8 Visual Studio projectfiles, and Mac/Unix users can create Xcode / KDevelop projectfiles just by installing Cmake. Cmake also autogenerates makefiles. jam is an alternative.
However, I don't plan to release what I have as a separate package. When (if!) we all like it, it should be subsumed into Bullet and should therefore build with whatever Bullet uses (even though I disagree with that!).
Anyway, let's not get passionate about buildsystems now ;-) I will leave the autotools/makefile, and just add cmake support, should keep both happy ;-)

I just got Windows version running, same problems as Mac.
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
and

Code: Select all

Compiling:CollisionGenerator Frag Shader -
(1) : warning C7011: implicit cast from "int" to "float"

Linking:CollisionGenerator -
Fragment info
-------------
(1) : warning C7011: implicit cast from "int" to "float"
I just changed the comparison, and another minor platform-incompatibility, and now it runs, but give this error:

Code: Select all

C:\develop\bullet_gpu\GPUphysics>GPUphysics.exe
OpenGL Error: invalid operation
Linking:CubeShader -
Vertex info
-----------
(39) : warning C7504: OpenGL does not allow writing to input variable 'gl_Vertex
'

OpenGL Error: (null)
OpenGL Error: (null)
OpenGL Error: (null)
Hope this helps.

Bullet ships with an unmodified GLUT for windows. So developers on most platforms should be able to compile out-of-the-box without any manual re-configution. Linux / Mac already have glut. As the project focusses on physics, I wasn't intending to start modifying glut, but if the GPU work requires it, we can switch to freeglut.

Thanks again!
Erwin

User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker » Wed Sep 13, 2006 10:14 pm

Version 0.1 of the GPUphysics demo is on my website:

http://www.sjbaker.org/tmp/GPUphysics-0.1.tgz

...fixed a couple of problems with stencil buffer support, also a boo-boo in one of the shaders.

Does *NOT* include the Mac fixes...that's coming ASAP.

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans » Wed Sep 13, 2006 10:38 pm

Thanks Steven!

I tried running your new version under both Windows and Mac.

Under windows, NVidia 6800 latest drivers, now it runs without reporting an error, but with just a grey screen. Under mac it reports an error. I have no idea about GPU's, is a vertex shader sampler absolutely necessary? ;-) The Macbook has none it reports. I haven't tried upgrading the driver on Mac (I'm new to OS X/Mac), the machine is new and drivers half a year old.

Code: Select all

Linking:CubeShader - 
ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 2 samplers

Validate:CubeShader - 
ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 2 samplers

Validation Failed: Program is not successfully linked.

Failed to link shader.
GPU_physics_demo.cxx:277: failed assertion `cubeShader -> compiledOK ()'
What graphics card do you use?

User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker » Wed Sep 13, 2006 11:03 pm

Erwin Coumans wrote: Under windows, NVidia 6800 latest drivers, now it runs without reporting an error, but with just a grey screen.
Agggh! I wonder what that's all about? It's kinda hard to diagnose at long range.
Under mac it reports an error. I have no idea about GPU's, is a vertex shader samples absolutely necessary ;-) The Macbook has none it reports. I haven't tried upgrading the driver on Mac (I'm new to OS X/Mac), the machine is new and drivers half a year old.

Code: Select all

Linking:CubeShader - 
ERROR: Implementation limit of 0 active vertex shader samplers (e.g., maximum number of supported image units) exceeded, vertex shader uses 2 samplers
Well, 'sampler' is shader-speak for a texture map. The 'CubeShader' does indeed use two textures - one for position and the other for rotation. Without the ability to bind 'samplers' to vertex shaders, we'd have to pull the result texture back into the CPU and we couldn't draw all of those objects in one big 'splat' with the hardware doing everything,

It's really a needed feature.
What graphics card do you use?
Here a home, I have a vanilla nVidia 6800 card - at work I have a 6800GT, 7800 ULTRA and a 7900 SLI. The 0.1 version runs identically on all of them.

Running the 'glewinfo' program here at home, I see:

Running on a GeForce 6800/PCI/SSE2 from NVIDIA Corporation
OpenGL version 2.0.0 NVIDIA 76.76 is supported

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans » Wed Sep 13, 2006 11:37 pm

Perhaps we can simplify the demo, reduce the amount of shaders?
Or can we visualize some of the intermediate results in some way?

Are the any ways to debug the results in any way? Either rendering some buffers, or sending stuff back to GPU.

Thanks,
Erwin


Dual booting the macbook into windows results in error below.

Code: Select all

Linking:VelocityGenerator -
 Link successful. The GLSL vertex shader will run in hardware. The GLSL fragment
 shader will run in hardware.
Validate:VelocityGenerator -
 Link successful. The GLSL vertex shader will run in hardware. The GLSL fragment
 shader will run in hardware. Validation successful.
Linking:PositionGenerator -
 Link successful. The GLSL vertex shader will run in hardware. The GLSL fragment
 shader will run in hardware.
Validate:PositionGenerator -
 Link successful. The GLSL vertex shader will run in hardware. The GLSL fragment
 shader will run in hardware. Validation successful.
Linking:CollisionGenerator -
 Link successful. The GLSL vertex shader will run in hardware. The GLSL fragment
 shader will run in hardware.
Validate:CollisionGenerator -
 Link successful. The GLSL vertex shader will run in hardware. The GLSL fragment
 shader will run in hardware. Validation successful.
Linking:CubeShader -
 Link failed.
Validate:CubeShader -
 Link failed. Validation failed - link has not been called or link has failed.
Failed to link shader.
Assertion failed: cubeShader -> compiledOK (), file .\GPU_physics_demo.cxx, line
 273

User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker » Thu Sep 14, 2006 5:04 pm

Erwin Coumans wrote:Perhaps we can simplify the demo, reduce the amount of shaders?

Or can we visualize some of the intermediate results in some way?
Yes - I think we should run just the cubeShader with fixed position and rotation textures. That would eliminate a lot of the code and should leave us with a simple regular grid of
teeny-tiny cubes sitting out in front of the camera.

If that works - then something would have to be going wrong with the iterative cycling through the 'physics' part - being able to pull the textures back into the CPU and maybe save them to disk would help to visualise whatever problem that might be.

If that doesn't work - then we can dump the cubeShader and modify the vertex coordinates of the cubes too see if they come up...steadily working back through simpler and simpler ways to draw things until it works.
Are the any ways to debug the results in any way? Either rendering some buffers, or sending stuff back to GPU.
Well, yes - there are a bunch of little tricks - but unless I can find a windows box, or somehow reproduce the problem at home, this will be a painful process!

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans » Thu Sep 14, 2006 7:08 pm

SteveBaker wrote:
Yes - I think we should run just the cubeShader with fixed position and rotation textures. That would eliminate a lot of the code and should leave us with a simple regular grid of
teeny-tiny cubes sitting out in front of the camera.

If that works - then something would have to be going wrong with the iterative cycling through the 'physics' part - being able to pull the textures back into the CPU and maybe save them to disk would help to visualise whatever problem that might be.
Sound good. Please let me know when you have such more simple GPU sample, I will give it a try on several machines.

Oh, by the way, the fork-lift is still in the pipeline. This weekend I will make a new version with cleaned-up samples, including a start for the fork-lift. Looking forward to play with that too, picking up objects etc ;-)

Thanks!
Erwin

User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker » Fri Sep 15, 2006 1:45 am

Erwin Coumans wrote: Sound good. Please let me know when you have such more simple GPU sample, I will give it a try on several machines.

Oh, by the way, the fork-lift is still in the pipeline. This weekend I will make a new version with cleaned-up samples, including a start for the fork-lift. Looking forward to play with that too, picking up objects etc ;-)
Sounds like we both have a busy weekend ahead of us!

For a simple demo, I was thinking in terms of a multiplayer game where the idea is to race two forklifts around a track that's littered with obstacles that you have to move out of the way - or (more likely) drop in annoying places to frustrate your opponent.

With some simple controls and either split screen rendering or an overview of the entire track - this might not take much to get working. I have all the 3D models it would take.

Dirk Gregorius
Posts: 874
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Post by Dirk Gregorius » Fri Sep 15, 2006 8:35 am

Maybe a little off topic, but how shall all this GPU physic stuff help when your application is GPU bound? Are there so many application out there that have some processing time left for implementing physics on the GPU? I don't want be negative, but what is the reason for all of this - especially with multi-core architectures coming up and if I look at the architechture of the PS3 I don't see any need for GPU physic at all? Maybe you can convince me?

Anyway, thanks for putting so much effort into this and sharing the code!

Cheers,
-Dirk

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans » Fri Sep 15, 2006 2:10 pm

Dirk Gregorius wrote:Maybe a little off topic, but how shall all this GPU physic stuff help when your application is GPU bound? Are there so many application out there that have some processing time left for implementing physics on the GPU? I don't want be negative, but what is the reason for all of this - especially with multi-core architectures coming up and if I look at the architechture of the PS3 I don't see any need for GPU physic at all? Maybe you can convince me?

Anyway, thanks for putting so much effort into this and sharing the code!

Cheers,
-Dirk
First of all because it's FUN :lol:
And Bullet is already being optimized for PS3 SPU & multicore.

I find most recent titles abusing the GPU with boring things that shift the focus from interactive fun to boring rendering. Imagination seems to be lacking with game designers, and allowing to use GPU cycles for GPU physics might shift the budget. I think GPU Physics effects/FX can be the next version of the particle system, but a highly interactive one. So those Physics FX can co-exist with gameplay physics.

Having played with Havok GPU on both Nvidia and ATI it shows potential to add some fun to gaming I think, and with such big companies backing the effort, it seems that GPU physics is a good trend. Recently I bought a Nintendo DS, and playing the new 2D Mario BROS and Brain Age made me realise that their focus on interaction and gameplay is right, and most PS3/XBox 360 titles have their focus wrong.

So I don't see the need for abusing the GPU cycles with boring 1080i/p non-interactive graphics features, perhaps you convince me?
Erwin

Dirk Gregorius
Posts: 874
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Post by Dirk Gregorius » Fri Sep 15, 2006 5:04 pm

I agree with everything you say, but from my experience people want all that physic stuff, but not at the cost it usally comes with. Regarding the Havox FX stuff one could argue that they needed something to react to AGEIA. Anyway it is good that physic gets a lot of attention and people get an idea what can be done with it. If they are willing to abuse some cycles for physics is another question...

User avatar
Dragonlord
Posts: 191
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland
Contact:

Post by Dragonlord » Fri Sep 15, 2006 5:39 pm

The problem is that many games are already abusing physics. It's true focusing on graphics only won't make a good game but the same is true for physics. Many physics gamblings don't add to the gameplay like graphics so the problem exists in both domains.

User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker » Fri Sep 15, 2006 10:47 pm

GPU physics are interesting because there is a potential to speed up the physics by several orders of magnitude - with a reduction in graphics performance of only a few percent.

Sure if you are really, really tight on GPU performance - and have tons and tons of CPU to spare then maybe you shouldn't use it. But you can do the 'grunt work' physics for tens of thousands of objects in the time it takes the GPU to draw a mere handful of 128x128 pixel polygons!

Sure - if I was taking 50% of the GPU to do this then it would be useless - but we're talking a couple of percent - tops.

Also, don't think of this as running on today's computers. It won't run at all on anything but the very high end cards right now - think of this as something that we'll have in a couple of years.

There is a strong case to be made that todays graphics are "good enough" - and anything we add is pretty small details. But most games only do physics on a handful of objects at a time. There is something to be said for having hundreds to thousands of physics-based objects in the game.

Also (as I'm fond of pointing out), not everyone is doing games. I do high end 3D graphics for flight simulators in my 'day job'. We have 40 to 50 PC's rendering graphics because graphics is very easy to distribute. But distributing physics is much harder - and whilst we might dedicate several PC's to doing nothing but physics, the more horsepower we get from one 'physics PC' the better. Since each one has a completely idle GPU - it makes sense to make use of it.

...and yes, it's fun too!

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans » Sat Sep 16, 2006 8:50 pm

Here is some good previous discussion on GPU physics:
http://www.gamedev.net/community/forums ... _id=383736
Local cached copy (pdf)

Steve, will you make some progress this weekend on a simplified GPU rendering sample?

Post Reply