The current implementation of vram limits in JavaFX uses 2 numbers - a "target" and a "max" - and a fairly basic concept of applying back pressure on vram usage, that is roughly like the following:
- If an allocation will outgrow the target amount, then free "unused" textures in various stages of aggressiveness.
- If, while trying to free unused textures, we are still going to use more than the target amount, move on to an even more aggressive stage that attempts to free any unlocked textures to stay under the max amount.
This suffers from a couple of problems:
- The target and max are static, which leads to the following issues.
- Once we reach the target, we stay aggressive until something changes in the app to "need" fewer resources.
- Until we reach the target, we aren't really trying to be a "good citizen" and dump unused stale texture memory.
- The max is set to be a "good citizen" and not use all available vram because once we get there, we stay there and all other programs on the machine will be gritting their teeth at us.
- Since we have little flexibility in the "back pressure" on allocations, if we set the max too high then the current scheme will have no desire to avoid rampant texture growth and if we set it too low then we are constantly in "panic allocation mode" and there is no good tradeoff there.
We could benefit by switching to a model similar to what the VM uses - where there is a target that moves as the app gets more and more active, but still a max that it can never exceed. This would allow us to be a little more relaxed and a little more dynamic in the following ways:
- Reaching the target doesn't shift us into a semi-permanent "allocation panic" mode, we simply grow the target up to the max, and apply a more dynamic back pressure to prevent it from growing too often.
- We can set the max much higher because it isn't really related to the back-pressure mechanism and there is little reason to keep the app from using all available vram for cases where it really needs that much media/texture resources.
- The model will be easier to explain as it would that much closer to being analogous to existing resource limit parameters that developers are already aware of.
- If an allocation will outgrow the target amount, then free "unused" textures in various stages of aggressiveness.
- If, while trying to free unused textures, we are still going to use more than the target amount, move on to an even more aggressive stage that attempts to free any unlocked textures to stay under the max amount.
This suffers from a couple of problems:
- The target and max are static, which leads to the following issues.
- Once we reach the target, we stay aggressive until something changes in the app to "need" fewer resources.
- Until we reach the target, we aren't really trying to be a "good citizen" and dump unused stale texture memory.
- The max is set to be a "good citizen" and not use all available vram because once we get there, we stay there and all other programs on the machine will be gritting their teeth at us.
- Since we have little flexibility in the "back pressure" on allocations, if we set the max too high then the current scheme will have no desire to avoid rampant texture growth and if we set it too low then we are constantly in "panic allocation mode" and there is no good tradeoff there.
We could benefit by switching to a model similar to what the VM uses - where there is a target that moves as the app gets more and more active, but still a max that it can never exceed. This would allow us to be a little more relaxed and a little more dynamic in the following ways:
- Reaching the target doesn't shift us into a semi-permanent "allocation panic" mode, we simply grow the target up to the max, and apply a more dynamic back pressure to prevent it from growing too often.
- We can set the max much higher because it isn't really related to the back-pressure mechanism and there is little reason to keep the app from using all available vram for cases where it really needs that much media/texture resources.
- The model will be easier to explain as it would that much closer to being analogous to existing resource limit parameters that developers are already aware of.
- relates to
-
JDK-8089216 Centralized texture management does not prune unused textures when a platform allocation fails
-
- Open
-