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 OK? Bernhard > On 4. Mar 2018, at 20:20, Wayne Stambaugh <stambau...@gmail.com> 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 <stegma...@sw-systems.de> >>>> 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.hillbr...@gmail.com >>>>> <mailto:seth.hillbr...@gmail.com>> 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 <stegma...@sw-systems.de >>>>> <mailto:stegma...@sw-systems.de>>: >>>>> 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 <j...@rokeby.ie >>>>>> <mailto:j...@rokeby.ie>> 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 <stegma...@sw-systems.de >>>>>>> <mailto:stegma...@sw-systems.de>> 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.wlostow...@cern.ch >>>>>>>> <mailto:tomasz.wlostow...@cern.ch>> 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@lists.launchpad.net >>>>>>>> <mailto:kicad-developers@lists.launchpad.net> >>>>>>>> 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@lists.launchpad.net >>>>> <mailto:kicad-developers@lists.launchpad.net> >>>>> 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@lists.launchpad.net >>>>> <mailto:kicad-developers@lists.launchpad.net> >>>>> 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@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
