[intel-npu] Dynamic options and properties and refactoring #27955
Conversation
…ending optionBase with mutability and compiler support version; expanding optionsDesc functionality; cleanup in compiler adapter
github-actions
bot
added
category: inference
| @@ -168,6 +168,7 @@ offer a limited set of supported OpenVINO features. | |||
| ov::intel_npu::device_alloc_mem_size | |||
| ov::intel_npu::device_total_mem_size | |||
| ov::intel_npu::driver_version | |||
| ov::intel_npu::compiler_version | |||
There was a problem hiding this comment.
Do we need to make this public now?
There was a problem hiding this comment.
This was a request from @lmielick i believe
| @@ -24,6 +24,7 @@ class ZeroEngineBackend final : public IEngineBackend { | |||
| const std::vector<std::string> getDeviceNames() const override; | |||
| uint32_t getDriverVersion() const override; | |||
| uint32_t getGraphExtVersion() const override; | |||
| uint32_t getCompilerVersion() const override; | |||
There was a problem hiding this comment.
Compiler version should be obtained from the compiler adapter, not from the backend.
| @@ -10,6 +10,7 @@ | |||
| #include "intel_npu/common/npu.hpp" | |||
| #include "intel_npu/utils/logger/logger.hpp" | |||
| #include "openvino/runtime/so_ptr.hpp" | |||
| #include "properties.hpp" | |||
There was a problem hiding this comment.
I think this might be confusing, Should we find a name that suggests it is just a container for a list of supported properties?
There was a problem hiding this comment.
At a second thought, "a container for a list of supported properties" is exactly what a Config ( from config.hpp) is. Can we not reuse a config to store the list of supported properties?
| struct TypePrinter<type> { \ | ||
| static constexpr bool hasName() { return true; } \ | ||
| static constexpr const char* name() { return #type; } \ | ||
| #define TYPE_PRINTER(type) \ |
There was a problem hiding this comment.
Seems like we should split config.hpp in multiple headers?
OptionBase, OptionValue, OptionDesc can go in another header and keep only Config class in config.hpp?
options.hpp should not even include config.hpp anymore?
…ed options as a single string (to be used in VCL)
Details:
Update and continuation of #26923
- unfifying all options into one header. Separation is now based only on option::mode field
- extending optionsBase with mutability and compilersupportVersion
- extending OptionsDesc functionality with dynamic add (based on option:mode, on compilersupportversion or on compiler support string) and other helper functions such as reset or option:mode based string export
- updating existing options
- unifying properties registration and definition into one single class shared between plugin and compiled model
- config properties register dynamically, based on the presence of the underlying config option
- adding option to have special hooks in get/set property
- adding api to fetch compiler version from CID
- adding new public property NPU_COMPILER_VERSION to expose cid version to user
Options registration based on compiler supported properties list (received from compiler) is implemented but not active in this PR to avoid releasing untested code. Implementation of compiler adapter api and additional features such as completely hiding private propeties and handling of ghost properties is added in a separate future PR once we have level-zero support for it
Tickets: