6. IPU supported operations
Below is a list of currently supported operations that can be executed on IPU hardware. This list will be expanded over time as we add more support. Some overloads and modes of operation for ops are not supported and we’ve tried to list all the caveats but some may have been missed.
6.1. Torch operations
6.1.1. Tensor operations
Many of the tensor operations will be executed before even reaching the IPU
so we can consider them supported anyway. Some, like
no sense on a distributed memory system like the IPU so are ignored. There
are no constraints on the memory format of how operations should be called
other than the constraint that all graph inputs should be contiguous.
We will also create tensor views. However, the aliasing property of views with respect to in-place operations should not be relied on as we may have slightly different view behaviour.
Additionally, some PyTorch operations may be implemented by composition of the listed ops but may not be explicitly listed but are in fact supported.
Indexing, slicing, joining and mutating ops
In PyTorch, slicing a tensor is accessing a subset of the tensor by providing the start and end indices, such as
With a PopTorch model, you may take a slice of a tensor only if one of two conditions are met:
The start and end are constants, or can be resolved to be constants (for example, a function of the shape of a tensor which does not change between runs).
The start and end of the slice are related by a constant, for example
tensor[x:x+5]. Please note that this will produce different results to PyTorch if the end value exceeds the length of the tensor: PyTorch will output a smaller size tensor but PopTorch will allow the slice to wrap round to the start of the relevant dimension.
To set the random state, use
6.1.2. Math operations
sorted=Falseis not supported for
2-norm and nuclear norm are unsupported for matrices.
2-norm and nuclear norm are unsupported.
BLAS and LAPACK Operations
6.2. Torch.nn operations
torch.nn.Sequential can be passed into our
compiler wrappers and just work.
6.2.2. Convolution layers
Conv transpose operations do not yet support dilations.
6.2.3. Pooling layers
Currently the max pool layers do not return the indices
so only the variants with
return_indices=False are supported.
6.2.4. Padding layers
All padding layers are supported.
6.2.6. Normalization layers
affine=True is supported as a parameter. That is to say, only the variants with trainable parameters are supported.
6.2.7. Recurrent layers
Bidirectional layers, non-zero dropout probabilities,
num_layers to a value greater than 1
are not currently supported for any recurrent layer. In addition,
bias=False is currently only supported for
6.2.8. Linear layers
6.2.10. Sparse layers
Embedding and EmbeddingBag are supported with the exception of the
6.2.11. Loss functions
This version supports a limited subset of loss functions. However, we support
identity_loss() which gives you the ability to implement any arbitrary
One caveat for the following loss functions is if they are used they will always be included in the back propagation and will always receive a gradient, which is a slight deviation from normal PyTorch operations, where they have to opt in to the gradient pass.
6.2.12. Vision Layers
Support nearest and bicubic mode.
PyTorch Scatter functions
PyTorch Spline Convolution functions
6.3. 16-bit float operations
float16 operations has been greatly simplified since PopTorch version 3.0. Please read this section
carefully if you are used to the way this worked prior to version 3.0.
In PopTorch version 3.0 and later,
float16 operations are handled straightforwardly by the dispatcher frontend.
Tensors and models can be freely cast to and from
float16, and normalization running
statistics can also be retyped by simple casting.
If you have PopTorch code created with a previous version of PopTorch, see Section 6.4, 16-bit float migration.
6.4. 16-bit float migration
Legacy PopTorch code using
float16 can be updated for the dispatcher frontend by considering the following points:
Casts were not well supported by the tracing frontend. They are fully supported by the dispatcher frontend.
opts.Precision.halfFloatCasting()was used to switch between ways of resolving ops with both
float16inputs (mixed-precision inputs), either by upcasting the inputs to
float32, or by downcasting them to
float16. This option is not supported under the dispatcher frontend: mixed precision ops are now always upcast to
float32, in accordance with normal PyTorch behaviour. To recreate the effect of
opts.Precision.halfFloatCasting(poptorch.HalfFloatCastingBehavior.FloatDowncastToHalf), which was the default behaviour with the tracing frontend,
float32inputs to mixed-precision ops should be explicitly cast to
float16before being passed to the op.
opts.Precision.runningStatisticsAlwaysFloat()was used to cause the running mean and variance of certain normalization ops to be calculated in
float32precision, even though the normalization module itself had been cast to
float16. This option is not supported in the dispatcher frontend, as the same effect can be achieved by simply casting the running statistic tensors back to
float32before running the model.
6.5. Gradient computation control
torch.no_grad is supported as a context manager as well as a decorator to suppress the
computation of gradients locally.