Use torch.ao.quantization instead of torch.quantizaiton

[NicolasHug]

Same as #4551 but without black conflicts

I just did some brutal sed -i "s/.../..." so I might have done something wrong. @z-a-f please double-check that these are the intended changes :)

[NicolasHug]

@z-a-f , are the functions / classes in toch.ao.quantization exactly the same as in torch.quantization, or should we expect some different results? Some of the changes here are editing the training references, so we need to make sure that everything still works as before in terms of model accuracy etc.

[datumbox]

The changes look good to me but as Nicolas said, I think it's worth confirming that our references still work the way we expect them to work prior merging.

Edit: It seems there are some related failures. Often when new features are introduced, we need to wait until the latest nightly becomes available. Not sure if that's the case here as well.

[vkuzo]

is there any expectation that torchvision needs to work with arbitrary versions of pytorch (not just the latest version)? If yes, we will need a version check. If not, this is good.

[NicolasHug]

We expect the torchvision main branch to work with pytorch nightly, we don't need it to be compatible with previous (or even currently stable) versions

[z-a-f]

@z-a-f , are the functions / classes in toch.ao.quantization exactly the same as in torch.quantization, or should we expect some different results? Some of the changes here are editing the training references, so we need to make sure that everything still works as before in terms of model accuracy etc.

The AO only changed the package name. The functionality is expected to be the same.

[z-a-f]

Same as #4551 but without black conflicts

I just did some brutal sed -i "s/.../..." so I might have done something wrong. @z-a-f please double-check that these are the intended changes :)

This should be fine -- basic mapping of the AO migration is as follows:

• All torch.quantization references should change to torch.ao.quantization
• All from torch import quantization should change to from torch.ao import quantization

Otherwise, the logic should stay the same.

One note: the migration is currently an ongoing process and will not be part of the binary up until 1.11+ (if building from source, 1.11.dev10+). That means that if you have explicit dependency on earlier versions of pytorch, you will get errors.

[z-a-f]

The reason https://app.circleci.com/pipelines/github/pytorch/vision/11088/workflows/c3d06578-6137-4d13-8f38-7342e02c2148/jobs/853515 is failing is because there is a dependency on 1.11.dev09+.

[datumbox]

Approving given @z-a-f's comment that only the package changed location and everything else remains the same. Because we don't have great coverage on the reference scripts, I recommend testing the train and eval commands prior merging.

[NicolasHug]

I tried 2 runs of

python train_quantization.py --device='cpu' --post-training-quantize --backend='fbgemm' --model=resnet18

and got

Test:  Acc@1 69.376 Acc@5 88.898
Test:  Acc@1 69.520 Acc@5 88.896

On main I got

Test:  Acc@1 69.432 Acc@5 88.896

which is concistent with the current docs.

So with @z-a-f 's confirmation that the changes are mostly just a renaming, I think the changes are fine.

I'll merge once cmake_windows_gpu decides to properly pick an updated pytroch version.

[datumbox]

I tried to investigate why this is failing. It seems that cmake on Windows with GPU installs a very old nightly of PyTorch (1.11.0.dev20210929) that possibly doesn't contain the necessary change on the quantization namespace.

It's worth noting that the Windows Cmake with CPU picks up today's nightly (1.11.0.dev20211111) and works without issues.

Upon further investigation, it seems that the last available release of win-64 with CUDA 10.2 happened on 20210929. Since Cmake builds using CUDA 10.2, we are having issues.

[datumbox]

The issues should now hopefully be resolved after #4945