View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0024826CommunityOCCT:Foundation Classespublic2014-04-14 10:162016-09-08 21:34
ReporterIstvan Csanady Assigned Tobugmaster  
PrioritynormalSeverityfeature 
Status closedResolutionfixed 
Target Version6.9.0Fixed in Version6.9.0 
Summary0024826: Wrapping of parallelisation algorithms
DescriptionAs an OCCT user I would find it useful, to have the Intel TBB parallelisation methods wrapped in the TKernel framework, to be able to support different multithreading libraries such as Grand Central Dispatch on OSX, and to be able to use these wrappers in a uniform way.

Note: currently parallel_for_each is used in the BRepMesh meshing algorithm, and the parallel_for is used in the "Parallelization FillDS part of BO" story. It is pretty easy to provide such constructs with GCD, as I mentioned in this forum thread: http://dev.opencascade.org/index.php?q=node/909
Providing a C++ interface with a factory method would be nice, but a simple macro like solution (like in the BOPCol_TBB.hxx) could be useful as well. Also see this forum topic, and the references in it: https://groups.google.com/forum/#!searchin/oce-dev/gcd/oce-dev/l8wU6mpZtlA/WJNzd244xr8J
Steps To Reproducenot applicable
TagsNo tags attached.
Test case numberNot needed

Attached Files

  • CR24826-perf_01.xls (14,336 bytes)
  • CR24826-perf_02.xls (14,336 bytes)

Relationships

related to 0021961 closedpdn Open CASCADE Paralleling BRepMesh using Intel TBB tools 
related to 0024639 closedmkv Open CASCADE Parallelization FillDS part of BO 
related to 0022146 closedabv Open CASCADE Foundation Classes - Integration of OCC in-house parallelization tool 
parent of 0025801 closedbugmaster Open CASCADE Some of the commands in BOPTest packages show the execution time without -t key 
related to 0025545 closedbugmaster Community TopLoc_Location::Transformation() provokes data races 

Activities

kgv

2014-04-15 14:15

developer   ~0028844

Just to notice - parallel_for is used also in OpenGl_RaytraceGeometry.

Istvan Csanady

2014-04-25 13:47

developer   ~0029073

Just an example to show how simple it is to write a parallel_for_each with the dispatch API:
    dispatch_group_t syncGroup = dispatch_group_create();
    for (auto iter : container)
    {
        dispatch_group_async(syncGroup, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
            process(iter)
        });
    }
    dispatch_group_wait(syncGroup, DISPATCH_TIME_FOREVER);

git

2014-08-19 10:46

administrator   ~0030869

Branch CR24826 has been created by azn.

SHA-1: 6bfc8cbce36add7026719a1ab205b819f0892441


This branch includes the following new commits:

       new 6bfc8cb 0024826: Wrapping of parallelisation algorithms 0022146: Integration of OCC in-house parallelization tool


Detailed log of new commits:

commit 6bfc8cbce36add7026719a1ab205b819f0892441
Author: azn
Date: Tue Aug 19 10:44:01 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    0022146: Integration of OCC in-house parallelization tool
    
    - Added new structures and wrappers for parallelization.

git

2014-09-19 11:02

administrator   ~0031884

Branch CR24826 has been updated by azn.

SHA-1: 33adb1b9f3c5014f006f075dc6338f7a3738187b


Detailed log of new commits:

Author: azn
Date: Fri Sep 19 11:01:15 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    
    - Implement ParallelForEach parallel primitive.

git

2014-09-25 12:03

administrator   ~0032124

Branch CR24826 has been updated by azn.

SHA-1: a012b30ef8408108535470117798d1cbabe3d346


Detailed log of new commits:

Author: azn
Date: Thu Sep 25 12:03:05 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    
    - Implementation of alternative parallel primitives to BRepMesh and BOP modules.

dbp

2014-09-29 11:22

developer   ~0032287

Last edited: 2014-09-29 11:23

 Dear azn,

Please consider the following remarks:

//! Returns mutex instance.
static Standard_Mutex& mutex()
{
  static Standard_Mutex aMutex;
  return aMutex;
}

