Search Issue Tracker
By Design
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
- var VisionOSEDRHeadromm has a comma instead of a dot when building with Metal Rendering App Mode and local OS localization is set to German
- IAP Catalog remove product “x” and add product “+” buttons are not consistent with other remove and add buttons in the Editor
- Performance issues in Play Mode when quickly hovering the mouse cursor over Hierarchy GameObjects
- Frame Debugger displays incorrect output when FidelityFX Super Resolution or Spatial-Temporal Upscaler is used with Temporal Anti-aliasing or Subpixel Morphological Anti-aliasing
- The layout system is failing to correctly calculate or apply the height of the Japanese fallback font when the primary English font's metrics are used
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.