Re: [Kicad-developers] MacOS + OpenMP

Hi again, just wanted to share some of my OpenMP on macOS experience, FWIW: I used both clang-5.0.1 and clang-6.0 from MacPorts. KiCad builds fine with it. It works fine on my build machine (b). On my MacBook (a) such a build always crashes when ratsnest changes after I opened the PCB (e.g.

Re: [Kicad-developers] MacOS + OpenMP

On windows builds using msys, openmp 4.5, gcc 7.3.0 On 3/4/2018 1:36 PM, Bernhard Stegmaier wrote: > Hi all, > > could please anybody test the following on a Windows/Linux OpenMP version? > > I have a PCB with only components placed (via “Update from Schematic”), > no routing done yet. > Make

Re: [Kicad-developers] MacOS + OpenMP

Bernhard, On 03/04/2018 02:32 PM, Bernhard Stegmaier wrote: > Wayne, I am seeing the same funny stuff on my old Debian box. > I didn’t follow up, because I thought it might have to do something with my > OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not > that good

Re: [Kicad-developers] MacOS + OpenMP

Wayne, I am seeing the same funny stuff on my old Debian box. I didn’t follow up, because I thought it might have to do something with my OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not that good maintained. But, the first picture is the OpenGL renderer, so this one

Re: [Kicad-developers] MacOS + OpenMP

Orson, no, the raytracing renderer is completely fine in that use-cases. It is only the OpenGL renderer. I first noticed the hang when I switched back from Raytracing to OpenGL (obviously after I did one of the 2 use-cases). If it crashes, I get a backtrace of the crashing thread as follows

Re: [Kicad-developers] MacOS + OpenMP

Bernhard, I suppose this is about raytrace rendering? Anyway, I see it crashing even without any design loaded. 3D viewer passes the first phase so I see the design rendered, but during 'Post processing shader' stage it crashes. Cheers, Orson On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote: >

Re: [Kicad-developers] MacOS + OpenMP

Debian testing package reports libgomp1 version 8-20180218-1 and CMake finds it as version 4.5. I'm not sure why the disconnect. I'm using gcc 7.3.0. I'll check windows when I get a chance. On 03/04/2018 01:36 PM, Bernhard Stegmaier wrote: > Hi all, > > could please anybody test the

Re: [Kicad-developers] MacOS + OpenMP

Hi all, could please anybody test the following on a Windows/Linux OpenMP version? I have a PCB with only components placed (via “Update from Schematic”), no routing done yet. Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer. Now, edit a footprint (“e”) and do a “Update Footprint

Re: [Kicad-developers] MacOS + OpenMP

Hi all, So, I played around a bit to get OpenMP and GCD into something like a “parallel_for” wrapper which either uses OpenMP or GCD. Unfortunately, OpenMP seems to require that the “for” statement directly follows the “#pragma omg for …”. That currently killed all my attempts to define such a

Re: [Kicad-developers] MacOS + OpenMP

Hi, So for now I've had a chance to test the motherboard project on my Retina macbook display. eeschema: horrible zoom, feels like elastic band zoom and I have all scroll wheel accelerations and similar disabled, zoom response is super laggy, cannot work like this, will need to make schematics on

Re: [Kicad-developers] MacOS + OpenMP

When I started with KiCad I had massive problems mixing gcc and clang depending on what dependency was built with which compiler (different libstdc, ABI, etc.) - even if everything should have been compatible in theory. So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t

Re: [Kicad-developers] MacOS + OpenMP

Hi All- I was playing with this last night (don't normally compile on the mac) and found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp. Running some OMP test code from https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 shows expected result of 4

Re: [Kicad-developers] MacOS + OpenMP

Hmm? You keep everything as is (especially creating threads), but just put the “#pragma …” before the for-loop. So, there is one thread for the progress and one for the workers. In the workers thread OpenMP (if there) takes care of adding additional threads for parallelising the loop? Or, am I

Re: [Kicad-developers] MacOS + OpenMP

But then the progress reporter won’t work (and you’ve got no way to cancel). Non-pooling parallel threads are sufficient for zone filling, aren’t they? > On 1 Mar 2018, at 15:00, Bernhard Stegmaier wrote: > > For now it would probably be fine to just restore the

Re: [Kicad-developers] MacOS + OpenMP

For now it would probably be fine to just restore the pragma for the for loop optimisation. Mac users are used to work single-threaded, all others would get back multithreading here. > On 1. Mar 2018, at 15:58, Tomasz Wlostowski wrote: > > On 01/03/18 15:43, Jeff

Re: [Kicad-developers] MacOS + OpenMP

On 01/03/18 15:43, Jeff Young wrote: > The purpose is it works on Mac. > > But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part. > Thanks Jeff! Be aware that neither std::thread nor std::async have any concept of thread pooling - we need to look for a suitable library or

Re: [Kicad-developers] MacOS + OpenMP

The purpose is it works on Mac. But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part. Patch coming. Cheers, Jeff. > On 1 Mar 2018, at 14:09, Tomasz Wlostowski wrote: > > On 01/03/18 15:01, Jon Evans wrote: >> I missed that change to STL, oops!

Re: [Kicad-developers] MacOS + OpenMP

I didn’t follow in detail, but from what I saw I guess the bad thing about it was to use OpenMP for (1) parallelising for loop and (2) creating individual threads for progress reporter and workers. As soon as you don’t have OpenMP it didn’t work anymore… so maybe using OpenMP for (1) and

Re: [Kicad-developers] MacOS + OpenMP

On 01/03/18 15:26, Bernhard Stegmaier wrote: > I didn’t follow in detail, but from what I saw I guess the bad thing about it > was to use OpenMP for > (1) parallelising for loop > and > (2) creating individual threads for progress reporter and workers. > > As soon as you don’t have OpenMP it

Re: [Kicad-developers] MacOS + OpenMP

> On 1. Mar 2018, at 15:28, Tomasz Wlostowski wrote: >> > Sure, I'm all in for STL - my only concern is that zone filling, as it > is done now, does not benefit at all from multiple CPU cores. We need a Welcome to the KiCad Mac world, citing you some mails ago: <<<

Re: [Kicad-developers] MacOS + OpenMP

On 01/03/18 15:01, Jon Evans wrote: > I missed that change to STL, oops! > In that case we should standardize on STL for all new code in the future > so that it will work on Mac. Me too. I don't understand the purpose of it - now all zone calculation (except for insulated copper island removal)

Re: [Kicad-developers] MacOS + OpenMP

I missed that change to STL, oops! In that case we should standardize on STL for all new code in the future so that it will work on Mac. There are already many edge cases I have found (or users have reported) where KiCad is extremely slow, and we need to have a good story for multiprocessing so

Re: [Kicad-developers] MacOS + OpenMP

Once we figure out what is involved and any risks, we can make a decision at that point. I'm working under the assumption that this only applies to the raytracing. Wayne On 3/1/2018 8:41 AM, Bernhard Stegmaier wrote: > Currently, I fully agree with you. > > The only spot right now where it has

Re: [Kicad-developers] MacOS + OpenMP

There’s performance and there’s responsiveness. The footprint loading and zone filling were moved to STL so that progress reporting would work on Mac. As long as we don’t introduce more OpenMP into core stuff, I’m not that fixated on what we use for raytracing. Cheers, Jeff. > On 1 Mar

Re: [Kicad-developers] MacOS + OpenMP

This seems like it is not critical for the upcoming V5 release, but that a strategy should be determined before we get too far into V6, right? Adam On Thu, Mar 1, 2018 at 7:41 AM, Bernhard Stegmaier wrote: > Currently, I fully agree with you. > > The only spot right now

Re: [Kicad-developers] MacOS + OpenMP

The zone filler was moved to STL. > On 1 Mar 2018, at 13:29, Jon Evans wrote: > > It is also used for zone filling and in my new eeschema connectivity code > that I'm hoping to get merged soon after V5 release. > > I'm happy to help with research / testing of alternatives

Re: [Kicad-developers] MacOS + OpenMP

The zone filling code was the only spot which didn’t work by just simply replacing the for loop with dispatch_apply. I’ll have to dig a little deeper on what has to be done there… I guess it is something about using variables outside the loop body in the clang block given to dispatch_apply.

Re: [Kicad-developers] MacOS + OpenMP

On 01/03/18 14:29, Jon Evans wrote: > It is also used for zone filling and in my new eeschema connectivity > code that I'm hoping to get merged soon after V5 release. > > I'm happy to help with research / testing of alternatives if we can't > use OpenMP on Mac.  > I'd like to hear from a

Re: [Kicad-developers] MacOS + OpenMP

It is also used for zone filling and in my new eeschema connectivity code that I'm hoping to get merged soon after V5 release. I'm happy to help with research / testing of alternatives if we can't use OpenMP on Mac. Jon On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh wrote: >

Re: [Kicad-developers] MacOS + OpenMP

Ughh! Thank you Apple. I'm not opposed to this idea if OpenMP isn't a viable option on macos. I would like to see our macos port be on par with linux and windows ports. Wayne On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote: > I did look around a bit. > Looks like OpenMP isn’t a friend of Xcode

Re: [Kicad-developers] MacOS + OpenMP

I did look around a bit. Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its own Grand Central Dispatch (libdispatch) implementation/library doing similar things (at first glance, didn’t look into details). So, I guess OpenMP maybe won’t happen soon with stock toolchain or we

Re: [Kicad-developers] MacOS + OpenMP

Is there a complicated board design online I could download and test for comparison between macOS and windows? Someone people have used before for kicad verification for example. On Wed, Feb 28, 2018 at 11:40 PM, Bernhard Stegmaier < stegma...@sw-systems.de> wrote: > I had a quick look where

Re: [Kicad-developers] MacOS + OpenMP

I had a quick look where OpenMP is used. I found it somewhere in the connectivity/ratsnest code. I don’t know of any complaints in that area and even on my old HW I had never a bad experience. And then, 3D-Viewer. So, in my opinion it is basically only about 3D-Viewer… I don’t know if user

Re: [Kicad-developers] MacOS + OpenMP

Or rip it out and use STL? > On 28 Feb 2018, at 23:38, Jon Evans wrote: > > Hi all, > > Does anyone have a working build setup for getting OpenMP-enabled KiCad out > of MacOS? > If so, please share how -- I tried for a bit but couldn't get it going (I'm > not super

[Kicad-developers] MacOS + OpenMP

Hi all, Does anyone have a working build setup for getting OpenMP-enabled KiCad out of MacOS? If so, please share how -- I tried for a bit but couldn't get it going (I'm not super familiar with the MacOS toolchain yet). We should make sure that the 5.0 release is built with OpenMP, otherwise our