pip install torch-mlir keeps downloading all the versions of the package but does not install them

[wangkuiyi]

I am installing torch-mlir in a new conda env with Python version 3.10. The pip command keeps downloading all the versions of the package.

[powderluv]

Does it work with regular python pip 3.10 ?

[wangkuiyi]

python -m pip install ... works the same as pip install ...

[powderluv]

oh i mean't instead of conda

[WanchaoYao]

Yes, same problem.................

[powderluv]

@ashay I think we should drop torchvision from the requirements.txt chain so we don't have unnecessary downloads for end users. We can add a torchvision-requirements.txt that captures the right torchvision version during RollPyTorch and then we can add a test-requirements.txt (similar to build-requirements.txt) and it can included torchvision-requirements.txt. And any time we try to run tests we can pip install -r test-requirements.txt and then run tests without an additional deps for end users who may not care about our e2e tests.

Let me know what you think and if you want to take a crack at it ? Or I can look at it too.

[ashay]

Sure, I'll reset that behavior, but it'd probably take me a couple of days to get to this.

[bsergean]

Thanks guys ! This prevent me and probably a lot of people to give iree a try.

(I think there's a different way, by building all module manually is possible, but quite painful, very unlike a pip install way)

[wangkuiyi]

@bsergean I reported this bug, but to be clear, it doesn't stop us from using IREE.

I've been using JAX with IREE while I wait for the fix. That way works just fine.

Back to the PyTorch-IREE path, I'm afraid that PyTorch itself is the main problem, not torch-mlir. Both torch.jit.trace and torch.fx.symbolic_trace in PyTorch 1.x can't trace the backward pass. With PyTorch 2.0, I had to use torch.func.grad and functorch.make_fx (which was recently moved to torch....experimental...). We need to wait for PyTorch 2.0 to fix these APIs.

[bsergean]

Thanks for the heads up. A few week ago I was able to get things to compile manually.

I think we only use forward right now so maybe it will be ok, but I have to say I'm very new to all of this :)

[wangkuiyi]

Nice work! @bsergean

Another problem might be worth mentioning is that there are thousands of operators in PyTorch. It is impossible for the people working on the torch-mlir project to turn all of them into MLIR. But if your model uses only those supported by torch-mlir, it should be fine. -- I could be wrong here; torch-mlir authors please correct me.

[powderluv]

We used to have a tracking sheet with all the operators. Roughly 2k or so with 800 core ops. We got to a point where we added support for a lot of these ops so now we just measure based on workloads / models. If you have a model that isn't supported please let us know -- you can either add the op or we can help add it. We run complex models like Stable Diffusion and BLOOM etc.

[wangkuiyi]

Thanks @powderluv for the information! This seems like a very good plan.

I was on the PyTorch team, and I really like PyTorch. I know that PyTorch has pretty good support for M1/M2 chips, so it makes perfect sense for torch-mlir to support macOS well. If all this project needs to set up CI is some macOS machines, I'd be happy to help find hardware resources.

[ashay]

Here is an attempt at separating the dependencies. Given the tricky references to pip packages, the more folks that review the change, the better, so please take a look. Thanks!

Also, @powderluv, there seems to be some unrelated GitHub checkout-related error that is affecting recent PRs. Could it be because of the recent switch to a100 runs in CI?