Here the static variable is used, thus it is shared over all instances of class Range.Therefore, execution of one task can affect on the execution of another task. You probably should use mutable member variable for mutex.

//! Returns first non processed element or end.
//! Thread-safe method.
Value It() const
{
  Standard_Mutex::Sentry aMutex( mutex() );
  return ( myIt != myEnd ) ? myIt++ : myEnd;
}

It is ok for heavy tasks. Hovewer, for small tasks (i.e., transformation of millions of vertices according to some matrix) syncronization overhead can be too high (performance can degrade significantly). For many collections (like vector, array, ...) we can use atomics, which are almost free.

static Standard_Address Run(Standard_Address theTask)

Can we use explicit type for the argument (Task<Functor, InputIterator>)?

Also please check code style in your patch (the are several inaccuracies with brackets and naming conventions: ( mutex() ), i, ...).

The separate question is about test code (ParallelTest_Calculator in QABugs_19.cxx). We probably demonstrate where this functionality should NOT be used. Calculations are too simple to get any performance boost. It is interesting to show several examples of tasks (of different complexity) and measure actual acceleration in each case. Also it would be great to compare performance of our solution with OpenMP and Intel TBB for some widely used example (saxpy is a good choice). We need to understand the efficiency of our solution to ensure proper use in various problems.

kgv

2014-09-29 23:03

developer   ~0032340

Last edited: 2014-09-29 23:04

 
+aNumLogicalProcessors = (Standard_Integer)sysconf(_SC_NPROCESSORS_ONLN);

please notice that this does not work as expected on Android platform - current implementation of sysconf returns random number of active (not in power-safe suspended mode) cores.
There is workaround based on parsing "/sys/devices/system/cpu/present" and "/sys/devices/system/cpu/possible" from sysfs.

git

2014-10-01 13:14

administrator   ~0032503

Branch CR24826 has been updated by azn.

SHA-1: ab8d390727f4ddb99fafdb7b55b8ed2e1a9c106c


Detailed log of new commits:

Author: azn
Date: Wed Oct 1 13:12:18 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    
    Simple parallelization primitives for the loops "for" and "foreach" were implemented.
    This realization is based on the templates. Therefore the next functor-interface should be realized:
    
    // Example
    class Functor
    {
    public:
      void operator() ([proccesing instance]) const
      {
        //...
      }
    };
    
    These primitives wrap tbb::parallel_for and tbb::parallel_for_each interfaces if TBB library is used.
    All parts of OCC code which are using tbb were changed on new primitives.

git

2014-10-03 12:58

administrator   ~0032620

Branch CR24826 has been updated forcibly by azn.

SHA-1: 6c0b0abb1b3543ee656845100b45c032ce4944a1

git

2014-10-03 13:08

administrator   ~0032622

Branch CR24826 has been updated forcibly by azn.

SHA-1: 7a076286d5b39dfef41c89a9eb0db88dddfc07db

abv

2014-10-15 15:59

manager   ~0033146

Some remarks:

- In BRepMesh_WireInterferenceChecker, Standard_Mutex::Sentry is created inside if{} where it does not have sense, please correct
- Class OSD_Parallel does not have description, please provide

git

2014-12-03 17:08

administrator   ~0034975

Branch CR24826 has been updated forcibly by azn.

SHA-1: c3b77c3acc31ab1c19a901b83a683be372857d10

kgv

2014-12-03 20:38

developer   ~0034985 

