Make Gazebo aware of SetCameraPassCountPerGpuFlush #921
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎉 New feature
See gazebosim/gz-rendering/issues/323
Summary
ign-rendering has a new feature aimed to improve performance but also fixes a few bugs related to particle simulations; which is controlled via
Scene::SetCameraPassCountPerGpuFlush
.A value of 0 will use the legacy mode (i.e. previous behavior) to ease porting from older version.
A value > 0 controls performance vs RAM tradeoff (note that it is an upper limit; a very high value doesn't immediately waste RAM. See
Scene::SetCameraPassCountPerGpuFlush
documentation for details)This PR depends on gazebosim/gz-rendering#353 otherwise it will not compile.
Test it
Just run the code again. This PR changes SetCameraPassCountPerGpuFlush explicitly to 6 to take advantage of the new feature. Set it to 0 for legacy.
As for performance, there won't be yet measurable differences because most sensors are currently downloading rendering data immediately after submitting rendering; which forces a flush per sensor. The final improvement will come when we make use of AsyncTickets in Ogre 2.2
However after the PR it can be immediately tested that particles FXs involving GpuRays behave differently, because pre-PR each cubemap face would be rendered at different timestamps; post-PR they are all rendered at the same timestamp (even in legacy mode).
Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge