G-API: Implement concurrent executor #24845

TolyaTalamanov · 2024-01-10T15:31:07Z

Overview

This PR introduces the new G-API executor called GThreadedExecutor which can be selected when the GComputation is compiled in serial mode (a.k.a GComputation::compile(...))

ThreadPool

cv::gapi::own::ThreadPool has been introduced in order to abstract usage of threads in GThreadedExecutor.
ThreadPool is implemented by using own::concurrent_bounded_queue

ThreadPool has only as single method schedule that will push task into the queue for the further execution.
The important notice is that if Task executed in ThreadPool throws exception - this is UB.

GThreadedExecutor

The GThreadedExecutor is mostly copy-paste of GExecutor, should we extend GExecutor instead?

Implementation details

Build the dependency graph for Island nodes.
Store the tasks that don't have dependencies into separate vector in order to run them first.
at the GThreadedExecutor::run() schedule the tasks that don't have dependencies that will schedule their dependents and wait for the completion.

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

I agree to contribute to the project under Apache 2 License.
To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
The PR is proposed to the proper branch
There is a reference to the original bug report and related work
There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
The feature is well documented and sample code can be built with the project CMake

TolyaTalamanov · 2024-01-10T15:32:13Z

modules/gapi/test/gapi_sample_pipelines.cpp

@@ -513,4 +515,23 @@ TEST(GAPI_Pipeline, 1DMatWithinSingleIsland)
    EXPECT_EQ(0, cv::norm(out_mat, ref_mat));
 }

+TEST(GAPI_Pipeline, NewExecutorTest)


Was a temp test, need to remove

TolyaTalamanov · 2024-01-10T15:42:01Z

modules/gapi/src/executor/thread_pool.cpp

+
+#include "thread_pool.hpp"
+
+#include <iostream>


modules/gapi/src/executor/thread_pool.cpp

TolyaTalamanov · 2024-01-11T10:45:04Z

modules/gapi/src/executor/thread_pool.cpp

+
+void cv::gapi::own::WaitGroup::wait() {
+    while (task_counter.load() != 0u) {
+        std::unique_lock<std::mutex> lk{m};


Definitely shouldn't be in loop...

modules/gapi/src/executor/gexecutor.cpp

…rent-executor

…rent-executor-tmp

TolyaTalamanov · 2024-01-12T10:19:47Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+namespace magazine {
+namespace {
+
+void bindInArgExec(Mag& mag, const RcDesc &rc, const GRunArg &arg)


This part is pure copy-paste from gexecutor.cpp, perhaps it should be somewhere in common (e.g gcommon.hpp)

TolyaTalamanov · 2024-01-12T10:21:34Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    }
+}
+
+void assignMetaStubExec(Mag& mag, const RcDesc &rc, const cv::GRunArg::Meta &meta) {


@dmatveev This is the place where meta is stored into Mag. I assume there might be some data race that's why Mag is currently protected by mutex.

there won't be a race if we statically preallocate the magazine for all relevant [rc.id]s in all relevant types, but the mutex is fine and we can do that later.

Left mutex so far

TolyaTalamanov · 2024-01-12T10:24:25Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+
+    virtual StreamMsg get() override
+    {
+        std::lock_guard<std::mutex> lock{m_mutex};


Removing lock causes the data race even though magazine::getArg is supposed to be a read operation

TolyaTalamanov · 2024-01-12T10:26:32Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    void meta(const GRunArgP &out, const GRunArg::Meta &m) override
+    {
+        const auto idx = out_idx.at(cv::gimpl::proto::ptr(out));
+        std::lock_guard<std::mutex> lock{m_mutex};


I assume it's impossible that two Island's write to the same memory in parallel but it caused data race if mutex isn't used

TolyaTalamanov · 2024-01-12T10:30:49Z

modules/gapi/src/executor/gthreadedexecutor.hpp

+
+    void run();
+    void verify();
+    std::shared_ptr<GIslandExecutable> exec() { return m_isl_exec; }


exec() is redundant for IslandActor, in fact GIslandExecutable::Ptr can be stored & accessed in GThreadedExecutor and passed to IslandActor by pointer/reference.

Please, leave a comment in code

TolyaTalamanov · 2024-01-12T10:36:58Z

modules/gapi/src/executor/thread_pool.cpp

+#include <opencv2/gapi/util/throw.hpp>
+
+void cv::gapi::own::WaitGroup::add() {
+    std::lock_guard<std::mutex> lk{m};


In fact it's not necessarily to acquire the mutex on add() method, task_counter might be an atomic.

But since we still need the mutex for wait (as it's uses condvar) atomic + mutex seems the weird combination and didn't give any significant performance improvements. Decided to keep it simple so far.

If fact WaitGroup can be implemented without condvar and mutex by using 2 atomics. But it requires c++20 for this thing: https://en.cppreference.com/w/cpp/atomic/atomic/wait

WaitGroup has been removed

TolyaTalamanov · 2024-01-12T10:39:52Z

modules/gapi/src/executor/thread_pool.cpp

+    }
+}
+
+void cv::gapi::own::ThreadPool::schedule(cv::gapi::own::ThreadPool::Task task) {


ThreadSanitizer also signals problems when schedule is called from different threads but it seems to be fine since both WaitGroup::add() and Queue::push are supposed to be thread-safe

TolyaTalamanov · 2024-01-12T10:40:47Z

modules/gapi/src/executor/thread_pool.cpp

+void cv::gapi::own::ThreadPool::stop() {
+    wait();
+    for (uint32_t i = 0; i < m_num_workers; ++i) {
+        m_queue.push({});


Empty task - termination criterion for the worker, at least worth a comment...

TolyaTalamanov · 2024-01-12T10:41:09Z

modules/gapi/src/executor/thread_pool.hpp

+
+#include <opencv2/gapi/own/exports.hpp> // GAPI_EXPORTS
+
+#if defined(HAVE_TBB)


Yet another copy-paste of this thing

TolyaTalamanov · 2024-01-12T13:24:01Z

modules/gapi/include/opencv2/gapi/gcommon.hpp

+ *
+ * Specifies a number of threads that should be used by executor.
+ */
+struct use_threaded_executor


Should be exposed into python later

dmatveev · 2024-01-12T13:23:02Z

modules/gapi/include/opencv2/gapi/gcommon.hpp

+ */
+struct use_threaded_executor
+{
+    explicit use_threaded_executor(uint32_t nthreads = std::thread::hardware_concurrency())


probably here we should stick to the OpenCV thread settings: https://docs.opencv.org/4.9.0/db/de0/group__core__utils.html#ga2db334ec41d98da3129ef4a2342fc4d4

...but normally it is needed to respond/handle to the setNumThreads() which sets # of threads to OpenCV globally (as it is still a set of standalone functions)

Good point, I think we can use cv::getNumThreads() there instead. Done

dmatveev · 2024-01-12T16:55:37Z

modules/gapi/CMakeLists.txt

    src/executor/gstreamingexecutor.cpp
    src/executor/gasync.cpp
+    src/executor/thread_pool.cpp


is it a third thread pool in this only module? :)

I guess you refer to RequestPool's from ie and ov backends.

dmatveev · 2024-01-12T16:56:32Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    switch (arg.index())
+    {
+    case GRunArg::index_of<Mat>() :
+        mag_rmat = make_rmat<RMatOnMat>(util::get<Mat>(arg)); break;


normally we have break in the following line

(or the whole case ...: ...; break in a single line)

It's just a copy-paste from gexecutor.cpp but no problem to address it :)

dmatveev · 2024-01-12T16:59:34Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    }
+}
+
+void assignMetaStubExec(Mag& mag, const RcDesc &rc, const cv::GRunArg::Meta &meta) {


there won't be a race if we statically preallocate the magazine for all relevant [rc.id]s in all relevant types, but the mutex is fine and we can do that later.

dmatveev · 2024-01-12T17:11:13Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    cv::gimpl::Mag &mag;
+    std::mutex     &m_mutex;


I believe it is an abstraction leak to expose 1) a data structure and 2) its protection mutex by a reference to some external context like this.

If the goal of this whole stub is to populate an input vector for an island, you can query the object who owns those two (a magazine and a mutex) to do that for you. Then this thread safety concern falls to that context. So what you could do instead is to have a GraphState structure - representing a running graph - and host the magazine in.

The pro of this way is that later you may have a single executor serving multiple executable graphs - to their state will be clearly separated one from another.

dmatveev · 2024-01-12T17:44:30Z

modules/gapi/src/executor/thread_pool.cpp

+    }
+}
+
+static thread_local cv::gapi::own::ThreadPool* current;


doesn't look good tbh :)

Quite handy though, user doesn't need to keep ThreadPool for scheduling nested tasks.

static void foo() { // do something ThreadPool::get()->schedule(bar); }; static void bar() { // do something ThreadPool::get()->schedule(baz); } ... ThreadPool tp; tp.schedule(foo);

But if we have plan to make ThreadPool available for all GCompiled's, it can be removed for now

dmatveev · 2024-01-12T17:45:16Z

modules/gapi/src/executor/thread_pool.cpp

+}
+
+void cv::gapi::own::ThreadPool::worker() {
+    current = this;


why do you need current at all?

Answered above

dmatveev · 2024-01-12T17:46:42Z

modules/gapi/src/executor/thread_pool.cpp

+}
+
+void cv::gapi::own::ThreadPool::schedule(cv::gapi::own::ThreadPool::Task task) {
+    m_wg.add();


so you increase you wait count once you schedule a task, and decrease once you're done with it -- why?

The entire WaitGroup are used to implement ThreadPool::wait() that is supposed to block until all scheduled tasks, including nested ones, are completed

not relevant, WaitGroup has been removed

dmatveev · 2024-01-12T17:47:23Z

modules/gapi/src/executor/thread_pool.cpp

+        cv::gapi::own::ThreadPool::Task task;
+        m_queue.pop(task);
+        if (!task) {
+            break;


Does this mean you terminate your worked threads once the graph is done?

The answer is NO, workers are terminated in the ThreadPool::stop that called during GCompiled destruction.

Not it's done in shutdown method which is private and called only in ~ThreadPool()

dmatveev · 2024-01-12T17:48:07Z

modules/gapi/src/executor/thread_pool.cpp

+    }
+}
+
+void cv::gapi::own::ThreadPool::schedule(cv::gapi::own::ThreadPool::Task task) {


Shouldn't this be &&task ?

smirnov-alexey · 2024-01-15T15:10:33Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+}
+
+void cv::gimpl::IslandActor::verify() {
+    if (m_e) {


Can we get a simultaneous read + write situation for the exception? Shouldn't it be protected (e.g. atomic)?

IslandActor itself doesn't give any thread-safe guarantees, besides this method is called only in main thread when all tasks are completed.

smirnov-alexey · 2024-01-15T15:30:52Z

modules/gapi/src/executor/thread_pool.cpp

+            break;
+        }
+        task();
+        m_wg.done();


Do we care if this line can be unreachable due to hang/exception in task above?

It's assumed that task can't throw exception at this point.

Make sense to check it with something like this: static_assert(noexcept(task()))
Since this is available since C++17 only

TolyaTalamanov · 2024-01-16T08:11:43Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+void cv::gimpl::Task::run() {
+    m_f();
+    for (auto* dep : m_dependents) {
+        if (dep->m_ready_deps.fetch_add(1u) == dep->m_num_deps - 1) {


Looks it's not memory_order::seq_cst for sure

…rent-executor

TolyaTalamanov · 2024-01-26T12:47:41Z

modules/gapi/include/opencv2/gapi/gcommon.hpp

@@ -11,6 +11,7 @@
 #include <functional>   // std::hash
 #include <vector>       // std::vector
 #include <type_traits>  // decay
+#include <thread>       // hardware_concurrency


Not needed any more

TolyaTalamanov · 2024-01-26T12:48:46Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    }
+}
+
+void assignMetaStubExec(Mag& mag, const RcDesc &rc, const cv::GRunArg::Meta &meta) {


Left mutex so far

TolyaTalamanov · 2024-01-26T13:25:41Z

@dmatveev Could you have a look one more time, please?

dmatveev · 2024-01-26T15:42:12Z

modules/gapi/include/opencv2/gapi/gcommon.hpp

+    explicit use_threaded_executor(
+            uint32_t nthreads = static_cast<uint32_t>(cv::getNumThreads()))


probably it's not ok to have cv::getNumThreads() called in the header.

Instead, you could introduce two constructors, a default one () with nthreads set to cv::getNumThreads() in its initializer list, and the value-based one.

Can't we just declare it here and move implementation to a cpp file?

Can't we just declare it here and move implementation to a cpp file?
In this case it's needed to call cv::getNumThreads() in header anyway

dmatveev · 2024-01-26T15:43:03Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+void bindInArgExec(Mag& mag, const RcDesc &rc, const GRunArg &arg) {
+    if (rc.shape != GShape::GMAT)
+    {


A strange mix of {, can you please stick to the BSD-style one?

dmatveev · 2024-01-26T15:44:59Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+}
+
+void cv::gimpl::GThreadedExecutor::Output::post(cv::GRunArgP&&, const std::exception_ptr& e) {
+    if (e) { m_eptr = e; }


this is the third indentation style I see in this file

modules/gapi/src/executor/gthreadedexecutor.cpp

dmatveev · 2024-01-26T15:52:47Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    // Notify every consumer about completion one of its dependencies
+    for (auto* consumer : m_consumers) {
+        const auto num_ready =
+            consumer->m_ready_producers.fetch_add(1, std::memory_order_relaxed) + 1;


Why don't u use pre-increment here, again?

only because I specify memory_order there

@TolyaTalamanov did you find out which is the best order here?

It's a good question, I'd say we need to guarantee that the new scheduled task will see all changes in magazine that have been made by its producers which means memory_order_acq_rel.

But since all magazine changes currently synchronized by mutex it's already guaranteed so memory_order_relaxed can be used until we get rid of the mutex on magazine :)

i'd vote for ++(int) still as to a more concise construct. BUT that's up to you

The thing is operator++(int) doesn't accept std::memory_order which isn't default there so I can't use it :)

dmatveev · 2024-01-26T16:00:16Z

No major problems, but I'd expect reviews from other first. If you align the indentation, we can merge this. Thanks!

smirnov-alexey · 2024-01-26T16:16:42Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+
+    // Count the number of last tasks
+    auto isLast = [](const std::shared_ptr<Task>& task) { return task->isLast(); };
+    const auto kNumLastsTasks =


Does it handle recursive task creation?

Not sure what means "recursive" task creation, could you elaborate, please?

when tasks may spawn new (previously unknown) tasks, I believe. May be the case with loops, but let's put it aside for now

The Task itself is an abstraction which handles dependencies so if it spawns new tasks recursively it's already taken into account...

smirnov-alexey · 2024-01-26T16:19:25Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    };
+
+    void run(ExecutionState& state);
+    bool isLast() const { return m_consumers.empty();  }


Could there be a data race for the vector of consumers here?

Once all tasks are created, m_consumers aren't changed, so different threads only perform read operations. Not obvious though

smirnov-alexey

Looks good

…rent-executor

dmatveev

Ok to go if it isn't breaking anything right now. Let it live in parallel with the primary one. Will swap them someday

dmatveev · 2024-01-29T13:51:28Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+    // Notify every consumer about completion one of its dependencies
+    for (auto* consumer : m_consumers) {
+        const auto num_ready =
+            consumer->m_ready_producers.fetch_add(1, std::memory_order_relaxed) + 1;


i'd vote for ++(int) still as to a more concise construct. BUT that's up to you

dmatveev · 2024-01-29T13:52:04Z

modules/gapi/src/executor/gthreadedexecutor.cpp

+
+    // Count the number of last tasks
+    auto isLast = [](const std::shared_ptr<Task>& task) { return task->isLast(); };
+    const auto kNumLastsTasks =


when tasks may spawn new (previously unknown) tasks, I believe. May be the case with loops, but let's put it aside for now

TolyaTalamanov · 2024-01-29T21:19:02Z

@asmorkalov Could you merge it, please?

asmorkalov · 2024-01-30T06:07:58Z

Clang (MacOS) reports warning:

Run python3 $GIT_CACHE/warnings-handling.py
/Users/opencv-cn/GHA-OCV-1/_work/opencv/opencv/opencv/modules/gapi/test/gapi_sample_pipelines.cpp:92:39: warning: taking the max of unsigned zero and a value is always equal to the other value [-Wmax-unsigned-zero]

asmorkalov · 2024-01-30T06:09:10Z

Android build failed:

 FAILED: modules/gapi/CMakeFiles/opencv_gapi.dir/src/executor/thread_pool.cpp.o 
ccache /opt/android-sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=armv7-none-linux-androideabi21 --sysroot=/opt/android-sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DCVAPI_EXPORTS -DOPENCV_WITH_ITT=1 -DTBB_SUPPRESS_DEPRECATED_MESSAGES=1 -DTBB_USE_GCC_BUILTINS=1 -D_USE_MATH_DEFINES -D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__TBB_GCC_BUILTIN_ATOMICS_PRESENT=1 -I/home/ci/opencv/modules/gapi/include -I/home/ci/build/o4a/modules/gapi -I/home/ci/opencv/modules/core/include -I/home/ci/opencv/modules/flann/include -I/home/ci/opencv/modules/imgproc/include -I/home/ci/opencv/modules/dnn/include -I/home/ci/opencv/modules/features2d/include -I/home/ci/opencv/modules/calib3d/include -I/home/ci/opencv/modules/video/include -I/home/ci/opencv/modules/gapi/src -I/home/ci/opencv/modules/gapi/src/3rdparty/vasot/include -I/home/ci/opencv/3rdparty/ittnotify/include -I/home/ci/build/o4a/3rdparty/ade/ade-0.1.2d/sources/ade/include -isystem /home/ci/build/o4a -isystem /home/ci/build/o4a/3rdparty/tbb/oneTBB-2020.2/include -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security     -fsigned-char -W -Wall -Wreturn-type -Wnon-virtual-dtor -Waddress -Wsequence-point -Wformat -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winconsistent-missing-override -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -Wno-comment -Wno-deprecated-enum-enum-conversion -Wno-deprecated-anon-enum-enum-conversion -fdiagnostics-show-option -Qunused-arguments  -fvisibility=hidden -fvisibility-inlines-hidden  -O3 -DNDEBUG   -DNDEBUG -fPIC -std=c++11 -MD -MT modules/gapi/CMakeFiles/opencv_gapi.dir/src/executor/thread_pool.cpp.o -MF modules/gapi/CMakeFiles/opencv_gapi.dir/src/executor/thread_pool.cpp.o.d -o modules/gapi/CMakeFiles/opencv_gapi.dir/src/executor/thread_pool.cpp.o -c /home/ci/opencv/modules/gapi/src/executor/thread_pool.cpp
/home/ci/opencv/modules/gapi/src/executor/thread_pool.cpp:51:5: error: use of undeclared identifier 'GAPI_Assert'
    GAPI_Assert(task);

TolyaTalamanov · 2024-01-30T13:55:49Z

@asmorkalov, thanks! Build has passed

TolyaTalamanov added 4 commits December 12, 2023 09:11

Merge branch '4.x' of https://github.com/opencv/opencv into 4.x

b9c0bb4

Merge branch '4.x' of https://github.com/opencv/opencv into 4.x

149e478

Snapshot

d045b87

Snapshot

d12c3ec

TolyaTalamanov marked this pull request as draft January 10, 2024 15:31

TolyaTalamanov commented Jan 10, 2024

View reviewed changes

opencv-alalek added feature category: g-api / gapi labels Jan 11, 2024

TolyaTalamanov commented Jan 11, 2024

View reviewed changes

TolyaTalamanov force-pushed the at/concurrent-executor branch from 2b3fd6f to dbd7570 Compare January 11, 2024 16:11

TolyaTalamanov commented Jan 11, 2024

View reviewed changes

modules/gapi/src/executor/gexecutor.cpp Outdated Show resolved Hide resolved

asmorkalov requested a review from dmatveev January 12, 2024 06:17

TolyaTalamanov added 3 commits January 12, 2024 10:10

Merge branch '4.x' of https://github.com/opencv/opencv into at/concur…

063b9a8

…rent-executor

Merge branch '4.x' of https://github.com/opencv/opencv into at/concur…

7bfb92c

…rent-executor-tmp

Merge branch '4.x' of https://github.com/opencv/opencv into 4.x

b615680

TolyaTalamanov force-pushed the at/concurrent-executor branch from dbd7570 to 7ccd71a Compare January 12, 2024 10:16

TolyaTalamanov added this to the 4.10.0 milestone Jan 12, 2024

TolyaTalamanov marked this pull request as ready for review January 12, 2024 10:17

TolyaTalamanov force-pushed the at/concurrent-executor branch from 7ccd71a to 38b2c43 Compare January 12, 2024 10:44

TolyaTalamanov commented Jan 12, 2024

View reviewed changes

Introduce GThreadedExecutor for G-API

bfd0ac8

TolyaTalamanov force-pushed the at/concurrent-executor branch from 38b2c43 to bfd0ac8 Compare January 12, 2024 11:25

Fix windows warnings

4917d57

dmatveev self-assigned this Jan 12, 2024

TolyaTalamanov commented Jan 12, 2024

View reviewed changes

dmatveev reviewed Jan 12, 2024

View reviewed changes

smirnov-alexey reviewed Jan 15, 2024

View reviewed changes

TolyaTalamanov commented Jan 16, 2024

View reviewed changes

Merge branch '4.x' of https://github.com/opencv/opencv into at/concur…

aa47a08

…rent-executor

Fix comments to review

65e2897

TolyaTalamanov force-pushed the at/concurrent-executor branch from c73a0cc to 65e2897 Compare January 25, 2024 19:17

TolyaTalamanov added 4 commits January 26, 2024 09:54

Fix windows build

66e6baf

Merge branch '4.x' of https://github.com/opencv/opencv into at/concur…

68c783a

…rent-executor

Use static function for worker

42e3b3a

Delete copy / assign for ThreadPool

6383255

TolyaTalamanov commented Jan 26, 2024

View reviewed changes

Use getNumThreads()

ebc0028

dmatveev reviewed Jan 26, 2024

View reviewed changes

smirnov-alexey reviewed Jan 26, 2024

View reviewed changes

smirnov-alexey approved these changes Jan 26, 2024

View reviewed changes

TolyaTalamanov added 5 commits January 29, 2024 10:25

Merge branch '4.x' of https://github.com/opencv/opencv into at/concur…

9803fc5

…rent-executor

Align brackets style

2a19b8c

Move use_threaded_executor ctor to cpp file

357ed84

Add gcommon.cpp

632703d

Fix compilation issues

b67a187

dmatveev approved these changes Jan 29, 2024

View reviewed changes

Fix build

991d22a

asmorkalov merged commit 8e43c8f into opencv:4.x Jan 30, 2024

This was referenced Feb 3, 2024

5.x merge 4.x #24958

Closed

5.x merge 4.x #24981

Merged


		#include <opencv2/gapi/own/exports.hpp> // GAPI_EXPORTS

		#if defined(HAVE_TBB)

		explicit use_threaded_executor(
		uint32_t nthreads = static_cast<uint32_t>(cv::getNumThreads()))

Uh oh!

G-API: Implement concurrent executor #24845

G-API: Implement concurrent executor #24845

Uh oh!

Conversation

TolyaTalamanov commented Jan 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

ThreadPool

GThreadedExecutor

Implementation details

Pull Request Readiness Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

TolyaTalamanov commented Jan 10, 2024 •

edited

Loading