Search Issue Tracker
By Design
By Design in 2022.2.X
Votes
0
Found in
2022.2.0a13
Issue ID
UUM-2877
Regression
No
Different behavior between UnityEditor and UTR observed when counting m_ResourceCreationThisFrameBytes
Steps to reproduce:
- Open Editor and run Tests/EditModeAndPlayModeTests/TextureStreaming project
- Observe GfxDeviceD3D11Base::FlushIfNeeded()
-> GetD3D11Context()->Flush() never actually gets called
-> so m_ResourceCreationThisFrameBytes never surpasses 1GB
- Now compare with running "perl utr.pl --suite=playmode --clean-library --testproject=Tests/EditModeAndPlayModeTests/TextureStreaming --debug"
- Again, observe GfxDeviceD3D11Base::FlushIfNeeded()
Expected result: same behavior, no actual manual flushing
Actual result: now we actually see the device getting flushed; running this way, m_ResourceCreationThisFrameBytes actually surpasses 1GB
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Texture Import Warnings are obscured by other Terrain Layer options in the Inspector
- Active Targets section text in Graph Inspector is truncated despite available space
- Burst Inspector middle divider is jittering when resized with the Burst Inspector window docked
- Shader Graph Node information is briefly displayed in Graph Inspector when clicking on Category in the Blackboard
- JsonConvert conversion fails trying to call GetCallbackMethodsForType when [OnDeserialized] is used in a class
Resolution Note:
UTR uses a different mode. It generates what is essentially a huge single frame. The flush is needed to avoid drivers crashing. As we cannot make UTR to actually tick frames, or EndBatchModeUpdates, we must do this or crash in the driver.
Resolution Note (2022.2.X):
UTR uses a different mode. It generates what is essentially a huge single frame. The flush is needed to avoid drivers crashing. As we cannot make UTR to actually tick frames, or EndBatchModeUpdates, we must do this or crash in the driver.