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. mov
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 su
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 maint
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 is
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
<<<
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:
> H
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 following
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 from
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 “
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
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
t
I do not think it is feasible to distribute a different libstdc++ with
V5 stable for macOS unless there's someone who wants to take that on.
Adam
On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh wrote:
> Just for clarification I think Tom was commenting that the changes hurt
> the zone filling s
Just for clarification I think Tom was commenting that the changes hurt
the zone filling speed. @Tom, is that what your were commenting on earlier?
On 3/1/2018 10:11 AM, Jeff Young wrote:
> But then the progress reporter won’t work (and you’ve got no way to cancel).
>
> Non-pooling parallel thre
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 threads.
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 w
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 pragma for the for loop
> opti
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 Young wrote:
>> The purpose is
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 wri
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!
>> In that case we should st
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 usual
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 di
> 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:
<<<
I'd like to hear from a *sing
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) w
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 tha
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
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 2018,
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 where it has real impact
Currently, I fully agree with you.
The only spot right now where it has real impact is the raytracing 3d viewer.
And for me it is also only 3x faster with threading, so not that critical for
some “offline” functionality.
But more and more OpenMP stuff might get added which maybe will make an imp
OK, I’ll play around some more with GCD.
I’ll also check what a custom toolchain/compiler would mean.
We can decide then which way to finally go when more parallelisation stuff
might be added in future.
Bernhard
> On 1. Mar 2018, at 14:25, Wayne Stambaugh wrote:
>
> Ughh! Thank you Apple.
My work team is 100% on Mac. They run Altium on a Windows VM and would
gladly switch to KiCad if it had feature parity and a native Mac version.
Also Chris is a Mac user and his motherboard is pretty complex :)
-Jon
On Thu, Mar 1, 2018, 08:34 Tomasz Wlostowski
wrote:
> On 01/03/18 14:29, Jon
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 if we can't use
> Op
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.
Be
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 *single*
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:
> Ughh! Thank you Apple
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 c
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 w
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 Open
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
exp
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 familiar with the MacOS too
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
40 matches
Mail list logo
