mirror of
https://github.com/saymrwulf/onnxruntime.git
synced 2026-07-18 18:52:16 +00:00
41d2ff622c
### Description
<!-- Describe your changes. -->
In previous implementation, there are two loops to iterate H * W
elements to calculate the `mean` and `squaredNorm` value in one thread,
meanwhile it outputs H * W elements in one thread. That results it's
very very slow when H * W is a large value. And usually, H * W does be a
large value in a model. For example, in the `candy-8` model, the shapes
of [H, W] are [224,224], [112,112], [56,56] for `InstanceNormalization`
op. And in my ADL, `[1,224,224,32]` consumes 17 ms. See below:
```
[profiling] kernel "23848328|[InstanceNormalization] 23848328" input[0]: [1,224,224,32] | float32, input[1]: [32] | float32, input[2]: [32] | float32, output[0]: [1,224,224,32] | float32, execution time: 17007914 ns
```
In this PR, it uses workgroup memory to optimize the original algorithm.
The advantage is that it can parallelly utilize the 64 (workgroupSize)
threads in one workgroup to calculate `mean` and `squaredNorm` value.
Meanwhile, it only outputs `H * W / workgroupSize` outputs for one
thread, which greatly reduces the overhead for one thread. With this
optimization, `[1,224,224,32]` becomes 3 ms and the main overhead is the
extra two `transpose`. The `createInstanceNormProgramInfo` only needs
`0.64` ms. See below:
```
[profiling] kernel "23003600|[InstanceNormalization] 23003600" input[0]: [1,224,224,32] | float32, output[0]: [1,32,224,224] | float32, execution time: 1543792 ns
program-manager.ts:115
[profiling] kernel "23003600|[InstanceNormalization] 23003600" input[0]: [1,32,224,224] | float32, input[1]: [32] | float32, input[2]: [32] | float32, output[0]: [1,32,224,224] | float32, execution time: 642652 ns
program-manager.ts:115
[profiling] kernel "23003600|[InstanceNormalization] 23003600" input[0]: [1,32,224,224] | float32, output[0]: [1,224,224,32] | float32, execution time: 991608 ns
```
This PR currently only applies the new algorithm to NCHW format. For
NHWC format, one way is to transpose the input so that it can use the
new algorithm. But the disadvantage is that 2 extra transpose are added.
@dakenf also gives another way to optimize NHWC. Details see
[here](
|
||
|---|---|---|
| .. | ||
| _example.jsonc | ||
| abs-int32.jsonc | ||
| abs.jsonc | ||
| absr.jsonc | ||
| abss.jsonc | ||
| acos.jsonc | ||
| add.jsonc | ||
| add_int32.jsonc | ||
| and.jsonc | ||
| asin.jsonc | ||
| cast.jsonc | ||
| ceil.jsonc | ||
| concat.jsonc | ||
| concat_int32.jsonc | ||
| conv-transpose.jsonc | ||
| conv.jsonc | ||
| cos.jsonc | ||
| depth-to-space.jsonc | ||
| div.jsonc | ||
| div_int32.jsonc | ||
| einsum.jsonc | ||
| equal.jsonc | ||
| exp.jsonc | ||
| expand.jsonc | ||
| floor.jsonc | ||
| gather-elements.jsonc | ||
| gather.jsonc | ||
| gelu.jsonc | ||
| gemm.jsonc | ||
| global-average-pool.jsonc | ||
| greater.jsonc | ||
| identity.jsonc | ||
| image-scaler.jsonc | ||
| instance-norm.jsonc | ||
| layer-norm.jsonc | ||
| leaky-relu.jsonc | ||
| less.jsonc | ||
| log.jsonc | ||
| matmul-broadcast.jsonc | ||
| matmul.jsonc | ||
| mul.jsonc | ||
| mul_int32.jsonc | ||
| neg-int32.jsonc | ||
| neg.jsonc | ||
| not.jsonc | ||
| or.jsonc | ||
| pad-big.jsonc | ||
| pad.jsonc | ||
| pow-big-number.jsonc | ||
| pow.jsonc | ||
| pow_int32.jsonc | ||
| reduce-min.jsonc | ||
| relu.jsonc | ||
| reshape-int32.jsonc | ||
| reshape-pack.jsonc | ||
| reshape.jsonc | ||
| resize-pack.jsonc | ||
| shape.jsonc | ||
| sin.jsonc | ||
| skip-layer-norm.jsonc | ||
| slice.jsonc | ||
| softmax.jsonc | ||
| split.jsonc | ||
| sqrt.jsonc | ||
| sub.jsonc | ||
| sub_int32.jsonc | ||
| tan.jsonc | ||
| tile.jsonc | ||
| transpose.jsonc | ||
| transpose_int32_uint32.jsonc | ||
| upsample.jsonc | ||
| xor.jsonc | ||