masahi commented on pull request #5779: URL: https://github.com/apache/incubator-tvm/pull/5779#issuecomment-643443113
> I'm not sure why you would have to insist on passing them if the user is fine with the TorchScript provided ones If you want to use names chosen by Torch, how are you going to figure out the correct names to give to TVM at deploy time? The names are the one attached to the graph after this line https://github.com/apache/incubator-tvm/blob/master/python/tvm/relay/frontend/pytorch.py#L2504, rather than the graph you supply to the frontend. You also need to remember whatever names Torch chooses until deploy time, since TVM doesn't export input names but they are needed to correctly set inputs. I think most of the times names don't change. Previously we were using names chosen by Torch, but due to the corner case reasons discussed in the thread above, we decided to it is better to let user chooses whatever name they like (ones that don't require remembering). > Passing the shapes should be needed very little, and I am surprised that you would need the user to do that. Passing the pairs of (name, shape) is common across other frontends. We initially started with the same API as others, and we haven't found a good reason to deviate from it. Yes Torch knows the shape when traced, but for scripted it doesn't. The Relay itself is not ready for dynamic shape input. For these reasons, we require input shapes to be passed explicitly. Since TVM users are supposed to know the input shape, I don't think it is a problem. Passing dtypes is not something we (not only pytorch, but other frontends too) thought about, since we always assume float32 inputs. We can discuss how to integrate them. But most of the times inputs are fp32, so I don't want to introduce breaking API changes to allow dtype option. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
