tvm-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [incubator-tvm] masahi edited a comment on pull request #5779: Improve separation of PyTorch dtypes and TVM dtypes in relay PyTorch frontend
Date Fri, 12 Jun 2020 19:21:24 GMT

masahi edited a comment 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 (we did
change dict to list, since the argument order matters in Torch). Yes Torch knows the shape
when traced, but for scripted cases 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:
users@infra.apache.org



Mime
View raw message