the demos run too slow on GPU RTX30XX

[ElonKou]

Thanks for your great work, I have compared this repo on different GPU s, Its seems that the demos run slowly on RTX 3080, but runs faster on 1060Ti, the simulate time of demo did not grow linearly, but intermittently, even if all threads are used to simulate.

[ElonKou]

compile mode: Release OS: ubuntu 20.04 compiler: GCC 9.4.0 openMP : 4.5 This seems doesn't same as #111 's compile mode problem, thanks again.

[ElonKou]

It seems that omp doesn't work well, and these are "BarDemo" 's output when use STOP_TIMING_PRINT at https://github.com/InteractiveComputerGraphics/PositionBasedDynamics/blob/00db2e091a88a628099787cf6fada941e851dbfa/Simulation/TimeStepController.cpp#L240C2-L240C17:

time simulation step: 0.902057 ms
time simulation step: 1.63367 ms
time simulation step: 1.6798 ms
time simulation step: 1.04513 ms
time simulation step: 0.900882 ms
time simulation step: 1.06935 ms
time simulation step: 133.068 ms
time simulation step: 1.09121 ms
time simulation step: 0.908746 ms
time simulation step: 0.903538 ms
time simulation step: 0.911558 ms
time simulation step: 0.898618 ms
time simulation step: 0.904867 ms

It looks like stange when substep cost 133ms. So I delete #pragma omp parallel if(numBodies > MIN_PARALLEL_SIZE) default(shared) at TimeStepController.cpp file , then the program works better , but slower thand 1060Ti, I guess the #define MIN_PARALLEL_SIZE 64 will cause this problem, than I set 6400 for MIN_PARALLEL_SIZE, the demo runs same as delete omp paralle sentances, also not intermittently.

maybe that is omp's fault or wrong use of omp, but I'm not familer with omp.

and this is my cpu : 12th Gen Intel® Core™ i7-12700 × 20

Tnanks very much!

[janbender]

On some systems the v-sync slows down the execution. Can you try to turn this off?

[ElonKou]

On some systems the v-sync slows down the execution. Can you try to turn this off?

It semes that doesn't reduce the random large "time simulation step" when I turn off the v-sync on my ubuntu system, and other's openGL program works well on whether it's in open or closed.

[janbender]

It's really hard to say where is the problem. The solver performs a fixed number of iterations, so therefore the solver should take approximately the same time in each step.

Just to be sure that the problem does not come from the visualization. Could you try to turn this off? Just comment out lines 60-64 (the MiniGL commands) and instead add a loop in which you call timeStep() until the time is greater than the end time of the simulation.

[ElonKou]

It's really hard to say where is the problem. The solver performs a fixed number of iterations, so therefore the solver should take approximately the same time in each step.

Just to be sure that the problem does not come from the visualization. Could you try to turn this off? Just comment out lines 60-64 (the MiniGL commands) and instead add a loop in which you call timeStep() until the time is greater than the end time of the simulation.

Thanks for you reply , I have tested time cost on different settings (101 timeStep() , MIN_PARALLEL_SIZE=64 or MIN_PARALLEL_SIZE=6400, whether use MiniGL rendering ), It seems that rendering will not affect time, but MIN_PARALLEL_SIZE, and there are some statistical results.

and, max time in 101x8 = 808 outputs result: 64_render: 368.575 ms (too large) 64_norender: 724.715 ms (too large) 6400_render: 23.6743 ms (normal) 6400_norender: 24.0029 ms (normal)

Did openMP encounter resources competition during thread scheduling?

[janbender]

That's quite strange. I never had issues like that on my machine.

[ElonKou]

That's quite strange. I never had issues like that on my machine.

Yes, this is a very strange problem, and I will continue to check if there is a solution. Thank you again for your help and outstanding work. This is a great PBD project :-)