-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bitpacking #291
Bitpacking #291
Conversation
…n/ao into uint4-improvements
…o uint4-improvements
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/ao/291
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit b01550f with merge base 5485929 (): This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
||
Inputs: | ||
data: torch.Tensor - a tensor of unpacked elements of a small dtype. | ||
container_size: int - the size of the large dtype in bits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious. container_size
can be determined from data.dtype
right? e.g. uint8 -> 8, uint16 -> 16. (there is also this - https://pytorch.org/docs/stable/type_info.html#torch.torch.iinfo).
Also, is it assumed that data.dtype
has container_size
number of bits? What if data
use larger or smaller bit-width than container_size
? e.g. store int4 in int32, then request to pack to int8. Depending on what are your assumptions to the inputs, perhaps some kind of type checking and/or type casting is good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice first step let's keep iterating on cuda mode to figure out how to promote this to a stable feature
Based on this issue: #284
Adding this first iteration of packing/unpacking algorithms to support lower bit dtypes into protoype/