STEP reader improvement (Pass 4): Moving to OpenGL 3.2

[vejmarie]

Hi Guys,

I worked during my week-end on the 3D pipe rendering and found the FPS bottleneck that we face. Most of the time is positively lost into "SoBrepFaceSet.cpp" to render the triangles from part mesh through standard OpenGL 1.5 code. This is a good option, but with modern OpenGL (we are now at version 4), we can do far much better, and I started to work on a mockup on my Mac Machine.

Roughly I tried to make it purely because the FPS on CAD Assistant is currently x3 the one I got with FreeCAD. I move the code to Vertex Buffer Object, this is currently quick and dirty but stable enough to render the bareleye model and a gear box model that I am using as a test bench with the same rendering quality than before.

bareleye is running with current rendering implementation at 1.5 fps on my system. With VBO implementation I am running on the same hardware at 7.5fps same speed than CAD Assistant ! (still not blazing but, I do not have a discrete GPU on my Mac and the model is huge)

VBO is roughly caching within the GPU memory the rendering mesh avoiding data send operation at each render frame if there is no changes within the model. Same thing it is caching per Part, which means that if we change a Part only this Part will have to be updated the remaining parts mesh will stay the same into the GPU memory.

Moving to VBO within this part of the code will means faster FPS on the global rendering code of FreeCAD. There is a tradeoff it does assume that FreeCAD will work only on OpenGL machine which support at least 3.2 OpenGL. I think that most of modern rendering driver do. At least on Mac most of Mac machine running El Capitan or later are working with that.

I can try to make the code work with a failover approach detecting which pipeline to use depending on the OpenGL implementation, but this might complexify maintenance.

Advise welcome, but I am more than happy regarding this progress, which will allow us to bring FreeCAD performances at the same level than other piece of code !

vejmarie

[triplus]

Sounds good but note that currently i use at least 2 computers (haven't checked all yet) that don't support OpenGL 3.2. And i have a feeling there is a lot of hardware out there currently capable of running FreeCAD in the same situation. My question would therefore be is it really the OpenGL causing FreeCAD to perform slow in such situations. Or is something else the cause and you just bypassed it altogether?

[vejmarie]

Sounds good but note that currently i use at least 2 computers (haven't checked all yet) that don't support OpenGL 3.2. And i have a feeling there is a lot of hardware out there currently capable of running FreeCAD in the same situation. My question would therefore be is it really the OpenGL causing FreeCAD to perform slow in such situations. Or is something else the cause and you just bypassed it altogether?

Hi,

Unfortunatly yes. Because the current implementation with OpenGL 1.5 is sending each vertex for each triangles to the rendering pipeline. It means a crazy amount of copy on the PCIe bus at each frame. Using VBO means, moving the data one time, and asking to the GPU to render them, and updating just what we need lowering PCIe transfer.

I will try to find a clean way to detect hardware support, and depending on it, keeping the standard implementation as a fall back option, which will allow to keep FreeCAD running properly on such machine. Can you tell me which graphical hardware you are using ? OpenGL 3.2 is dating from 2009, and we are in 2017

vejmarie

[ickby]

Hello,

I don't know much about the implementation of BrepFaceSet, but I know that coin does in general support vertex buffer objects. Last time I debugged some render code I have seen those buffers all around To my limited knoledge coin uses them for example in their IndexedFaceSet. There is also this class: https://bitbucket.org/Coin3D/coin/src/1 ... ew-default

Maybe it is sensible to check how coin does the VBO rendering and utilize that in our BrepFaceSet, as this would bring hardeware detection and compatibility automatically.

Edit: this note may be very helpful: https://grey.colorado.edu/coin3d/vbo_rendering.html

[triplus]

Unfortunatly yes. Because the current implementation with OpenGL 1.5 is sending each vertex for each triangles to the rendering pipeline. It means a crazy amount of copy on the PCIe bus at each frame. Using VBO means, moving the data one time, and asking to the GPU to render them, and updating just what we need lowering PCIe transfer.

I see and thanks for the explanation. I notice substantial performance issues in use cases when number of geometry increases. Therefore improving this has my vote. I wasn't sure what could be the cause of this and i guess as you say stressing out the PCI/GPU as you explained does make sense.

I didn't upgrade the GPU on some hardware as FreeCAD runs just fine on it as is for now (when reasonable amount of geometry is being used).

OpenGL 3.2 is dating from 2009, and we are in 2017

vejmarie

Lets say we take Core 2 CPU as a reference as it can still perform reasonably well today. That takes us back in 2006. And at that time a lot of hardware had only OpenGL 2.1 support. I do imagine today 10 years after there is still a lot of such hardware out there (or older). And it's reasonable to expects users will try to run FreeCAD on it for a few more years down the road.

P.S. Occasionally users ask if armhf with OpenGL ES should work.

[vejmarie]

Hello,

I don't know much about the implementation of BrepFaceSet, but I know that coin does in general support vertex buffer objects. Last time I debugged some render code I have seen those buffers all around To my limited knoledge coin uses them for example in their IndexedFaceSet. There is also this class: https://bitbucket.org/Coin3D/coin/src/1 ... ew-default

Maybe it is sensible to check how coin does the VBO rendering and utilize that in our BrepFaceSet, as this would bring hardeware detection and compatibility automatically.

Edit: this note may be very helpful: https://grey.colorado.edu/coin3d/vbo_rendering.html

I don't know that much on Coin yet (still on the learning curve). Looks like that it does match the OpenGL approach (which is not surprising:)). I don't know why BRepFaceSet is not using Coin either, as the whole implementation is using pure OpenGL calls. The cleanest way could be that we use Coin to re-implement it. I will try to have a look.

In the meantime, I can easily detect at run time if the GL implementation support VBO, and as a first step propose a patch which is using VBO in Open GL as a first step if they are available and then move to Coin. It looks like that the dataset will have to be organized the same way.

Using VBO is really accelerating the rendering on GPU integrated chip like most of the one we find on entry level desktop or laptop nowadays.

[wmayer]

With Qt there is an easy way to find out the available OpenGL version: http://doc.qt.io/qt-4.8/qglformat.html# ... nFlag-enum

[vejmarie]

I made a mistacke VBO are supported at Open GL 1.4 ! So it looks like that we can even support very old hardware with that stuff.

[triplus]

I made a mistacke VBO are supported at Open GL 1.4 ! So it looks like that we can even support very old hardware with that stuff.

This would be really good as likely no VBO checkbox or detection would be needed. And for what i read on the web about VBO performance. Improvements should be substantial!

P.S. No wonder i don't upgrade GPU on some hardware i use FreeCAD as it already works good and the performance just keep increasing.

[Jee-Bee]

maybe off topic but what would be a reason not to upgrade to a higher version of OpenGL?