For ONNX Ops, which only have a few operator versions available, the version upgrade does not work reliably:
Example:
Assume that the input graph is in version 17 (specific versions are not important, this is an issue for all versions) and should be converted to version 18. The graph contains a node, which only has operator version 13 and 18 (Again, specific versions are not important, just used for the example.), like ReduceLogSumExp. Therefore, the operator in the graph is still in version 13, because v18 is not available in a graph of version 17.
A conversion function for this operator would now implement a conversion from 13 to 18, because these are the closest available versions of the operator and be registered as @register("ReduceLogSumExp", node_version=13, up_conversion=True) like these other conversion functions:
|
@register("DFT", node_version=19, up_conversion=True) |
If the version converter now runs with a model of version 17 as input, the converter tries to look up a conversion function here:
|
adapter = registry.lookup_adapters( |
where the
from_version is set to the model version in this line
|
node_version = node.version or self._default_onnx_opset |
because
node.version is usually not set for most ONNX models.
As a result, the registry tries to look up a conversion from v17 to v18, which does not exist, because there is no v17 version of the Op, which causes the conversion not to run.
Possible Solution:
One possible solution could be to switch the conversion function lookup from the source version to the target version. For each target version, there should exist at most one conversion function. If a conversion function exists, then the operator needs to be upgraded and if there is no conversion function, then the old operator from the previous version is left in the model.
For ONNX Ops, which only have a few operator versions available, the version upgrade does not work reliably:
Example:
Assume that the input graph is in version 17 (specific versions are not important, this is an issue for all versions) and should be converted to version 18. The graph contains a node, which only has operator version 13 and 18 (Again, specific versions are not important, just used for the example.), like ReduceLogSumExp. Therefore, the operator in the graph is still in version 13, because v18 is not available in a graph of version 17.
A conversion function for this operator would now implement a conversion from 13 to 18, because these are the closest available versions of the operator and be registered as
@register("ReduceLogSumExp", node_version=13, up_conversion=True)like these other conversion functions:onnxscript/onnxscript/version_converter/_version_converter.py
Line 157 in 5989b56
If the version converter now runs with a model of version 17 as input, the converter tries to look up a conversion function here:
onnxscript/onnxscript/version_converter/_version_converter.py
Line 255 in 5989b56
where the
from_versionis set to the model version in this lineonnxscript/onnxscript/version_converter/_version_converter.py
Line 313 in 5989b56
because
node.versionis usually not set for most ONNX models.As a result, the registry tries to look up a conversion from v17 to v18, which does not exist, because there is no v17 version of the Op, which causes the conversion not to run.
Possible Solution:
One possible solution could be to switch the conversion function lookup from the source version to the target version. For each target version, there should exist at most one conversion function. If a conversion function exists, then the operator needs to be upgraded and if there is no conversion function, then the old operator from the previous version is left in the model.