-
Notifications
You must be signed in to change notification settings - Fork 809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronous Render List Generation and Frame-Independent Task Scheduling #2887
Open
douira
wants to merge
54
commits into
CaffeineMC:dev
Choose a base branch
from
douira:decoupled-frustum-test
base: dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Nov 22, 2024
…led yet, it just does the tree frustum test right after each bfs for testing purposes atm)
…g RenderSection objects, improve tree render list generation performance
…the tree, this greatly improves performance
…ync bfs if there is very fast movement
…trees of varying accuracy to present as few sections as possible while not generating any errors when the camera is in motion.
… unloading of chunks
…ssues when the distance changes (for example under water)
- rebuild tasks are scheduled in a queue and pruned each frame - async culling tasks and results are classes in their own package - chunk rebuild tasks are prioritized based on their distance to the camera, their type, how long the task has been pending, and whether the section is currently visible (in the frustum) - generally cleaned up the update method in RSM
… its own "run" token
…the frame rate and section count when the world updates frequently
…plicity. also changed the frustum test to be before adding a section to the queue, and not after. from my measurements by looking at how long the OcclusionCuller call inside FrustumCullTask takes, this has no impact on performance.
…graph search culling
…ta all at once instead of for each section separately
…sk duration estimation
… douira:sharp-angle-traversal-occlusion
… variants of, add support for very tall worlds
… different tree implementation
…estimation, limit upload size based on previous mesh task result size or an estimate of it, the limit behavior changes depending on which type of upload buffer is used
douira
force-pushed
the
decoupled-frustum-test
branch
from
November 25, 2024 19:12
94885b5
to
158cd78
Compare
… not automatically correctly ordered since they're not coming from a tree
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Uses an octree to generate render lists independently of the, now asynchronous, slow graph search.
Testing has not shown regressions and generally frame rate has improved a little if a system was not limited by render list generation, and a lot if it was. (see testing thread)
Combination with #2886 will avoid even more of the asynchronous work since a graph search isn't necessary to schedule tasks with this PR. (will merge conflict, but should be easy to resolve)
Companion PR in Iris: IrisShaders/Iris#2539
Makes #2780 unnecessary, since the octree traversal is correctly ordered already.