More conservative recommendations on dynamic shapes usage in docs (#11161)

* More conservative recommendations about using dynamic shapes

* Duplicated statement from C++ part to Python part of reshape doc (no semantical changes)
This commit is contained in:
Sergey Lyalin
2022-03-24 14:49:14 +03:00
committed by GitHub
parent 0ba2774cf0
commit 47a73b49de
2 changed files with 7 additions and 2 deletions

View File

@@ -39,6 +39,8 @@ There are other approaches to change model input shapes during the stage of <a h
### Dynamic Shape Notice
Shape-changing functionality could be used to turn dynamic model input into a static one and vice versa.
It is recommended to always set static shapes in case if the shape of data is not going to change from one inference to another.
Setting static shapes avoids possible functional limitations, memory and run time overheads for dynamic shapes that vary depending on hardware plugin and model used.
To learn more about dynamic shapes in OpenVINO please see a [dedicated article](../OV_Runtime_UG/ov_dynamic_shapes.md).
### Usage of Reshape Method <a name="usage_of_reshape_method"></a>
@@ -179,6 +181,8 @@ There are other approaches to change model input shapes during the stage of <a h
### Dynamic Shape Notice
Shape-changing functionality could be used to turn dynamic model input into a static one and vice versa.
It is recommended to always set static shapes in case if the shape of data is not going to change from one inference to another.
Setting static shapes avoids possible functional limitations, memory and run time overheads for dynamic shapes that vary depending on hardware plugin and model used.
To learn more about dynamic shapes in OpenVINO please see a [dedicated article](../OV_Runtime_UG/ov_dynamic_shapes.md).
### Usage of Reshape Method <a name="usage_of_reshape_method"></a>

View File

@@ -36,6 +36,7 @@ Apply those methods only if native dynamic shape API described in the following
The decision about using dynamic shapes should be based on proper benchmarking of real application with real data.
That's because unlike statically shaped models, inference of dynamically shaped ones takes different inference time depending on input data shape or input tensor content.
Also using the dynamic shapes can bring more overheads in memory and running time per each inference call depending on hardware plugin and model used.
## Dynamic Shapes without Tricks
@@ -77,10 +78,10 @@ If such a model is converted with Model Optimizer or read directly by Core::read
Such dimensions automatically treated as dynamic ones.
So you don't need to call reshape if undefined dimensions are already configured in the original model or in the IR file.
If the input model has undefined dimensions that you are not going to change during the inference, you can set them to static values, using the same `reshape` method of the model.
If the input model has undefined dimensions that you are not going to change during the inference, it is recommended to set them to static values, using the same `reshape` method of the model.
From the API perspective any combination of dynamic and static dimensions can be configured.
Model Optimizer provides capability to reshape the model during the conversion, including specifying dynamic dimensions.
Model Optimizer provides identical capability to reshape the model during the conversion, including specifying dynamic dimensions.
Use this capability to save time on calling `reshape` method in the end application.
To get information about setting input shapes using Model Optimizer, refer to [Setting Input Shapes](../MO_DG/prepare_model/convert_model/Converting_Model.md)