Repository navigation
[TF:TRT] Create execution context with device memory if shape output is present in TRT 7 - #52186
Conversation
|
Looks good to me. I modified the PR description with more details. Please check. |
c430234 to
db47424
Compare
|
Based on the code then it's not the fact that there is a shape tensor, but that it is int32 data type. That's not the same thing, right? Because shape tensor has additional qualifications of being 0-d or 1-d. Does this same behavior occur when index output of "topK" operation is set as output? Is there no op that we can insert at the output to force TRT into correct behavior? |
db47424 to
56b64d4
Compare
|
Thanks @christopherbate for your comment! You are right, we could and should be more specific when checking the output tensor. I have added checks to ensure that it is 0-d or 1-d.
The error happens at an assertion of a shape tensor size: "Assertion failed: size == shapeTensorVolume(out.extent)"
I am not aware of any. |
|
I am not sure whether we can/should add check for 0-d or 1-d to filter the cases. It depends on the situation of the bug. For example, if we have this in the network: |
56b64d4 to
ad618aa
Compare
f36cd86 to
1a3ffc0
Compare
|
Rebased to avoid conflicts. Ready to proceed @bixia1 |
bixia1
left a comment
There was a problem hiding this comment.
Looks good to me, thanks for working on this!
Just two minor comments and it should be good for merging after this.
1a3ffc0 to
5d151c0
Compare
Workaround for TRT 7 to handle shape outputs.
Previously, we use createExecutionContextWithoutDeviceMemory to create IExecutionContext, so that TF-TRT can manage the needed device memory to support the execution using the IExecutionContext. This triggers a bug in TRT 7. To workaround the bug, we switch to use createExecutionContext for creating IExecutionContext when the TRTEngine has int32 output.
Add two test cases.
Tracker #45481
Tagging @bixia1 for review.