Skip to content

HAL parallel_for proposal #26989

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: 4.x
Choose a base branch
from
Draft

Conversation

mshabunin
Copy link
Contributor

@mshabunin mshabunin commented Feb 27, 2025

WIP

Based on #26941

This is proposal of mechanism allowing to pass OpenCV parallel_for backend to HAL. This is just rough draft, details are up for discussion.

The proposal

Pass HAL_Context structure containing funciton pointer to parallel_for to those HAL functions which might require it (are not called inside cv::parallel_for in OpenCV)

struct HAL_Context {
    void (*parallel_for_fn)(
        int tasks, // Q: should we split it into begin/end too?
        void (*body_callback)(int start, int end, void* data), // callback function to be provided by HAL
        void* data); // data will be passed to callback
        // Q: do we need 'stripes' argument?
        // Q: do we need to pass number of threads and backend name/id?
}; // NOTE: using struct allows extending it in the future without breaking API
// Q: do we need to version the structure in addition?

HAL functions would then accept context as an argument:

int cv_hal_lut(HAL_Context * ctx, ...); // Q: should context be a pointer or maybe a reference?
// NOTE: we can add extra function/overload instead of modifiyng existing one

Notes:

  • some extra work is required to wrap cv::parallel_for_ in C-like API and take a pointer to pass to HAL - context creation can be extracted and reused (e.g. in hal_replacement.hpp)

Another approach

We can also use unified initialization mechanism:

int cv_hal_init(HAL_Context * ctx);

OpenCV would call this function at some point and provide similar context structure or a set of arguments.
Possible call points:

  • on library load (Q: does it work with static library and application? would it work after dynamic library unload/load?)
  • before first call to HAL (should be wrapped in a singletone and added before each HAL call) (Q: can it affect performance?)

Q: do we need cv_hal_free or something similar?
Q: in case when we have multiple HALs, should we call init for each one?
Q: potential problem if we pass extra data (e.g. number of threads) via context - then we should re-init HAL if this data changes. Or HAL should assume extra level of indirection - it can only store pointer/reference to context, but should not copy it.

GenshinImpactStarts and others added 3 commits February 26, 2025 18:36
Co-authored-by: Liutong HAN <liutong2020@iscas.ac.cn>
Co-authored-by: Liutong HAN <liutong2020@iscas.ac.cn>
@mshabunin mshabunin added the RFC label Feb 27, 2025
@amane-ame
Copy link
Contributor

Wouldn't adding parameters to the HAL interface break both the ABI and API? Additionally, it seems this would imply a significant number of HAL interfaces would need to be changed.

@mshabunin
Copy link
Contributor Author

Yes, we'll probably need to add new overloaded functions with context parameter. And we don't need to update all HAL functions, only those that require it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy