[Vincent]

Hi @skywaver,

There are multiple factors that can impact GPU performance. The raptor-cuda.scn model has about 20000 elements, which in theory would be enough to fill a Titan Xp. However, the occupancy will depend on how many blocks of threads can fit on each SM, which depends on the size of the blocks and on how many registers the kernels use.

The low occupancy would explain why only 25% of your GPU is being used. To know exactly what prevents it from being fully used, you should use the visual profiler that comes with the CUDA SDK. It will tell you exactly what kernels could be improved and how.

The profiler will also tell you the bottleneck that leads to a low frame rate. It would either be the memory transfers or the kernels. The reason is probably that it simply takes a long time to compute the force field. To decrease that time you would need to increase the occupancy of the GPU.

On my computer (with a GTX 1050 Ti), GPU usage reaches about 40%, with about 45 frames per second. When I used CUDA a while ago, the bottleneck was the GPU was not fully used, and the memory transfers had little immpact.

Cheers,
Vincent

[Vincent]

Hello Gad,

Then your scene parameters are set pretty much exactly as they should for what you want. I tried your scene and it worked directly. The two livers fall at the same speed, but they bounce differently, as expected. You might want to increase the max number of iterations of the CG solver for the smaller one, but other than the scene seems to run as it should.

In this particular case it’s better to use a separate solver instance for each object, since they have different convergence characteristics (the elements do not have the same size).

Cheers,
Vincent

[Vincent]

Hi Gad,

It’s actually not very simple to keep everything consistent. IT also depends on what you want to achieve. We could say there are some “base” unit types: distance (e.g. meter), mass (e.g. kilogram) and force (e.g. newton). We could also add time to those, but the units are usually assumed to be seconds. Every other quantity depends on these units, but you have to manage them yourself.

For example, in your scene you divided the size by 10. This means that, to obtain the exact same object behavior, you need to adjust gravity (units of size/time^2, so divide by 10), mass density (implicitly defined with the UniformMass, which has units of mass, so no need to change it), and Young’s modulus (units of force/size^2, so multiply by 100). The smaller object will appear to move more slowly, just like it would appear if you zoomed the camera out 10 times farther.

There are other things that need to be considered in your scene. The first is that contacts will also be different if you scale the object. If you keep the same contact stiffness for the smaller liver, the contacts will be 10 times stronger (units of force*size).
The second one is the solver used to advance the system in time. The more nodes there are in your liver model, the more iterations the CGLinearSolver needs to reach the solution. If it does only 25 iterations and does not actually converge, the objects in the scene will move more slowly than they should.

Hope this helps.

Cheers,
Vincent

[Vincent]

Hi swkhang,

There are no default units in SOFA, you have to define them yourself. If you decide to use meters for size and kg for mass, your gravity will have units of m/s^2, your mass density kg/m^3 and Young’s modulus in Pa (or N/m^2). If you decide to measure size in millimeters, everything else has to be changed accordingly, so you would get a gravity in mm/s^2, a mass density in kg/mm^2 and Young’s modulus in MPa.

For springs, I’m guessing the coordinates/size is the most important unit. A stiffness of 10000 in meters would not be so large (N/m), but in mm it would be huge (N/mm). The same goes for mouse events, which are modeled with a spring.

Cheers,
Vincent

[Vincent]

At this point, only the configuration is done. To build the runSofa application, you need to run the command ninja from the /home/user1/sofa/build/v17.06/ directory. This could take from 10 minutes to 1 hour, depending on your machine.

Once compilation is complete, you can run ninja install from the same directory to perform the installation. You can also run Sofa directly from the build directory in /home/user1/sofa/build/v17.06/bin

Let me know if you still have issues after that.

Cheers,
Vincent

[Vincent]

Hi,

Could you post the output you get when compiling? From the output of CMake, it looks like the configuration was successful.

Cheers,
Vincent

[Vincent]

Hi Erwan,

If you want to add a template that does not already exist in SOFA, you also need to give it a name with the Name() function that returns the string you will use in your scene. For example:
template<> inline const char* Vec3fTypes::Name() { return "Vec3f"; }

In this case, the Vec3fTypes is a specific typedef for another more general template, juste like std::string with the <__cxx11basic_string<char, char_traits<char>, allocator<char> > >>. This particular example can be found in sofa/defaulttype/VecTypes.h. It is also possible to define an alias for a particular template, as can be seen in sofa/defaulttype/TemplateAliases.cpp.

To summarize, you can define your template name with something like
template<> inline const char* std::string::Name() { return "String"; }
and if you want to be able to write it differently,
RegisterTemplateAlias StringAlias("str", "String");

Cheers,
Vincent

[Author]

Posts