Break signal for 3Dsurface

Here's the place for discussion related to CAM/CNC and the development of the Path module.
GeneFC
Posts: 1452
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Break signal for 3Dsurface

Postby GeneFC » Sat Jul 18, 2020 2:36 pm

As I mentioned earlier, when I was playing with Freman's "endless loop" model I saw full 100% utilization (4 cores) for most of the time.

This was using the precompiled FreeCAD available on the releases page. It may be a packaging thing.

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21937 (Git)
Build type: Release
Branch: master
Hash: 0de5a290113800dc5779a76d7e216bd882e0ed1e
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

Gene
GeneFC
Posts: 1452
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Break signal for 3Dsurface

Postby GeneFC » Sat Jul 18, 2020 2:42 pm

<Charlie_root> wrote:
Sat Jul 18, 2020 4:11 am

I mean howcome Slic3r can just eat through a huge complex model at 0.2mm layer height basically instantly ?

what if we ditch G2 interpolation and just use linear piecewise ? would that speed it up ?
I think slicing is 2D. :shock:

Lots of repetitions for layers, but still just 2D.

Just from looking at the code I would guess that the G-code generation is only a tiny part of the time consumed. The majority of the time is figuring out what to cut.

Gene
etrombly
Posts: 135
Joined: Thu Dec 05, 2019 6:50 pm

Re: Break signal for 3Dsurface

Postby etrombly » Sat Jul 18, 2020 5:31 pm

GeneFC wrote:
Sat Jul 18, 2020 2:36 pm
As I mentioned earlier, when I was playing with Freman's "endless loop" model I saw full 100% utilization (4 cores) for most of the time.

This was using the precompiled FreeCAD available on the releases page. It may be a packaging thing.

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21937 (Git)
Build type: Release
Branch: master
Hash: 0de5a290113800dc5779a76d7e216bd882e0ed1e
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

Gene
That's weird, maybe a different program was running at the same time? The endless loop was in a single threaded python portion of the code that doesn't call out to anything else.
GeneFC
Posts: 1452
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Break signal for 3Dsurface

Postby GeneFC » Sat Jul 18, 2020 8:26 pm

No, it was definitely FreeCAD. Memory usage sky-rocketed as well, up to about 30 GB, so perhaps something else was going on. This went on for 30 minutes or more, until I finally killed it. Of course there could have been a very small portion of the code that was locked up, using multiple threads to do nothing.

Gene
User avatar
<Charlie_root>
Posts: 36
Joined: Mon Aug 12, 2019 8:01 pm
Contact:

Re: Break signal for 3Dsurface

Postby <Charlie_root> » Sun Jul 19, 2020 12:05 am

I'm also wondering ... maybe this is completley absurd, but is there a possibility of speeding it up frther by doing some of the parralel processing on the GPU ?
RETRIBUTION IS AT HAND
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Sun Jul 19, 2020 1:48 am

I raised this a while ago. IIRC it was reckoned to be too hardware specific to invest time into developing it.
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Sun Jul 19, 2020 8:51 am

etrombly wrote:
Sat Jul 18, 2020 11:10 am
There are a few things that can still be done to speed it up. There are some steps that can be done in parallel, but I just did a quick check with mnesarco's threading module, and due to pythons GIL it doesn't actually speed anything up. Those sections would need to be ported to C++ (which would be a big task, it's a large chunk of the current python code).

Originally the meshing was done using brepmesh, it's currently done using part.tessellate. I can do some tests because it seems like tessellate is a little slower. I had added a much faster method, but it didn't create an accurate enough result. Maybe we can still use that for a preview pass, before generating the final operation.
That preview idea is very good. I often do half a dozen recomputations of a 3Dsurface path before getting all the params the way I want. I also have to turn off auto-recompution when editing params in the tree view. A faster, less accurate preview mode would be a great help.
Opencamlib is the slowest part. It's supposed to support multi threading, but I've noticed 3D surface seems to just be pegging 1 core most of the time. Maybe there are some improvements that can be made upstream. It might not be something that could be made parallel easily though.

edit: just looked around with opencamlib, the docker build I'm using doesn't turn on openmp (multithreading) support. I have a feeling this is true for most people. I turned it on and recompiled, but need to test more if it makes a difference.
What needs to be done to enable openmp on OCL build? I want to make sure I'm doing that.
etrombly
Posts: 135
Joined: Thu Dec 05, 2019 6:50 pm

Re: Break signal for 3Dsurface

Postby etrombly » Sun Jul 19, 2020 12:49 pm

When you compile opencamlib change it to something like "cmake -D BUILD_PY_LIB=ON -D BUILD_CXX_LIB=OFF -D USE_PY_3=ON USE_OPENMP=ON". If you're on windows and using the cmake gui just search for openmp. I just opened an issue for the docker container I'm using here https://gitlab.com/daviddaish/freecad_d ... /issues/15 to turn it on by default.
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Sun Jul 19, 2020 1:27 pm

Yes, I find that option ON in my CmakeCache.txt
Thanks for the confirmation.

That may just make the library re-entrant so mulitple threads can be called at once rather than creating multiple threads internally.