+  if ( trheArgc != 2 )
+  {
+    theDI << "Usage: "
+          << theArgv[0]
+          << " vec_length\n";
+    return 0;

wrong syntax should be treated as error - command should return 1 and use std::cout to report error. Please also use theDI.PrintHelp().

+  Standard_Integer aLength = atoi(theArgv[1]);

Draw::Atoi() should be used instead.

+  theCommands.Add ("OCC24826,", "Usage: OCC24826 vec_length", __FILE__, OCC24826, group);

this is not applicable adding new command without description.

+  //! Simple primitive for parallelization of "for" loops.
+  template <typename Functor>
+  static Standard_EXPORT void ParallelFor( const Standard_Integer theBegin,
+                                           const Standard_Integer theEnd,
+                                           const Functor&         theFunctor );

inline methods can not be exported

+  //! Returns number of logical proccesrs.
+  static Standard_EXPORT Standard_Integer getCountLogicalProcessors();

why it is private? The name "NbLogicalProcessors" would be better.

+    mutable Value          myIt;    //!< First non processed elemnt of range.

elemnt -> element

+
+class OSD_Parallel
+{

should not be this class documented?

--- /dev/null
+++ b/src/OSD/OSD_Parallel.cxx
@@ -0,0 +1,77 @@
+#include <OSD_Parallel.hxx>
+

file header is missing.

--- a/src/MeshTest/MeshTest_PluginCommands.cxx
+++ b/src/MeshTest/MeshTest_PluginCommands.cxx
@@ -83,7 +83,6 @@ void MeshTest::PluginCommands(Draw_Interpretor& theCommands)
     __FILE__, mpparallel, g);
   theCommands.Add("triarea","shape [eps]  (computes triangles and surface area)",__FILE__, triarea, g);
   theCommands.Add("tricheck", "shape   (checks triangulation of shape)", __FILE__, tricheck, g);
-

unrelated change.

Please provide some numbers for comparison between tbb / built-in replacement on several scenarios for BRepMesh and ray-tracing (ask Denis for test cases).

git

2014-12-05 18:39

administrator   ~0035084

Branch CR24826 has been updated forcibly by azn.

SHA-1: abb6e1de602e6c1bd631354475763d5913711026

msv

2014-12-08 13:37

developer   ~0035128

The parallel framework developed in scope of this bug is to be applied to the command OCC25545, so as to make it functioning in absence of TBB.

msv

2014-12-09 03:06

developer   ~0035177

I have had a look at the branch. I have the following remark, though may be it concerns not the changes of this branch but the initial code:

File BOPCol_Parallel.hxx
In the method BOPCol_ContextCnt::Perform, when bRunParallel is true, context is not passed to aFunctor.

abv

2014-12-10 14:30

manager   ~0035262

Mikhail, the code in BOPCol_ContextCnt::Perform() should be Ok -- I have checked that with Eugene some time ago (on first version of the fix).

msv

2014-12-11 12:03

developer   ~0035314

I have found the following problem with suggested wrapping mechanism.
Let's turn again to the file BOPCol_Parallel.hxx, which replaces the file BOPCol_TBB.hxx.
The body of the old class BOPCol_TBBContextFunctor had the following declaration:

  void operator()( const flexible_range<Standard_Integer>& aBR ) const;

The body of its replacement BOPCol_ContextFunctor is the following:

  void operator()( const Standard_Integer theIndex ) const;

So, the body of the old functor could work out a range of items in one thread run. And the new functor can work out only one item in one run.

The class IntTools_Context that plays the role of TypeContext parameter of the template is not thread-safe because it provides its services using non thread-safe data map containers. This thread-dangerous nature of the context is the cause why it is not passed to the functor in parallel mode.

So, in each run of functor body the new instance of context is created. And if in the old version it was done once for a range of items in new version it is done for each item. So, we can anticipate a significant downgrade of performance depending on shapes complexity.

The better way is to provide thread-safety of IntTools_Context and to pass the same instance of it in all thread runs.

To my mind, we are too hurry when implement wrapping mechanism without providing thread-safe containers. The better way would be to provide wrapping to implementation of thread-safe containers (TBB has a good set of them), so that to be ready to solve the problems like we have with IntTools_Context.

All in all, we must not permit downgrade of performance of OCCT code. So, I suggest that the certification of the patch for this bug will include special set of tests that involve parallel computation of BOP on complex shapes (at least the set that was used during implementation of parallelization of BOP).

msv

2014-12-11 16:40

developer   ~0035339

The set of tests for performance measurements please get from the post of PKV in the following page: http://dev.opencascade.org/index.php?q=node/718#comment-362

oan

2014-12-17 13:13

developer   ~0035458

Last edited: 2014-12-17 13:15

 Dear Mikhail,

your remark concerning IntTools_Context and possible slowdown is quite correct. However, introducing of thread-safe containers will not solve all possible problems with data races. What I mean:
I figured out that IntTools_ShrunkRange contains calls to IntTools_Context::ComputeVE that uses cached GeomAPI_ProjectPointOnCurve; IntTools_EdgeFace contains calls to IntTools_Context::IsValidPointForFace which uses cached GeomAPI_ProjectPointOnCurve; both of these classes are used in parallel that means possiblity that context of GeomAPI_ProjectPointOnCurve or GeomAPI_ProjectPointOnCurve can be corrupted during their using in parallel threads. In this case even if we wrapped data maps used in IntTools_Context, described problem will remain the hot point. This situation does not appear in old version as far as the same context is used for range of items processed in a single thread. As a solution, some protection can be impemented for particular tool, however this means creation of N * M mutexes, where N is number of shapes, M is number of tools related to this shape. So, it seems not a good idea.

Additionally, using of TBB as well as another framework providing such services is optional for OCCT and force using of TBB containers introduces unnecessary strict dependency. Hence, somehow or other we should take care to protect native OCCT containers, however such protection should be impemented on the level where the problem can occur.

As a result, IMHO, in this case it seems as an unavoidable victim if we want to introduce unified parallelization tool within OCCT.

Additional question to discuss: what the reason to maintain two pairs of similar methods ParallelForEach - ForEach and ParallelFor - For in class which name (OSD_Parallel) explicitely hints to parallel services implemented there, is not it a buttery butter? I suggest to remove existing ForEach and For methods, move their functionality to corresponding parallel ones, add new parameter isForceSingleThreadExecution with default value equal FALSE and remove prefix "Parallel". So, we will obtain quite logical OSD_Parallel::ForEach() instead of OSD_Parallel::ParallelForEach(), for instance.

msv

2014-12-22 10:28

developer   ~0035541

We shouldn't allow performance downgrade of the code. The context was initially introduced to speed up the calculations by creating one instance of a tool and then using it many times. With the proposed patch, this approach will be broken. It is not a good way to bring a well working approach as a victim to another improvement, even more so there is a way to avoid degradation.
So, I suggest that we first make the context thread-safe before going further in direction of parallelization of BOP related code.

Though TBB is optional product when working with OCCT, it is for the moment the only way to make algorithms running in parallel.

In order to separate unsafe things, it is possible to have one unique thing for each thread. For example, we could create a wrapper over the context, such that creates and uses a unique context for each thread.

Concerning API of OSD_Parallel class, I agree with proposition to leave only For and ForEach.

msv

2014-12-22 10:41

developer   ~0035542

Please continue the work on this issue taking above remarks into account.

git

2014-12-23 14:22

administrator   ~0035594

Branch CR24826 has been updated forcibly by azn.

SHA-1: ae1305a47f1c7236695e5f1e8d49c2c7084d74ae

git

2014-12-23 16:31

administrator   ~0035612

Branch CR24826 has been updated by azn.

SHA-1: d03f01013d24c17665ae7042f05cf80fa5c1fbd4


Detailed log of new commits:

Author: azn
Date: Tue Dec 23 16:31:43 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Fixes in Context Functor.

git

2014-12-24 07:53

administrator   ~0035643

Branch CR24826 has been updated forcibly by azn.

SHA-1: 3b31bdef60b74427df6df9126825974e412223f9

azn

2014-12-24 08:43

developer   ~0035644

Last edited: 2014-12-24 08:55

 I have prepared a small fix in which the context is initialized one time for each thread. It is allow to avoid performance downgrade (sometimes performance will better). In such a way this approach allows to integrate OSD_Parallel in OCCT.

But I agree that it more correct to have a thread-safety on the level of the context as it allows to increase performance and reduce memory requirements in further. But this issue may be implemented in the context of other bug-track record.

azn

2014-12-24 08:49

developer   ~0035645

Dear Mikhail,
Please review current changes.
- BOPCol_Parallel.hxx (BOP context issue)
- OSD_Parallel.hxx (API changes of ParallelFor and ParallelForEach)

msv

2014-12-25 10:58

developer   ~0035705

Remarks were given verbally.

msv

2014-12-25 11:01

developer   ~0035706

In general, the proposed fix looks more better than the previous, as it does not lead to creation of context tool in each call to functor body.
So, I agree to test and integrate it. And then create additional bug track item to make context thread safe.

git

2014-12-25 15:09

administrator   ~0035721

Branch CR24826 has been updated by azn.

SHA-1: 80aaf95ede3c516873d31d86e0aed75d12939084


Detailed log of new commits:

Author: azn
Date: Thu Dec 25 15:08:46 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Small fixes.

git

2014-12-26 13:10

administrator   ~0035751

Branch CR24826 has been updated by azn.

SHA-1: 7fda8a503ea15dd7f0480594086252767f415fa6


Detailed log of new commits:

Author: azn
Date: Fri Dec 26 13:09:45 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Small fixes.

msv

2014-12-26 16:46

developer   ~0035769

No more remarks. Please test.

msv

2014-12-26 16:51

developer   ~0035770

Also, please test separately and compare performance of tests according to my request http://tracker.dev.opencascade.org/view.php?id=24826#c35339. It is needed that each test case was run alone on a dedicated machine.

git

2014-12-26 17:57

administrator   ~0035779

Branch CR24826_1 has been created by msv.

SHA-1: 1c5fc127104b083b4398bb08c7b4fa9c8b8f0e9b


Detailed log of new commits:

Author: msv
Date: Fri Dec 26 17:05:31 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Simple primitives to parallelize loops type "for" and "foreach" were implemented. The primitives encapsulates complete logic for creating and managing parallel context of loops. Moreover the primitives may be a wrapper for some primitives from 3rd-party library - TBB.
    
    To use it is necessary to implement TBB like interface which is based on functors. For example:
    
    Class Functor
    {
    public:
      void operator() ([proccesing instance]) const
      {
        //...
      }
    };
    
    In the body of the operator () should be implemented thread-safe logic of computations that can be performed in parallel context. If parallelized loop iterates on the collections with direct access by index (such as Vector, Array), it is more efficient to use the primitive ParallelFor (because it has no critical section).
    
    All parts of OCC code which are using tbb were changed on new primitives.

msv

2014-12-26 17:58

developer   ~0035780

I have rebased CR24826_1 on master.

apv

2015-01-12 14:26

tester   ~0035956

Dear BugMaster,

Branch CR24826_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
SHA-1: 1c5fc127104b083b4398bb08c7b4fa9c8b8f0e9b

Number of compiler warnings:
occt component:
   Linux: 18 (18 on master)
   Windows: 0 (0 on master)
products component :
   Linux: 11 (11 on master)
   Windows: 1 (1 on master)
There is a problem with building of CR24826_1 on MacOS:
/Users/mnt/tools/WOK680/wok_entities/LOC/dev/CR24826-1-master-occt/inc/BOPCol_Parallel.hxx:90:21: error: static_cast from 'Standard_ThreadId' (aka '_opaque_pthread_t *') to 'size_t' (aka 'unsigned long') is not allowed

Regressions/Differences:
Not detected

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 369003916 / 369143040
Total CPU difference: 49313.14000000019 / 46134.27000000006

Testing on Windows:
Total MEMORY difference: 276191868 / 276918412
Total CPU difference: 35455.875 / 38326.15625

msv

2015-01-12 16:31

developer   ~0035968

Dear azn, please correct the error.

git

2015-01-21 16:11

administrator   ~0036336

Branch CR24826_1 has been updated forcibly by azn.

SHA-1: ae517975e04b90fe84fad5c60266340a227b49a9

git

2015-01-27 08:08

administrator   ~0036683

Branch CR24826_1 has been updated forcibly by azn.

SHA-1: 63af1e28b6a46249c533b6f46f6ffb0d35adea91

azn

2015-01-27 08:08

developer   ~0036684

Dear Mikhail,
Compilation errors have been corrected. Branch has been rebased on new master. Please update status of this ticket and send on the test.

msv

2015-01-27 11:11

developer   ~0036690

Alexander, I think the line OSD_Parallel.hxx:144 contains error ("->" vs ".").

git

2015-01-29 09:38

administrator   ~0036793

Branch CR24826_1 has been updated by azn.

SHA-1: e30c8b8a17c0a1e3dad85a925dae2e5ac6d93a45


Detailed log of new commits:

Author: azn
Date: Thu Jan 29 09:36:34 2015 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Small fix.

msv

2015-01-29 10:53

developer   ~0036796

Reviewed.
Please, test. I would like to remind:

Also, please test separately and compare performance of tests according to my request 0024826:0035339. It is needed that each test case was run alone on a dedicated machine.

git

2015-01-30 17:47

administrator   ~0036929

Branch CR24826_1 has been updated forcibly by apv.

SHA-1: b22a2191a632f970b55c1c5a4cf6187a6a36bc63

apv

2015-01-30 17:51

tester   ~0036930

Branch CR24826_1 has been rebased on the current master

apv

2015-02-03 18:18

tester  

CR24826-perf_01.xls (14,336 bytes)

apv

2015-02-03 18:19

tester   ~0037035

Dear msv, please have a look at file CR24826-perf_01.xls

msv

2015-02-03 19:20

developer   ~0037039

The content of the file shows that the parallel run performs longer than serial. Something strange. What kind of time you used? Is it CPU time or wall clock time? We need to consider only wall clock time.

apv

2015-02-04 18:02

tester  

CR24826-perf_02.xls (14,336 bytes)

apv

2015-02-04 18:09

tester   ~0037090

Dear msv, please have a look at file CR24826-perf_02.xls. It consists tests execution time comparison between CR24826 and master. Execution time was checked according to pkv's recommendation.

msv

2015-02-04 18:13

developer   ~0037091

Dear apv, thank you for analysis. Now it is obvious for me that the fix does not contain performance regressions.
So, it can be considered as tested.

apv

2015-02-05 11:16

tester   ~0037101

Dear BugMaster,

Branch CR24826_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
SHA-1: b22a2191a632f970b55c1c5a4cf6187a6a36bc63

Number of compiler warnings:
occt component:
   Linux: 18 (18 on master)
   Windows: 0 (0 on master)
products component :
   Linux: 11 (11 on master)
   Windows: 1 (1 on master)

Regressions/Differences:
Not detected

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 369861088 / 370076844
Total CPU difference: 53683.34999999986 / 49863.81000000002

Testing on Windows:
Total MEMORY difference: 275489696 / 276284192
Total CPU difference: 38727.5625 / 36894.109375

git

2015-03-18 13:32

administrator   ~0038489

Branch CR24826 has been deleted by inv.

SHA-1: 7fda8a503ea15dd7f0480594086252767f415fa6

git

2015-03-18 13:32

administrator   ~0038490

Branch CR24826_1 has been deleted by inv.

SHA-1: b22a2191a632f970b55c1c5a4cf6187a6a36bc63

Related Changesets

occt: master c7b59798

2015-02-05 12:49:35

msv


Committer: bugmaster Details Diff		 0024826: Wrapping of parallelisation algorithms

Simple primitives to parallelize loops type "for" and "foreach" were implemented. The primitives encapsulates complete logic for creating and managing parallel context of loops. Moreover the primitives may be a wrapper for some primitives from 3rd-party library - TBB.

To use it is necessary to implement TBB like interface which is based on functors. For example:

Class Functor
{
public:
void operator() ([proccesing instance]) const
{
//...
}
};

In the body of the operator () should be implemented thread-safe logic of computations that can be performed in parallel context. If parallelized loop iterates on the collections with direct access by index (such as Vector, Array), it is more efficient to use the primitive ParallelFor (because it has no critical section).

All parts of OCC code which are using tbb were changed on new primitives.

0024826: Wrapping of parallelisation algorithms

Small fix.		 Affected Issues
0024826
mod - src/BOPAlgo/BOPAlgo_BuilderSolid.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_Builder_2.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_Builder_3.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_2.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_3.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_4.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_5.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_6.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_7.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_PaveFiller_9.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_ShellSplitter.cxx Diff File
mod - src/BOPAlgo/BOPAlgo_WireSplitter.cxx Diff File
add - src/BOPCol/BOPCol_Parallel.hxx Diff File
rm - src/BOPCol/BOPCol_TBB.hxx Diff File
mod - src/BOPCol/FILES Diff File
mod - src/BOPDS/BOPDS_Iterator.cxx Diff File
mod - src/BOPTest/BOPTest_CheckCommands.cxx Diff File
rm - src/BOPTest/BOPTest_Chronometer.hxx Diff File
mod - src/BOPTest/BOPTest_PartitionCommands.cxx Diff File
mod - src/BOPTest/FILES Diff File
mod - src/BOPTools/BOPTools_AlgoTools_1.cxx Diff File
mod - src/BRepMesh/BRepMesh_FastDiscret.cxx Diff File
mod - src/BRepMesh/BRepMesh_IncrementalMesh.cxx Diff File
mod - src/BRepMesh/BRepMesh_WireChecker.cxx Diff File
mod - src/BRepMesh/BRepMesh_WireInterferenceChecker.cxx Diff File
mod - src/BRepMesh/BRepMesh_WireInterferenceChecker.hxx Diff File
mod - src/MeshTest/MeshTest_PluginCommands.cxx Diff File
mod - src/OpenGl/OpenGl_SceneGeometry.cxx Diff File
mod - src/OSD/EXTERNLIB Diff File
mod - src/OSD/FILES Diff File
add - src/OSD/OSD_Parallel.cxx Diff File
add - src/OSD/OSD_Parallel.hxx Diff File
mod - src/QABugs/QABugs_19.cxx Diff File
mod - src/QANCollection/QANCollection_Stl.cxx Diff File

Issue History

Date Modified Username Field Change
2014-04-14 10:16 Istvan Csanady New Issue
2014-04-14 10:16 Istvan Csanady Assigned To => abv
2014-04-14 11:48 szv Description Updated
2014-04-15 14:15 kgv Note Added: 0028844
2014-04-15 14:20 kgv Relationship added related to 0021961
2014-04-15 14:21 kgv Relationship added related to 0024639
2014-04-25 13:47 Istvan Csanady Note Added: 0029073
2014-08-05 12:22 abv Assigned To abv => azn
2014-08-05 12:22 abv Status new => assigned
2014-08-05 12:22 abv Target Version => 6.8.0
2014-08-05 12:28 abv Relationship added related to 0022146
2014-08-19 10:46 git Note Added: 0030869
2014-09-11 10:24 abv Target Version 6.8.0 => 7.1.0
2014-09-19 11:02 git Note Added: 0031884
2014-09-25 12:03 git Note Added: 0032124
2014-09-29 11:22 dbp Note Added: 0032287
2014-09-29 11:23 dbp Note Edited: 0032287
2014-09-29 23:03 kgv Note Added: 0032340
2014-09-29 23:04 kgv Note Edited: 0032340
2014-10-01 13:14 git Note Added: 0032503
2014-10-03 12:58 git Note Added: 0032620
2014-10-03 13:08 git Note Added: 0032622
2014-10-08 15:40 azn Assigned To azn => abv
2014-10-08 15:40 azn Status assigned => resolved
2014-10-15 15:59 abv Note Added: 0033146
2014-12-03 17:08 git Note Added: 0034975
2014-12-03 20:38 kgv Note Added: 0034985
2014-12-03 20:38 kgv Assigned To abv => azn
2014-12-03 20:38 kgv Status resolved => assigned
2014-12-05 18:39 git Note Added: 0035084
2014-12-08 13:34 msv Relationship added related to 0025545
2014-12-08 13:37 msv Note Added: 0035128
2014-12-09 03:06 msv Note Added: 0035177
2014-12-10 14:30 abv Note Added: 0035262
2014-12-11 12:03 msv Note Added: 0035314
2014-12-11 16:40 msv Note Added: 0035339
2014-12-17 13:13 oan Note Added: 0035458
2014-12-17 13:13 oan Assigned To azn => msv
2014-12-17 13:13 oan Status assigned => feedback
2014-12-17 13:15 oan Note Edited: 0035458
2014-12-22 10:28 msv Note Added: 0035541
2014-12-22 10:41 msv Note Added: 0035542
2014-12-22 10:41 msv Assigned To msv => azn
2014-12-22 10:41 msv Status feedback => assigned
2014-12-23 14:22 git Note Added: 0035594
2014-12-23 16:31 git Note Added: 0035612
2014-12-24 07:53 git Note Added: 0035643
2014-12-24 08:43 azn Note Added: 0035644
2014-12-24 08:49 azn Note Added: 0035645
2014-12-24 08:50 azn Assigned To azn => msv
2014-12-24 08:55 azn Note Edited: 0035644
2014-12-25 10:57 msv Assigned To msv => azn
2014-12-25 10:58 msv Note Added: 0035705
2014-12-25 11:01 msv Note Added: 0035706
2014-12-25 15:09 git Note Added: 0035721
2014-12-26 07:24 azn Assigned To azn => msv
2014-12-26 13:10 git Note Added: 0035751
2014-12-26 16:44 msv Status assigned => resolved
2014-12-26 16:44 msv Steps to Reproduce Updated
2014-12-26 16:46 msv Note Added: 0035769
2014-12-26 16:46 msv Assigned To msv => bugmaster
2014-12-26 16:46 msv Status resolved => reviewed
2014-12-26 16:51 msv Note Added: 0035770
2014-12-26 17:04 mkv Assigned To bugmaster => apv
2014-12-26 17:57 git Note Added: 0035779
2014-12-26 17:58 msv Note Added: 0035780
2015-01-12 14:26 apv Note Added: 0035956
2015-01-12 14:26 apv Assigned To apv => msv
2015-01-12 14:26 apv Status reviewed => assigned
2015-01-12 14:26 apv Test case number => Not needed
2015-01-12 16:31 msv Assigned To msv => azn
2015-01-12 16:31 msv Note Added: 0035968
2015-01-21 16:11 git Note Added: 0036336
2015-01-27 08:08 git Note Added: 0036683
2015-01-27 08:08 azn Note Added: 0036684
2015-01-27 08:08 azn Assigned To azn => msv
2015-01-27 08:08 azn Status assigned => resolved
2015-01-27 11:11 msv Note Added: 0036690
2015-01-27 11:11 msv Assigned To msv => azn
2015-01-27 11:11 msv Status resolved => assigned
2015-01-29 09:38 git Note Added: 0036793
2015-01-29 09:39 azn Assigned To azn => msv
2015-01-29 09:39 azn Status assigned => resolved
2015-01-29 10:53 msv Note Added: 0036796
2015-01-29 10:53 msv Assigned To msv => bugmaster
2015-01-29 10:53 msv Status resolved => reviewed
2015-01-30 14:45 mkv Assigned To bugmaster => apv
2015-01-30 17:47 git Note Added: 0036929
2015-01-30 17:51 apv Note Added: 0036930
2015-02-03 18:18 apv File Added: CR24826-perf_01.xls
2015-02-03 18:19 apv Note Added: 0037035
2015-02-03 18:19 apv Assigned To apv => msv
2015-02-03 18:19 apv Status reviewed => feedback
2015-02-03 19:20 msv Assigned To msv => apv
2015-02-03 19:20 msv Note Added: 0037039
2015-02-04 18:02 apv File Added: CR24826-perf_02.xls
2015-02-04 18:09 apv Note Added: 0037090
2015-02-04 18:09 apv Assigned To apv => msv
2015-02-04 18:13 msv Note Added: 0037091
2015-02-04 18:14 msv Assigned To msv => apv
2015-02-04 18:14 msv Status feedback => acknowledged
2015-02-04 18:14 msv Status acknowledged => reviewed
2015-02-05 11:16 apv Note Added: 0037101
2015-02-05 11:16 apv Assigned To apv => bugmaster
2015-02-05 11:16 apv Status reviewed => tested
2015-02-06 15:38 bugmaster Changeset attached => occt master c7b59798
2015-02-06 15:38 bugmaster Status tested => verified
2015-02-06 15:38 bugmaster Resolution open => fixed
2015-02-06 18:10 emv Relationship added parent of 0025801
2015-02-09 11:04 bugmaster Target Version 7.1.0 => 6.9.0
2015-03-18 13:32 git Note Added: 0038489
2015-03-18 13:32 git Note Added: 0038490
2015-05-14 15:29 aiv Status verified => closed
2015-05-14 15:32 aiv Fixed in Version => 6.9.0