FreeCAD renderer is CPU bounded (at least for me)
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
FreeCAD renderer is CPU bounded (at least for me)
I don't want hi-jack that thread, but only share a small observation.
I opened Yorik's the "panel" file, disabled Shape2DView projections and made the view turntable. Then observed CPU (via top) and GPU (via radeontop - a Linux tool, works with Radeons and both (Catalyst or open source) drivers)) usage:
* GPU usage (Radeon 6670, R600g driver) about 10%
* CPU (Athlon 240): one core full usage (a bottleneck)
* ~15 fps
Situation was better for the "Schenkel" file, about 50% GPU usage, 300 fps. Of course the second file was much simpler.
End of observation. Thank you for your time;)
I opened Yorik's the "panel" file, disabled Shape2DView projections and made the view turntable. Then observed CPU (via top) and GPU (via radeontop - a Linux tool, works with Radeons and both (Catalyst or open source) drivers)) usage:
* GPU usage (Radeon 6670, R600g driver) about 10%
* CPU (Athlon 240): one core full usage (a bottleneck)
* ~15 fps
Situation was better for the "Schenkel" file, about 50% GPU usage, 300 fps. Of course the second file was much simpler.
End of observation. Thank you for your time;)
Re: FreeCAD renderer is CPU bounded (at least for me)
Interesting, and what your seeing makes some sense to me and what I think I understand. I'm sure someone that actually knows in in's and out's of what Coin is doing might very well tell me I'm wrong, but... I'm thinking that the handling of the geometry is done by the CPU and the affect of light is done with the GPU. That is to say the actual turning of the object and it's shape at any given angle of view is being done with the CPU and the color, shiny or dull texture, shadows, etc. are being done with the GPU. Sense FreeCAD is not doing much with the raytrace side of it (yet), most of what you see as far as movement of the object is all being handled by the CPU. The GPU usage would go up, if for instance there were detailed shadows, bumpy, or mirror like textures, reflections, fog effect, and the like.
Like I said, that's what I think is going on. Would be nice to know for sure. It would also be nice if the handling of the geometry could be shifted to the GPU, but if that was not switchable, it would leave FreeCAD broken for anyone that did not have an OpenGL capable video chip.
Mark
Like I said, that's what I think is going on. Would be nice to know for sure. It would also be nice if the handling of the geometry could be shifted to the GPU, but if that was not switchable, it would leave FreeCAD broken for anyone that did not have an OpenGL capable video chip.
Mark
This post made with 0.0% Micro$oft products - GOT LINUX?
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: FreeCAD renderer is CPU bounded (at least for me)
I am seeing the same thing here. I have an on-board radeon hd4200 with open source driver, so my gpu usage is more than yours(30%), but I have one cpu core pegged at 100%. Seems like I remember seeing this with Unigraphics, so might be the norm. It does look like we spend a bit of time in SoBrepFaceSet::renderShape. See attached. Can be viewed with kgraphviewer(kde) or xdot(x11).
- Attachments
-
- profile.dot.zip
- NOT a zip.
- (47.57 KiB) Downloaded 151 times
Re: FreeCAD renderer is CPU bounded (at least for me)
In the file https://github.com/FreeCAD/FreeCAD_sf_m ... pFaceSet.h you could activate the define (by replacing #if 0 with #if 1) and check if this makes higher use of the GPU.
Code: Select all
#define RENDER_GLARRAYS
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: FreeCAD renderer is CPU bounded (at least for me)
Apparently we need to do more than just change the #define? I am not making it into the alternative call stack.
SoBrepFaceSet.cpp:183
apparently we can only use the glarrays if we have a certain material binding? Not sure where the material binding gets set and if it is persistant through the gui::document?
SoBrepFaceSet.cpp:183
Code: Select all
if (!doTextures && index_array.size() && hl_idx < 0 && num_selected <= 0) {
if (mbind == 0) {
mb.sendFirst(); // only one material -> apply it!
renderSimpleArray();
return;
}
else if (mbind == 1) {
renderColoredArray(&mb);
return;
}
}
Re: FreeCAD renderer is CPU bounded (at least for me)
No bigger difference for "Panels". Unfortunately both GPU usage (50% to 30%) and framerate (300 to 200 fps) goes down for "Schenkel" after the change.wmayer wrote:In the file https://github.com/FreeCAD/FreeCAD_sf_m ... pFaceSet.h you could activate the define(by replacing #if 0 with #if 1) and check if this makes higher use of the GPU.Code: Select all
#define RENDER_GLARRAYS
Edit: Some numbers from my laptop: i7-3632QM (4C/8T), integrated Intel HD 4000 + discrete Nvidia 645M (via Bumblebee/primus).
"Yorik's Panels":
* Geforce 645M - 20 fps, CPU usage 100%
* Intel HD 4000 - 14 fps, GPU usage (intel_gpu_top tool) - 30%, CPU 90%
* llvmpipe (software, no GPU) - 5 fps, CPU usage 150% (in optimal conditions should be 800% as 8 threads AFAIK)
"Schenkel":
* Geforce 645M - 200 fps, CPU usage 170% (two threads, maybe Bumblebee thing?)
* Intel HD 4000 - 200 fps, GPU usage (intel_gpu_top tool) - 60%, CPU 60% (no CPU bottleneck?)
* llvmpipe (software, no GPU) - 90 fps, CPU usage 300%
Re: FreeCAD renderer is CPU bounded (at least for me)
Hm, this was a contribution from a guy a year ago or so and he said that it speeds up the rendering. I have never looked very deeply into it.Apparently we need to do more than just change the #define? I am not making it into the alternative call stack.
Re: FreeCAD renderer is CPU bounded (at least for me)
First of all, we will never reach 100% in GPU due to the fact that modern GPUs consist mostly out of things we don't need, like Pixel engines geard toward shader programs or texture-engines. So 50% is already pretty high. The newer the GPU hardware, the lower the GPU usage I would guess...
The main difference of the Schenkel and the Panel are the number of nodes in the scene graph. So if you have a project consisting of small parts with only a couple of triangles each, the rendering process is more traversing the scene graph (CPU) rather then rendering triangles (GPU). So at them moment FreeCAD is not geared toward lots of parts. There fore our scene graph layout is to "flat". You can see this in the Scene Graph Inspector in the tools menu.
The solution is:
Coin has the ability to cash sub-scene graphs. Every SoSeparator can cash and hold the information for faster rendering on the GPU. But there fore we need a more tree like scene graph and carefully tuning the cashing parameters.
I already started that on the Assembly. There all sub-assemblies are grouped under the ViewProvider of its father. So the scene graph is more a tree. Also we can later on do more performance improvement by putting whole sub assembly graphs into on Coin node and make switching by LOD (Level of Detail) nodes.
So Coin has a lot of tricks we can use to speed up the render performance, but so far the CPU/GPU speed grows faster as the size of the FreeCAD models. But with the arrive of the Assembly this tide will surly turn
The main difference of the Schenkel and the Panel are the number of nodes in the scene graph. So if you have a project consisting of small parts with only a couple of triangles each, the rendering process is more traversing the scene graph (CPU) rather then rendering triangles (GPU). So at them moment FreeCAD is not geared toward lots of parts. There fore our scene graph layout is to "flat". You can see this in the Scene Graph Inspector in the tools menu.
The solution is:
Coin has the ability to cash sub-scene graphs. Every SoSeparator can cash and hold the information for faster rendering on the GPU. But there fore we need a more tree like scene graph and carefully tuning the cashing parameters.
I already started that on the Assembly. There all sub-assemblies are grouped under the ViewProvider of its father. So the scene graph is more a tree. Also we can later on do more performance improvement by putting whole sub assembly graphs into on Coin node and make switching by LOD (Level of Detail) nodes.
So Coin has a lot of tricks we can use to speed up the render performance, but so far the CPU/GPU speed grows faster as the size of the FreeCAD models. But with the arrive of the Assembly this tide will surly turn
Stop whining - start coding!
Re: FreeCAD renderer is CPU bounded (at least for me)
That's good news.
I made a couple of moderately large assemblies (open source 3D printers), and as soon as I start to add hardware (bolts) the performance while panning or rotating the view takes a huge hit. So much so that it becomes unmanageable.
I made a couple of moderately large assemblies (open source 3D printers), and as soon as I start to add hardware (bolts) the performance while panning or rotating the view takes a huge hit. So much so that it becomes unmanageable.
Re: FreeCAD renderer is CPU bounded (at least for me)
For such cases we need also a kind of automatic render resolution management.
Most people in FreeCAD has set a rather high render resolution in the preferences, because they want to see circles as circles (how irrational ). But for large model thats contra productive. Especally in cases such as Screws. You don't really see much of them, but they have a hight triangle count, cause of the detailed heads of even a thread and fillets/chamfer.
So in assembly we need a eye on that too, such as low render quality for catalog parts...
Most people in FreeCAD has set a rather high render resolution in the preferences, because they want to see circles as circles (how irrational ). But for large model thats contra productive. Especally in cases such as Screws. You don't really see much of them, but they have a hight triangle count, cause of the detailed heads of even a thread and fillets/chamfer.
So in assembly we need a eye on that too, such as low render quality for catalog parts...
Stop whining - start coding!