Use torch.Tensor with unsigned types directly instead of TensorWrapper
#5715
Conversation
…pper' Signed-off-by: Anatoly Myachev <[email protected]>
| @@ -442,7 +442,7 @@ def do_test(x, y, kernel_fn): | |||
| # triton result | |||
| x_tri = x if x_is_scalar else to_triton(x, device=device, dst_type=dtype_x) | |||
| y_tri = y if y_is_scalar else to_triton(y, device=device, dst_type=dtype_y) | |||
| z_tri = to_triton(np.empty(SIZE, dtype=z_ref.dtype), device=device) | |||
| z_tri = to_triton(np.empty(SIZE, dtype=str(z_ref.dtype)), device=device) | |||
There was a problem hiding this comment.
To avoid the issue: TypeError: can't convert np.ndarray of type numpy.ulonglong. The only supported types are: float64, float32, float16, complex64, complex128, int64, int32, int16, int8, uint64, uint32, uint16, uint8, and bool. String name for numpy.ulonglong type is uint64.
|
This looks like an nfc but that would force us to depend on a rather new PyTorch. What's the upside of this change? |
I did this from the point of view of removing code that is no longer relevant, to simplify code maintenance. I myself discovered this during debugging, when I saw that a tensor with a different type was being passed to the kernel and this was a bit unexpected. BTW: It looks like these types have been supported since version 2.3: |
PyTorch 2.5 has a limited support for these types: https://github.com/pytorch/pytorch/blob/release/2.5/docs/source/tensors.rst. Considering that Triton uses PyTorch tensors mainly as a data container for transfer data to the kernel, this might be enough.