WebGLRenderer: Defer blocking queries against WebGLPrograms after linking. #19745
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
toji
force-pushed
the
defer-program-queries
branch
from
dbb5a45
to
cea4a5a
Compare
This was referenced Jun 29, 2020
|
Review ping? |
Mugen87
reviewed
Jul 27, 2020
Mugen87
reviewed
Jul 27, 2020
mrdoob
reviewed
Jul 27, 2020
toji
force-pushed
the
defer-program-queries
branch
2 times, most recently
from
e575855
to
13f6f5b
Compare
|
Thanks for the feedback! Addressed all comments. |
|
I've tested your branch locally and it seems the |
|
I'll look into it, thanks! |
toji
force-pushed
the
defer-program-queries
branch
from
13f6f5b
to
f4222b3
Compare
|
Fixed. Explanation above. |
Mugen87
approved these changes
Jul 28, 2020
toji
force-pushed
the
defer-program-queries
branch
from
5800fb4
to
8574346
Compare
Program linking can happen asynchronously, but is forced to block and wait for completion the first time information about that program is queried after linking. This includes calls to getAttribLocation/getUniformLocation/getUniform/getProgramParameter/getProgramLogInfo, etc. This change defers most of those calls until the first time until the first time that they're actually needed by the page, which can allow the program linker time to complete and thus reduce blocking, especially when used in conjuntion with renderer.compile(). It's worth noting that many materials are initialized the first time they are encountered by the render loop and then immediately used for rendering, which negates most of the benefit that this could otherwise provide, but it lays the groundwork for more efficient patterns in the future and can significantly help classes like PMREMGenerator that are already using renderer.compile() internally.
📦 Bundle sizeFull ESM build, minified and gzipped.
🌳 Bundle size after tree-shakingMinimal build including a renderer, camera, empty scene, and dependencies.
|
toji
force-pushed
the
defer-program-queries
branch
from
8574346
to
8ef3f65
Compare
|
Rebased to resolve merge conflicts after discussion kicked up on #19752 again. |
|
Since I think Ricardo feels positive about this change and supporting |
|
Thank you! |
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.
Program linking can happen asynchronously, but is forced to block and wait for completion the first time information about that program is queried after linking. This includes calls to
getAttribLocation/getUniformLocation/getUniform/getProgramParameter/getProgramLogInfo, etc.This change defers most of those calls until the first time until the first time that they're actually needed by the page, which can allow the browser time to complete linking asynchronously and thus reduce blocking, especially when used in conjunction with
renderer.compile().It's worth noting that many materials are initialized the first time they are encountered by the render loop and then immediately used for rendering, which negates most of the benefit that this could otherwise provide, but it lays the groundwork for more efficient patterns in the future and can significantly help classes like
PMREMGeneratorthat are already usingrenderer.compile()internally.The ideal endpoint is for Three to start taking advantage of KHR_parallel_shader_compile as proposed by #16321 and #16662. This is just a lower-impact stepping stone along the way.