The OpenVINO backend maintains hardcoded static sets of supported ops in ggml_backend_openvino_device_supports_op (lines 949–966 of ggml/src/ggml-openvino/ggml-openvino.cpp):
static std::set<ggml_type> supported_types{ ... };
static const std::set<ggml_op> supported_ops{ ... };
static const std::set<ggml_unary_op> supported_unary_ops{ ... };
static const std::set<ggml_glu_op> supported_glu_ops{ ... };
The frontend already has ggml/src/ggml-openvino/openvino/op_table.cpp via get_supported_ops(). These two lists have already drifted:
| Op |
op_table.cpp |
Backend supported_ops |
GGML_OP_ADD1 |
yes |
missing |
GGML_OP_DIV |
yes |
missing |
GGML_OP_SUB |
yes |
missing |
GGML_OP_SOFT_MAX |
yes |
commented out |
GGML_OP_CONT |
yes |
commented out |
GGML_OP_NONE |
absent |
present (special passthrough) |
This means ops like GGML_OP_ADD1, GGML_OP_DIV, and GGML_OP_SUB have frontend translators but will never be dispatched to OpenVINO because the backend's supports_op check rejects them first.
Proposed change
Update ggml_backend_openvino_device_supports_op in ggml/src/ggml-openvino/ggml-openvino.cpp to derive support information from get_supported_ops() (defined in openvino/op_table.h / openvino/op_table.cpp) instead of maintaining separate hardcoded sets.
Why this matters
- Establishes a single source of truth for OpenVINO op support
- Fixes existing silent bugs:
GGML_OP_ADD1, GGML_OP_DIV, GGML_OP_SUB have translators but are never dispatched
- Reduces maintenance burden when adding new ops to the frontend
- Prevents future frontend/backend support-list divergence
Acceptance criteria
- Hardcoded static supported-op sets in
ggml_backend_openvino_device_supports_op are removed or replaced by op_table-driven logic
- Backend op support checks resolve through
get_supported_ops() from openvino/op_table.cpp
- Intentional exclusions (
GGML_OP_NONE, GGML_OP_SOFT_MAX, GGML_OP_CONT) are explicitly handled with comments explaining why
- No behavioral regressions in currently supported OpenVINO ops
- CI Tests passing
The OpenVINO backend maintains hardcoded static sets of supported ops in
ggml_backend_openvino_device_supports_op(lines 949–966 ofggml/src/ggml-openvino/ggml-openvino.cpp):The frontend already has
ggml/src/ggml-openvino/openvino/op_table.cppviaget_supported_ops(). These two lists have already drifted:op_table.cppsupported_opsGGML_OP_ADD1GGML_OP_DIVGGML_OP_SUBGGML_OP_SOFT_MAXGGML_OP_CONTGGML_OP_NONEThis means ops like
GGML_OP_ADD1,GGML_OP_DIV, andGGML_OP_SUBhave frontend translators but will never be dispatched to OpenVINO because the backend'ssupports_opcheck rejects them first.Proposed change
Update
ggml_backend_openvino_device_supports_opinggml/src/ggml-openvino/ggml-openvino.cppto derive support information fromget_supported_ops()(defined inopenvino/op_table.h/openvino/op_table.cpp) instead of maintaining separate hardcoded sets.Why this matters
GGML_OP_ADD1,GGML_OP_DIV,GGML_OP_SUBhave translators but are never dispatchedAcceptance criteria
ggml_backend_openvino_device_supports_opare removed or replaced byop_table-driven logicget_supported_ops()fromopenvino/op_table.cppGGML_OP_NONE,GGML_OP_SOFT_MAX,GGML_OP_CONT) are explicitly handled with comments explaining why