Skip to content
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

Exclude Padding from Shape Validation in Concat Operation #15308 #15329

Closed
wants to merge 1 commit into from

Conversation

shwetankTT
Copy link
Contributor

@shwetankTT shwetankTT commented Nov 21, 2024

Ticket

#15308

Problem description

The concat operation evaluates the shapes of all input tensors to determine whether the operation can be performed. However, the LegacyShape includes padding as part of the shape computation. Padding should not be considered in shape validation for the concat operation..

What's changed

CI Link: https://github.com/tenstorrent/tt-metal/actions/runs/11953331942

Checklist

  • Post commit CI passes
  • Blackhole Post commit (if applicable)
  • Model regression CI testing passes (if applicable)
  • Device performance regression CI testing passes (if applicable)
  • New/Existing tests provide coverage for changes

@shwetankTT
Copy link
Contributor Author

shwetankTT commented Nov 21, 2024

@ntarafdar @sjameelTT @jaebaek and @yugi957 I have not tested this extensively. Please let me know if this PR does not make sense. There was an issue i was facing during optimization of yolov4 model which was failing due to this validation error and i decided to fix it.

@jaykru-tt
Copy link
Contributor

Can you run models perf CI to ensure that nothing broke?

This doesn't seem to me like it should work in general with arbitrary padding for on-device concat; this op isn't padding aware yet afaik. If the inputs to concat have the same logical shapes but different padding, we would very likely mess stuff up. On the other hand, we only have padding for tiled tensors now and the padding should be the same for tensors of the same logical shape, so this should actually be okay until that changes.

I think we will eventually have arbitrary padding including for RM tensors, so we would have to revisit this then. @sjameelTT any thoughts? I know you've looked at concat before.

@jaykru-tt
Copy link
Contributor

@shwetankTT mentioned to me that he is obtaining tiled tensors with identical logical shape but distinct padding from sharded to interleaved (assuming a tilize is thrown in as well). This is even worse than what I was worrying about above.

input-tensor --> shape=Shape([1, 1, 400[448], 256]), dtype=DataType::BFLOAT16, layout=Layout::TILE)
MemoryConfig(memory_layout=TensorMemoryLayout::INTERLEAVED,buffer_type=BufferType::L1,shard_spec=std::nullopt)
input_tensor_2 --> shape=Shape([1, 1, 400[416], 256]), dtype=DataType::BFLOAT16, layout=Layout::TILE)
MemoryConfig(memory_layout=TensorMemoryLayout::INTERLEAVED,buffer_type=BufferType::DRAM,shard_spec=std::nullopt)

@shwetankTT
Copy link
Contributor Author

I am not seeing this issue over the mainline. Seems like resolved. Closing this issue due same.

@shwetankTT shwetankTT closed this Nov 25, 2024
@shwetankTT shwetankTT deleted the shwetankTT/concat_shape_val branch December 4, 2024 06:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants