-
-
Notifications
You must be signed in to change notification settings - Fork 703
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
Lack of support for partial WebGL buffer updates (delta-updates) #110
Comments
It's often quite difficult to do this due to the GPU/CPU memory boundary control issues (I've run into similar issues in other projects). Also, if any features change, the size and layout of the buffer may need to change, as well. Are you aware of a good way to handle / implement this in WebGL? (My GL experience is not in WebGL.) |
I assume you mean the issue where updating a buffer that's currently in use will stall the GPU? If this turns out the be a problem we could probably go back to the technique of having 2 swapping buffers so we can update a copy that isn't currently in use.
Ofcourse - if the layout changes, then there's no way to delta-update. This whole discussion is primarily about changes due to
I'm also only starting with WebGL, but I have a background in OpenGL and OpenGL ES, too. I also didn't measure if there was actually any performance issue with buffer-updates at the moment. There are definitely more pressing issues, but I'd like to have these things documented and to get early feedback (maybe someone already tried it or has experience with it). |
Right, either GPU stalls CPU or vice-versa.
Definitely.
Ah, yes. That makes sense. You need changes to individual features (flip a bool, adjust a color) but very little by way of geometry updates (so the same vertex set but different additional data on the vertices).
In my experience, these libraries (web and native) tends to be strongly CPU bound not GPU bound, so a few extra buffer copies rarely affects the performance. If we test and see that's not the case, then cool, and this is a reasonable path to addressing it. |
I don't think I've ever seen a blocking buffer update.
This is precisely why I suspect that buffer updates could be slow: we are CPU bound, and buffer updates can be bad on CPU. Traditionally, larger buffer updates are at risk of being CPU intense as the driver might have to rearrange or compress data. Small buffer updates, can even be injected into the GPU command lists by some drivers, so their overhead can be much smaller. I suspect that the Browser → Sandbox IPC adds some CPU overhead for sending large amounts of data around, too. Also, I didn't check yet, but I assume mapbox will also walk over all features and recreate the typed-arrays for them, so I expect additional CPU overhead in that. Therefore, delta-updates should probably implemented at that level (somewhere near |
Thanks for digging in to this further! Using a dirty-bitmap or equivalent sounds logical when only feature state is changing, since that's a 1:1 update of individual feature values.
This makes sense, especially adding in the complexity of Browser / Sandboxing and the significant amount of data maps have to update for every frame, depending on the scene. |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This issue was closed because it has been stalled for 7 days with no activity. |
I think it might still be worth looking into this. Reopened |
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
This issue was closed because it has been stalled for 30 days with no activity. |
Currently the WebGL buffers are very naive and they are always updated completly. Some API like the
feature-states
can be used to update individual features, however, even if a single feature is touched, the entire bucket gets reuploaded.There should be a dirty-bitmap (or similar) which keeps track of dirty buffer regions, so that larger buffer updates can be skipped.
The text was updated successfully, but these errors were encountered: