kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 maintained.

My system is a core i7 with an nvidia graphics card using the
proprietary nvidia drivers.  I rarely have any rendering issue with the
nvidia drivers.  I have far less luck with the open source nvidia drivers.

> 
> But, the first picture is the OpenGL renderer, so this one is OK?

Yes, the OpenGL rendering is fine.

> 
> 
> Bernhard
> 
>> On 4. Mar 2018, at 20:20, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> I'm not seeing any crash on Debian testing but there is some rather
>> amusing artifacts on the rendering.  It looks like all of my 3D models
>> have been deconstructed to tiny bits all over the model space.  Last
>> time I checked it was fine on windows.
>>
>> On 03/04/2018 02:06 PM, Maciej Suminski wrote:
>>> 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:
>>>> 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 Library” for only this footprint (no changes in footprint needed).
>>>> Open 3d-viewer again.
>>>>
>>>> Or:
>>>> Open PCB as above with only components and no routing yet.
>>>> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
>>>> Delete some of the components and reimport them vie “Update PCB from Schematic”.
>>>> Open 3d-viewer again.
>>>>
>>>> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang (all cores at 100%, grey window, nothing happens) 3d-viewer .
>>>> It doesn’t hang/crash in my non-OpenMP builds.
>>>>
>>>> If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer of OpenMP build is also fine again.
>>>>
>>>>
>>>> Regards,
>>>> Bernhard
>>>>
>>>>> On 3. Mar 2018, at 20:33, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>> 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 “parallel_for” (as function, #define, ?) so that the code will stay the same for both.
>>>>> One option would be to pull the “#pragma omp for …” into the wrapper, but I guess this is not really acceptable (since you can’t specify any specific schedule parameters any longer).
>>>>>
>>>>> I will think about it some more just because of the challenge… but I am not very optimistic at the moment to get something nice.
>>>>> If anyone else has a nice idea, I’d be very interested to learn freaky new stuff… :)
>>>>>
>>>>> On the other side, I looked at using a non-Xcode OpenMP capable clang.
>>>>> The only caveat seems to be not to mix standard C++ libraries (in the past libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find out if that is resolved).
>>>>> Default on macOS now is libc++, but it seems that at least MacPorts builds clang with libstdc++ per default (no idea why).
>>>>> The MacPorts build can easily be switched to libc++.
>>>>> That clang-mp builds KiCad without problems even if dependencies have been built with Xcode clang.
>>>>> Everything seems to work as expected, multithreading is there where it should be.
>>>>>
>>>>> So, for now it seems to be the most easy solution to switch to a suitable non-Xcode clang for building packages - if we want to have OpenMP for macOS.
>>>>>
>>>>> AFAIK our build machines use Homebrew.
>>>>> Seems as if Homebrew decides which standard library to use depending on macOS version (https://docs.brew.sh/C++-Standard-Libraries <https://docs.brew.sh/C++-Standard-Libraries>).
>>>>> So, if everything is recent enough it might not be a problem at all… like it obviously also has been for Seth below.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Bernhard
>>>>>
>>>>>> On 1. Mar 2018, at 17:47, Seth Hillbrand <seth.hillbrand@xxxxxxxxx <mailto:seth.hillbrand@xxxxxxxxx>> wrote:
>>>>>>
>>>>>> 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 <https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5> shows expected result of 4 threads.  I didn't get OpenMP errors when compiling KiCad although I didn't really notice a substantial difference in speed for the quick tests I was running.  Maybe with more involved operations.
>>>>>>
>>>>>> I'm not sure if this will require us to distribute a different libstdc++ with KiCad.  Probably.  Does that seem feasible to the packing team?
>>>>>>
>>>>>> -S
>>>>>>
>>>>>> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>>:
>>>>>> 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 wrong with that?
>>>>>>
>>>>>>> On 1. Mar 2018, at 16:11, Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> wrote:
>>>>>>>
>>>>>>> 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 <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>> wrote:
>>>>>>>>
>>>>>>>> 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 <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>> wrote:
>>>>>>>>>
>>>>>>>>> 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 write or own.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> <3d-view-no-raytrace.png><3d-view-with-raytrace.png>_______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>