# Is there a place for storing custom data within PyTorch Tensor **URL:** \ **Category:** hardware-backends\ **Created:** [February 28, 2023, 7:21am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085 "2023-02-28T07:21:08Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Sujoy\_Saraswati](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/sujoy_saraswati/32/783_2.png) [@Sujoy\_Saraswati](https://dev-discuss.pytorch.org/u/Sujoy_Saraswati)\ **Post date:** [February 28, 2023, 7:21am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/1 "2023-02-28T07:21:08Z")
Hi, Is there a place within the PyTorch C++ tensor object (which is based on TensorImpl class) to store some custom data? It could be a “void\*” blob which will be only used if a backend wants to keep some specific data for a tensor. While it is possible to have a separate map in the backend for keeping this kind of information, having it within the tensor would make it more efficient to store and retrieve. Regards, Sujoy ---
**Author:** ![albanD](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/alband/32/9_2.png) [@albanD](https://dev-discuss.pytorch.org/u/albanD)\ **Post date:** [February 28, 2023, 5:10pm UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/2 "2023-02-28T17:10:35Z")
This is loosely answering the question but we do have a strict 1-1 match between the TensorImpl and the python Tensor object. So if that works for you, you can store any custom data you want on the python object (as attributes) and that will just work! We don’t have any extra blob field that I’m aware of in C++ though. ---
**Author:** ![dzhulgakov](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/dzhulgakov/32/648_2.png) [@dzhulgakov](https://dev-discuss.pytorch.org/u/dzhulgakov)\ **Post date:** [March 1, 2023, 8:25am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/3 "2023-03-01T08:25:06Z")
If you have your own “DispatchKey” for your tensor, you can create your descendant of TensorImpl with additional fields. See [Extending dispatcher for a new backend in C++ — PyTorch Tutorials 1.13.1+cu117 documentation](https://pytorch.org/tutorials/advanced/extend_dispatcher.html#get-a-dispatch-key-for-your-backend) for some pointers. Examples of doing that is SparseTensor: [pytorch/SparseTensorImpl.h at master · pytorch/pytorch · GitHub](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/SparseTensorImpl.h) We also have helper class OpaqueTensorImpl in case you want to completely hide backend implementation, e.g. [pytorch/MetalTensorImpl.h at master · pytorch/pytorch · GitHub](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/metal/MetalTensorImpl.h) Just curious, what kind of information are you trying to attach? ---
**Author:** ![Sujoy\_Saraswati](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/sujoy_saraswati/32/783_2.png) [@Sujoy\_Saraswati](https://dev-discuss.pytorch.org/u/Sujoy_Saraswati)\ **Post date:** [March 1, 2023, 11:38am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/4 "2023-03-01T11:38:02Z")
Using a TensorImpl subclass works, but it has issues with shallow copy. While doing weight sharing, the shallow copy from a CPU TensorImpl to a backend subclass doesn’t work. We have a backend specific data layout for physical device memory of the tensors in some cases. PyTorch natively supports NCHW and channel last NHWC, but we want to store a different layout information for these tensors and use this information within the backend. This is an example information that we would like to keep within the C++ Tensor object. Regards, Sujoy ---
**Author:** ![ezyang](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/ezyang/32/12_2.png) [@ezyang](https://dev-discuss.pytorch.org/u/ezyang)\ **Post date:** [March 6, 2023, 12:18am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/5 "2023-03-06T00:18:53Z")
We could set up some sort of linked list or hash map in ExtraMeta which is accessible from TensorMeta. Most of the trouble is I am not sure what the most appropriate data structure for this is. ---
**Author:** ![ppiskorski](https://avatars.discourse-cdn.com/v4/letter/p/919ad9/32.png) [@ppiskorski](https://dev-discuss.pytorch.org/u/ppiskorski)\ **Post date:** [March 10, 2023, 9:44am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/6 "2023-03-10T09:44:25Z")
Hi, Just a super basic proposal that would fill the bill for our backend and hopefully push the discussion. 1. struct BackendMeta with a virtual destructor that is intended for overloading by a backend. 2. extra\_meta\_.backend\_meta\_ field. Per our needs ideally is a shared\_ptr (or an intrusive equivalent). 3. A setter and getter in the TensorImpl that reaches to the extra\_meta\_.backend\_meta\_ @ezyang can you elaborate why map? ---
**Author:** ![ezyang](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/ezyang/32/12_2.png) [@ezyang](https://dev-discuss.pytorch.org/u/ezyang)\ **Post date:** [March 10, 2023, 5:52pm UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/7 "2023-03-10T17:52:39Z")
If you’re willing to subclass the ExtraMeta, you might as well just subclass TensorImpl. The whole point of the map is to avoid having to subclass. ---
**Author:** ![ppiskorski](https://avatars.discourse-cdn.com/v4/letter/p/919ad9/32.png) [@ppiskorski](https://dev-discuss.pytorch.org/u/ppiskorski)\ **Post date:** [March 10, 2023, 8:28pm UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/8 "2023-03-10T20:28:29Z")
Sure, my description was not clear. I meant that an intrusive pointer to BackendMeta would be a new field in ExtraMeta. And the intention is that backends inherit BackendMeta producing a type unknown to the framework that contains whatever additional attributes are needed. But you’ve mentioned some sort of linked list or hash map, which, I am guessing, means ability to store multiple additional attributes. Why such design? ---
**Author:** ![ppiskorski](https://avatars.discourse-cdn.com/v4/letter/p/919ad9/32.png) [@ppiskorski](https://dev-discuss.pytorch.org/u/ppiskorski)\ **Post date:** [March 23, 2023, 8:59am UTC](https://dev-discuss.pytorch.org/t/is-there-a-place-for-storing-custom-data-within-pytorch-tensor/1085/9 "2023-03-23T08:59:40Z")
Please review the [PR 97429](https://github.com/pytorch/pytorch/pull/97429) with my proposal. In short the idea is that since there are downsides to overriding TensorImpl, that PR introduces BackendMeta which is intended for overriding by backends. The contract would be that for the framework the actual implementation is always opaque.