[Good First Issue] [ARM]: Implement CPU plugin just-in-time emitter for LogicalNot operation

[eshoguli]

Context

JIT Emitters are part of code generation feature (a.k.a. tensor compiler) that automatically produces highly-efficient optimized fused subgraph binary code. Each emitter implements specific operation from low level OpenVINO dialect.

Prerequisites

Recommended to use ARM CPU based platform for development (e.g. Mac, Raspberry Pi etc). Emulators (e.g. QEMU) is still an option, but not that convenient, especially for final performance evaluation.

What needs to be done?

• Create fp32 LogicalNot operation JIT emitter for ARM64 SIMD platform. Use OpenVINO CPU plugin JIT emitters documentation and Arm A-profile A64 Instruction Set Architecture documentation for details.
• Modify ARM64 executor and ARM64 kernel (in both places: create_eltwise_emitter and get_supported_precisions) to apply developed JIT emitter.

Before emitter implementation, please, modify tests to be sure that deveoped functionality is covered by test:

• Add jit kernel check in element-wise or activation test, the test must fail.
• If test doesn't fail then add supported operation in element-wise test instantiation or activation test instantiation if it's absent.

Tests

Tests are disabled in default build, so ensure to add -DENABLE_TESTS=ON into cmake command.

GoogleTest is used for testing. CPU functional test target is ov_cpu_func_tests. You can use two GoogleTest filters for element-wise and activation operations:

• for element-wise operations:

./bin/[platform]/[build_type]/ov_cpu_func_tests --gtest_filter="*smoke*Eltwise*"

• for activations:

./bin/[platform]/[build_type]/ov_cpu_func_tests --gtest_filter="*smoke*Activation*"

Example Pull Requests

• Abs operation: [CPU] [ARM64] jit abs #23692
• Sigmoid operation, which reuses Exp emitter: [CPU] [ARM64] jit sigmoid #23065

Resources

• Contribution guide - start here!
• What is OpenVINO?
• CPU plugin JIT emitters
• Blog post on contributing to OpenVINO
• User documentation
• Intel DevHub Discord channel - engage in discussions, ask questions and talk to OpenVINO developers
• How to link your Pull Request to an issue

Contact points

@eshoguli, @dmitry-gorokhov

Ticket

CVS-137699

[jvr0123]

.take

[github-actions]

Thank you for looking into this issue! Please let us know if you have any questions or require any help.

[jvr0123]

I'm currently having some issues with compiling Openvino on my Raspberry Pi 4. I have followed the build guide but have also been unable to get the release version to compile without the terminal freezing up after reaching about 30% with a bunch of c++: fatal error: Killed signal terminated program cc1plus messages. Here is the command I'm currently trying:

cmake -DCMAKE_BUILD_TYPE=Debug -DTHREADING=SEQ -DENABLE_OV_ONNX_FRONTEND=OFF -DENABLE_OV_PADDLE_FRONTEND=OFF -DENABLE_OV_TF_FRONTEND=OFF -DENABLE_OV_TF_LITE_FRONTEND=OFF -DENABLE_OV_PYTORCH_FRONTEND=OFF -DENABLE_OV_IR_FRONTEND=OFF -DENABLE_TESTS=ON -DENABLE_CLANG_FORMAT=OFF -DENABLE_FASTER_BUILD=ON -DENABLE_SYSTEM_FLATBUFFERS=OFF -DARM_COMPUTE_SCONS_JOBS=$(nproc --all) .. && cmake --build . --parallel

I have llvm and clang installed, as well as the other dependencies in install_build_dependencies.sh. Is this a common issue or am I doing something wrong?

[eshoguli]

CPU overheating? Possible solutions:

1. Build with cmake --build . --parallel 2 to prevent CPU overheating.
2. Use qemu: https://www.qemu.org/docs/master/system/target-arm.html. Note, please, you need aarch64 (not 32).
3. Cross compilation: https://forums.raspberrypi.com/viewtopic.php?t=343710

[jvr0123]

CPU overheating? Possible solutions:

1. Build with `cmake --build . --parallel 2` to prevent CPU overheating.

2. Use `qemu`: https://www.qemu.org/docs/master/system/target-arm.html. Note, please, you need aarch64 (not 32).

3. Cross compilation: https://forums.raspberrypi.com/viewtopic.php?t=343710

I actually just figured it out, the Raspberry Pi I'm using only has 4GB of ram, and it looks like adding 8GB of swap ram fixed the issue as the build process very quickly ate all of the system's ram. CPU temp isn't a huge issue, it stays around the ~52 C mark for the most of the build. I don't know how much ram the RPi docker image gets, but do you think it might be worth updating the RPi build instructions with minimum RAM requirements if this is a replicable issue?

[jvr0123]

Should the supported precision be element::f32 or element::boolean? The documentation for the operation specifies that it should only come as a boolean but the issue has fp32