This pull request implements a revision of the existing resources, assets, and loader system to add support for delayed or streamed loading.
Currently loading has to happen synchronously: a staging-area is populated with desired assets and resources. The area is sorted by dependencies between the resources and assets, and incrementally repopulated as new dependencies and resource artefacts emerge from loading an asset's data. This is fine and convenient, but it does not allow for data to be loaded in the background, forcing either synchronous loads during gameplay introducing lag stutters, or forcing long load screens to preload as much data as possible.
This PR aims to separate loading into two phases, if desired:
Resource generation and allocation
During this time, assets that generate resources must create a "stub" of the resources that they provide, and only load as little of their input data as possible. The stub resources may be textures and buffers, the size of which will be unknown.
Resources like textures and buffers are only allocated minimally, only loading as little data into them as absolutely necessary. Other resources like framebuffers, shaders, etc. are loaded as before.
The deferred load now returns synchronously, having created a state that can be rendered. Special care must be taken for assets that produce metadata, as that metadata is often necessary for normal operation.
Deferred or background loading
The textures and buffers that were deferred can now be loaded at a later point, incrementally as needed, or streamed in the background using a derived context.
Once the load is complete, the same state is achieved as with the old synchronous load system, but yielding much lower pause times for the first synchronous step.
In order to achieve this the following needs to be done:
[ ] A new resource class, deferrable-resource is introduced. Resources of this type can be loaded minimally.
[ ] The function allocate when called on a deferrable-resource will perform minimal allocation, rather than full allocation.
[ ] The function load when called on a deferrable-resource will perform full allocation with data loading. The resource's data field must be properly populated before this function can be called. Alternatively, the standard update-buffer-data or resize-buffer may be used as well.
[ ] A new asset class, deferrable-asset is introduced. Assets of this type can be loaded minimally.
[ ] The function allocate when called on a deferrable-asset will perform minimal loading, only producing as much metadata as necessary for standard operation, and producing deferrable-resource instances that are "close enough" to the real resource type once loaded fully.
[ ] The function load when called on a deferrable-asset will perform full allocation with data loading. The data of resources it generates will be populated fully so that they may be loaded as well.
[ ] Context creation must allow for a derived context, which can be active in a background thread alongside the main context, used for streaming in texture and buffer data.
[ ] A new staging area class, deferred-staging-area is introduced. When commit is called on such an area, the loader will perform a deferred load, and keep track of the assets and resources that have not been fully loaded yet.
[ ] A new loader class, streamed-loader is introduced. This loader keeps a background thread and derived context for use in background streamed loading. When commit is called on a deferred-staging-area with the keyword argument :stream T, then it will automatically start loading in the remaining assets and resources in the background.
This pull request implements a revision of the existing resources, assets, and loader system to add support for delayed or streamed loading.
Currently loading has to happen synchronously: a
staging-areais populated with desired assets and resources. The area is sorted by dependencies between the resources and assets, and incrementally repopulated as new dependencies and resource artefacts emerge from loading an asset's data. This is fine and convenient, but it does not allow for data to be loaded in the background, forcing either synchronous loads during gameplay introducing lag stutters, or forcing long load screens to preload as much data as possible.This PR aims to separate loading into two phases, if desired:
allocatedminimally, only loading as little data into them as absolutely necessary. Other resources like framebuffers, shaders, etc. are loaded as before.In order to achieve this the following needs to be done:
deferrable-resourceis introduced. Resources of this type can be loaded minimally.allocatewhen called on adeferrable-resourcewill perform minimal allocation, rather than full allocation.loadwhen called on adeferrable-resourcewill perform full allocation with data loading. The resource's data field must be properly populated before this function can be called. Alternatively, the standardupdate-buffer-dataorresize-buffermay be used as well.deferrable-assetis introduced. Assets of this type can be loaded minimally.allocatewhen called on adeferrable-assetwill perform minimal loading, only producing as much metadata as necessary for standard operation, and producingdeferrable-resourceinstances that are "close enough" to the real resource type once loaded fully.loadwhen called on adeferrable-assetwill perform full allocation with data loading. The data of resources it generates will be populated fully so that they may beloaded as well.deferred-staging-areais introduced. Whencommitis called on such an area, the loader will perform a deferred load, and keep track of the assets and resources that have not been fully loaded yet.streamed-loaderis introduced. This loader keeps a background thread and derived context for use in background streamed loading. Whencommitis called on adeferred-staging-areawith the keyword argument:stream T, then it will automatically start loading in the remaining assets and resources in the background.