[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Documentation has been added / updated (for bug fixes / features)
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
This PR introduces a fix to resolve a possible bug with the GraphicsResourceManager arbitrarily ending Vulkan cmd lists and then starting new ones in the middle of a frame, by removing that behaviour.
Is there an open issue that this resolves? If so, please link it here.
N/A
What is the current behavior? (You can also link to an open issue here)
The GraphicsResourceManager will end and start new cmd lists (the engine's concept of a "frame") at-will, which is probably causing unintentional side-effects during frames that are being prepped for actual rendering as opposed to pure resource loading.
What is the new behavior (if this is a feature change)?
The GraphicsResourceManager will now just append to the current cmd list, so frames may consist of both resource loading and actual drawing + presenting.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Any previous code relying on the old behaviour may no longer work - the DefaultRenderingSystem has already been checked and verified to still work as intended via the InputEcsSample and UIEventExample targets.
Other information:
This potential bug was discovered in the imgui branch, but I deemed it out of scope to be a part of that change.
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) This PR introduces a fix to resolve a possible bug with the
GraphicsResourceManagerarbitrarily ending Vulkan cmd lists and then starting new ones in the middle of a frame, by removing that behaviour.Is there an open issue that this resolves? If so, please link it here. N/A
What is the current behavior? (You can also link to an open issue here) The
GraphicsResourceManagerwill end and start new cmd lists (the engine's concept of a "frame") at-will, which is probably causing unintentional side-effects during frames that are being prepped for actual rendering as opposed to pure resource loading.What is the new behavior (if this is a feature change)? The
GraphicsResourceManagerwill now just append to the current cmd list, so frames may consist of both resource loading and actual drawing + presenting.Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) Any previous code relying on the old behaviour may no longer work - the
DefaultRenderingSystemhas already been checked and verified to still work as intended via the InputEcsSample and UIEventExample targets.Other information: This potential bug was discovered in the imgui branch, but I deemed it out of scope to be a part of that change.