Limit the amount of texture scaling done per frame to reduce stutters #6310
Conversation
Scaling causes really bad stutters in some games on some hardware. This should also reduce the impact of pathological cases like the first boss of FF Type-0 to be more bearable.
hrydgard
changed the title
| scaleFactor = 1; | ||
| // INFO_LOG(G3D, "Skipped scaling for now.."); | ||
| } else { | ||
| texelsScaledThisFrame_ += w * h; |
There was a problem hiding this comment.
Should this clear TexCacheEntry::STATUS_TO_SCALE here instead? Consider this case:
- 20 large textures appear on a frame, each 256x256 (so 20 frames to scale all.)
- By the 20th frame, the final texture to scale has changed. This is less frequent than 15 frames, so does not disable scaling.
- The status is never cleared, so it gets rescaled on frame 21.
I'm not sure, there may be other cases. That or we should clear it up where we reset all the fields / always when !match.
-[Unknown]
There was a problem hiding this comment.
Hm yes, this is better. Should be fine to just clear the flag here I think..
|
Yeah, less stutters in Dai-2-Ji Super Robot Taisen Z.Another way to reduce stutters is make sure cpu is active all the time,the "Force real clock sync" does that thing. |
|
I've found that this isn't really noticeable in other games and greatly helps with the crazy slowdowns in FF-Type-0 so I'll merge. Slowdowns aren't completely eliminated though of course because the issue is that the game modifies the CLUTs of all textures every frame for a little while, completely messing up the texture cache. |
Limit the amount of texture scaling done per frame to reduce stutters
|
I tested this in a few games. Almost all cap at 5 flips of deferring. Valkyria Chronicles 3 probably gets the most deferring, at about 32 flips (might just be the texture was not used every frame, otherwise it was 20-25 iirc.) Type-0 gets 20. 3rd Birthday gets 25. So, that's up to about a full second in a few games, but it's not too bad. -[Unknown] |
|
Have empty/flat textures been considered? |
|
@RadarNyan , considered how? What difference would that make? |
|
@hrydgard I'm wondering if a texture is empty/flat (which will not be actually scaled) will it still be counted in texelsScaledThisFrame_ (IMO, it shouldn't) |
|
It will, but it hardly matters as such textures aren't that common, and it will just delay scaling a tiny bit. |
|
@hrydgard If it will, then if there's one 256_256 plain texture (or some smaller ones combines bigger than 256_256) added first, doesn't it mean that all textures after that will be considered exceeding TEXCACHE_MAX_TEXELS_SCALED and not getting scaled within this frame? Of course I haven't seen a lot game (actually only one of my games, ULJM05889) updating plain/empty textures (more than) once per frame, and like you said it will get scaled after the plain/empty textures stops updating. Not really a big deal though. |
|
It's indeed so, but should be rare and not really anything to worry about. If you see some scaling getting heavily delayed by that, let me know. |
Scaling causes really bad stutters in some games on some hardware.
This should also reduce the impact of pathological cases like the first boss of FF Type-0 to be more bearable.
Causes some extra work but the heavy work gets spread over more frames. This probably will need some testing tuning before merge.
It should do nothing to speed if scaling is not enabled.