-
Notifications
You must be signed in to change notification settings - Fork 410
fix: unify LINSPACE alpha/beta dtype in the arange converter #4626
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -93,6 +93,78 @@ def forward(self, end_tensor): | |
| use_dynamo_tracer=False, | ||
| ) | ||
|
|
||
| @parameterized.expand([("int32", torch.int32), ("int64", torch.int64)]) | ||
| def test_arange_dynamic_start(self, _, dtype): | ||
| """A dynamic `start` reaches the Fill layer as an ITensor. | ||
|
|
||
| LINSPACE requires `alpha` (start) and `beta` (step) to share a dtype. A dynamic | ||
| `start` keeps the dtype of its incoming ITensor, while a literal `step` is | ||
| materialized as a constant of the sequence dtype, so the two can differ. | ||
|
|
||
| Three cases with a dynamic bound are covered here: an int32 `start`, an int64 | ||
| `start`, and both bounds dynamic. Of those, only the int64 `start` works today, | ||
| because the sequence dtype for integer operands is already int64 and matches. | ||
| """ | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor comment: this looks to be the pre-fix behavior. |
||
|
|
||
| class Arange(nn.Module): | ||
| def forward(self, start_tensor): | ||
| return torch.ops.aten.arange.start_step(start_tensor, 10, 1) | ||
|
|
||
| pyt_input = 2 | ||
| inputs = [ | ||
| torch_tensorrt.Input( | ||
| min_shape=(0,), | ||
| opt_shape=(2,), | ||
| max_shape=(5,), | ||
| dtype=dtype, | ||
| torch_tensor=torch.tensor(pyt_input, dtype=dtype).cuda(), | ||
| is_shape_tensor=True, | ||
| ) | ||
| ] | ||
| self.run_test_with_dynamic_shape( | ||
| Arange(), | ||
| inputs, | ||
| use_example_tensors=False, | ||
| check_dtype=False, | ||
| pyt_inputs=[pyt_input], | ||
| use_dynamo_tracer=False, | ||
| ) | ||
|
|
||
| def test_arange_dynamic_start_and_end(self): | ||
| """Both bounds dynamic, so neither is a constant carrying the sequence dtype.""" | ||
|
|
||
| class Arange(nn.Module): | ||
| def forward(self, start_tensor, end_tensor): | ||
| return torch.ops.aten.arange.start_step(start_tensor, end_tensor, 1) | ||
|
|
||
| pyt_inputs = [2, 9] | ||
| inputs = [ | ||
| torch_tensorrt.Input( | ||
| min_shape=(0,), | ||
| opt_shape=(2,), | ||
| max_shape=(5,), | ||
| dtype=torch.int32, | ||
| torch_tensor=torch.tensor(pyt_inputs[0], dtype=torch.int32).cuda(), | ||
| is_shape_tensor=True, | ||
| ), | ||
| torch_tensorrt.Input( | ||
| min_shape=(6,), | ||
| opt_shape=(9,), | ||
| max_shape=(12,), | ||
| dtype=torch.int64, | ||
| torch_tensor=torch.tensor(pyt_inputs[1], dtype=torch.int64).cuda(), | ||
| is_shape_tensor=True, | ||
| ), | ||
| ] | ||
| self.run_test_with_dynamic_shape( | ||
| Arange(), | ||
| inputs, | ||
| use_example_tensors=False, | ||
| check_dtype=False, | ||
| pyt_inputs=pyt_inputs, | ||
| use_dynamo_tracer=False, | ||
| ) | ||
|
|
||
|
|
||
| if __name__ == "__main__": | ||
| run_tests() | ||
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.
this is unrelated to your changes.
_sequence_dtype()(same file, lines 29-41) has a bug that affects this PR's own scenario, the returntrt.DataType.INT64fallback is inside the for loop, so it only ever looks at the first operand and ignores the rest. For arange(dynamic_int_start, 10.0, 1.5), it returns INT64 (wrong) instead of FLOAT, because it stops checking after start and never sees that end/step are floats. Since your _operand_as() now enforces whatever dtype this function returns on every operand, this silently produces wrong integer output instead of the correct float sequence.You could include the fix in this PR, with a minimal test scenario