There are a lot of strange things about the way this demo does or does not run on different systems. Unfortunately, I only have access to a handful of different Linux systems (with nVidia 6800 hardware) to do intensive testing on. We really need other OpenSource developers to do some diagnosis on other systems in order that we have a chance to fix this.tasora wrote:Hallo,
I am testing your GPU demo since I am going to implement some
GP-GPU stuff for my multibody simulator.
The demo is very interesting, but I found some problems on my
system.
Can you get us a stack backtrace from the debugger so we can understand where it crashed? That would tell me a lot.GPUphysics -s:
ops: program crashes!
Are the cubes really solidly green or are they shades of green/blue/cyan?GPUphysics -p:
OK, static green cubes displayed.
We don't understand why the vertex shader coide doesn't work under Windows - that's a very bizarre thing that certainly slows the demo down somewhat.GPUphysics -v:
OK, cubes are moving & colliding.
GPUphysics :
OK, cubes are moving & colliding.
Exactly as in GPUphysics -v mode (in fact there is
always the message about vertex shader being disabled,
by default on Win systems.)
On my nVidia 6800-Ultra (on a deskside machine with a 2.8GHz CPU, I get:The performance is a bit too low.. I suspect that there's something
wrong.. Just to give you an idea, the 'average' result is the following:
'Performance: 2 passes 256 cubes: other=0.501740ms collisions=16.285310ms'
Is this normal on a Nvidia 7900GS board?
Performance: 2 passes 256 cubes: other=0.296000ms collisions=1.746000ms
...so no, what you are seeing is definitely not good.
One possibility is that you have set the nVidia control panel (I'm not entirely sure how this works under Windows) such that the system's buffer swap is locked to the video vertical retrace signal. That would force the system to run no faster than 60Hz - or 16.667ms - if the delay somehow ended up being counted inside the collisions code then that might explain the problem. The additional 'other' time is due to the vertex shader being disabled under Windows.
That's weird too. Once again, this does not happen under Linux - so I'm not able to diagnose it. But it seems that one or more of the shader programs has been killed off - yet the main C++ renderer is still running - so whenever C++ tries to send data to the shader that's an invalid operation...but that's a guess. I'm not familar with Windows.After I close the window by mouse clicking, the background DOS
window starts printing the following line THOUSANDS of times:
'GLSL_ShaderPair::getUniformLocation: OpenGL Error - operazione non valida'
until I stop this by Ctrl+C.
If the message was coming out all the time then that would indeed be a problem. Can you start the program from within a DOS shell so you can see the messages coming out as the program runs? It seems hard to believe that this particular error could be happening while the program was running normally (albeit slowly).I suspect this should not happen - also, I guess that this may be related
with note 1), that is the poor performance.
No I'll take a look.PS: have you tested the GP-GPU code in
http://www.mathematik.uni-dortmund.de/~ ... orial.html
There are some hints about supported OpenGL modes
on ATI-Nvidia etc.