Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post Reply
slackydeb
Posts: 14
Joined: Sat Aug 09, 2008 7:15 pm

Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by slackydeb »

Hi.


In this post I refer to Bullet svn r1526 (aka 2.73RC4).
I'm on Debian GNU/Linux testing "Lenny" x86 32bit.
I compile using cmake/make/gcc as found in Debian repository.
My VGA is Nvidia 6600GT, driver 173.14.09.


In the "Extra" folder I found "GPUphysics" and "CUDA".


Trying to build "CUDA" I realized that it has only VS build support.
In the future will you support cmake or make for it?
(I am just curious, because I don't think my VGA supports CUDA).


Then I tried to build "GPUphysics" (I added "GPUphysics" in Extras/CMakeLists.txt).

I got this output (compilation ok, but problems linking):
Linking CXX executable GPUphysics
/usr/bin/ld: cannot find -l../../Glut/glew/lib/glew32.lib
collect2: ld returned 1 exit status
make[2]: *** [Extras/GPUphysics/GPUphysics] Error 1
make[1]: *** [Extras/GPUphysics/CMakeFiles/GPUphysics.dir/all] Error 2
make: *** [all] Error 2
It searches bullet_root/Glut/glew/lib/glew32.lib, but I think this is broken even building with VS because glew32.lib is in bullet_root/Glut/.

(glew32.lib is full of .dll, so I don't think it is useful under GNU/Linux).
Searching where my glew library is, I discovered this
user@host:~$ ls -l /usr/lib/libGLEW.*
-rw-r--r-- 1 root root 262438 25 gen 2008 /usr/lib/libGLEW.a
lrwxrwxrwx 1 root root 16 9 nov 20:31 /usr/lib/libGLEW.so -> libGLEW.so.1.5.0
lrwxrwxrwx 1 root root 16 9 nov 20:31 /usr/lib/libGLEW.so.1.5 -> libGLEW.so.1.5.0
-rw-r--r-- 1 root root 224992 25 gen 2008 /usr/lib/libGLEW.so.1.5.0
To build GPUphysics on GNU/Linux you have to substitute

Code: Select all

LINK_LIBRARIES(
  ../../Glut/glew/lib/glew32.lib ${GLUT_glut_LIBRARY} ${OPENGL_gl_LIBRARY} ${OPENGL_glU_LIBRARY}
)
with

Code: Select all

LINK_LIBRARIES(
  /usr/lib/libGLEW.so ${GLUT_glut_LIBRARY} ${OPENGL_gl_LIBRARY} ${OPENGL_glU_LIBRARY}
)
in Extras/GPUphysics/CMakeLists.txt.
Can you please apply a similar fix to svn to let build GPUphysics on GNU/Linux?

Then I ran the built executable, and tried what is suggested in Extras/GPUphysics/DEBUGGING_README.
I noticed that in that file the executable is referred to as GPU_physics_demo, but the actual name of the executable is GPUphysics.
Should the name of the executable (or the doc) be changed?

When I run the executable, I get this output first:
INFO: This hardware supports at most:
4 vert texture samplers
16 frag texture samplers
16 total texture samplers
Running the executable with "./GPUphysics", "./GPUphysics -p" or "./GPUphysics -v" I get an output as this:
@a
@b
@c
...
What does it mean?

Running "./GPUphysics" , the interesting rows I get are these (I report only the first 10):
Performance: 1 passes 256 cubes: other=0.208000ms collisions=0.933000ms
Performance: 1 passes 256 cubes: other=0.207000ms collisions=0.932000ms
Performance: 2 passes 256 cubes: other=0.189000ms collisions=1.446000ms
Performance: 2 passes 256 cubes: other=0.190000ms collisions=1.444000ms
Performance: 1 passes 256 cubes: other=0.211000ms collisions=0.932000ms
Performance: 2 passes 256 cubes: other=0.208000ms collisions=1.441000ms
Performance: 2 passes 256 cubes: other=0.187000ms collisions=1.447000ms
Performance: 2 passes 256 cubes: other=0.187000ms collisions=1.447000ms
Performance: 2 passes 256 cubes: other=0.188000ms collisions=1.447000ms
Performance: 2 passes 256 cubes: other=0.192000ms collisions=1.438000ms
...
Running "./GPUphysics -v" , the interesting rows I get are these (I report only the first 10):
Performance: 1 passes 256 cubes: other=0.640000ms collisions=0.745000ms
Performance: 1 passes 256 cubes: other=0.585000ms collisions=0.749000ms
Performance: 2 passes 256 cubes: other=0.585000ms collisions=1.260000ms
Performance: 2 passes 256 cubes: other=0.568000ms collisions=1.261000ms
Performance: 1 passes 256 cubes: other=0.637000ms collisions=0.672000ms
Performance: 2 passes 256 cubes: other=0.568000ms collisions=1.260000ms
Performance: 2 passes 256 cubes: other=0.569000ms collisions=1.253000ms
Performance: 2 passes 256 cubes: other=0.566000ms collisions=1.261000ms
Performance: 2 passes 256 cubes: other=0.587000ms collisions=1.259000ms
Performance: 2 passes 256 cubes: other=0.591000ms collisions=1.258000ms
...
What do these rows mean?


Last question.
What is GPUphysics? (I quickly read [1], but I didn't understand too much...)
Is it a library to execute code on the GPU using GLSL shaders (without CUDA/Stream)?
It doesn't seem tightly integrated with Bullet... How much is it general?


(Sorry for the long post.)

Thanks for your great work.
slackydeb


[1] http://www.bulletphysics.com/Bullet/php ... 00&p=10217
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by Erwin Coumans »

slackydeb wrote: In the "Extra" folder I found "GPUphysics" and "CUDA".

Trying to build "CUDA" I realized that it has only VS build support.
In the future will you support cmake or make for it?
We accept contributions for a CMake support for Bullet/Extras/CUDA.
Then I tried to build "GPUphysics" (I added "GPUphysics" in Extras/CMakeLists.txt).
GPUphysics is obsolete and used GLSL indeed. We could remove it if it causes confusion.

We actively work on CUDA and OpenCL support for Bullet.
Thanks,
Erwin
slackydeb
Posts: 14
Joined: Sat Aug 09, 2008 7:15 pm

Re: Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by slackydeb »

Erwin Coumans wrote: We accept contributions for a CMake support for Bullet/Extras/CUDA.
From your response I understand that the code is cross platform (Windows, GNU/Linux, BSD, ...), but it lacks cmake build support.
I don't think I'll spend time contributing a cmake build support for CUDA because CUDA is a proprietary technology.

Erwin Coumans wrote: GPUphysics is obsolete and used GLSL indeed. We could remove it if it causes confusion.
Thanks for this info.

Erwin Coumans wrote: We actively work on CUDA and OpenCL support for Bullet.
I'm interested in OpenCL support for Bullet.
I didn't find where the folder in Bullet regarding OpenCL is. Can you please point me out where is it?
Is OpenCL support only planned? Can I contribute to it?
In the last week I searched a lot for OpenCL specs and/or OpenCL SDK (even a pre-release version of them). Do you know where are they?


slackydeb
nadro
Posts: 17
Joined: Tue Jul 03, 2007 10:37 am

Re: Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by nadro »

Hi,
Support for CUDA is very good, but only for NV GeForce's users... What with ATI Stream support?
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by Erwin Coumans »

nadro wrote:Hi,
Support for CUDA is very good, but only for NV GeForce's users... What with ATI Stream support?
OpenCL is the recommended future-proof path. And our CUDA prototyping will be easy to port over to OpenCL. OpenCL makes Stream, GLSL, Brook obsolete for GPGPU development.

So in short: Our CUDA prototyping prepares for an OpenCL implementation. The OpenCL standard is currently being developed by Khronos members and not publically available yet.

Hope this helps,
Erwin
slackydeb
Posts: 14
Joined: Sat Aug 09, 2008 7:15 pm

Re: Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by slackydeb »

Erwin Coumans wrote: So in short: Our CUDA prototyping prepares for an OpenCL implementation. The OpenCL standard is currently being developed by Khronos members and not publically available yet.
Ok, then perhaps when I have some spare time I'll test/contribute to Bullet CUDA.


Thanks.
slackydeb
nadro
Posts: 17
Joined: Tue Jul 03, 2007 10:37 am

Re: Feedback/Bug Report about Extras/GPUphysics on GNU/Linux

Post by nadro »

Erwin Coumans wrote:
nadro wrote:Hi,
Support for CUDA is very good, but only for NV GeForce's users... What with ATI Stream support?
OpenCL is the recommended future-proof path. And our CUDA prototyping will be easy to port over to OpenCL. OpenCL makes Stream, GLSL, Brook obsolete for GPGPU development.

So in short: Our CUDA prototyping prepares for an OpenCL implementation. The OpenCL standard is currently being developed by Khronos members and not publically available yet.

Hope this helps,
Erwin
That's great :)
Post Reply