-
Notifications
You must be signed in to change notification settings - Fork 18
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
Workaround for WebGL crash for datasets with many segmentation layers #6995
Conversation
…ader needs to be compiled more often then, though)
@daniel-wer Another idea for improving crash behavior would be to automatically change the hardware utilization after a crash. It could work something like this:
However, I'm not fully convinced. Sometimes a webgl context loss just happens and a simple page refresh is enough to fix it. On the hand, once webgl is acting up, it can be quite brittle (e.g., chrome completely refused to intantiate webgl after repeated crashes even though I opened a normal dataset). As an alternative to my above suggestion, one could also show a blocking prompt before setting things up à la "The last time you used webKnossos, webgl crashed, do you want to change the Hardware Utilization from High to Very Low to avoid repeated crashes? You can change this back in the settings in the left sidebar." What are your thoughts on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM 👍
Regarding changing the hardware utilization following a WebGL crash, as dicussed, this would be hard to get right and there is no immediate need to implement it. I'd postpone working on that.
Also, regarding my observation that it takes ~10x as long to activate a uint64 segmentation layer than a uint32 segmentation layer in an uncached state: The shaders are essentially equal, only the layer name is different. This suggests that it might actually not be the compilation but the linking of the shader that is taking so long 🤔
…ove_wkconnect * 'master' of github.com:scalableminds/webknossos: Update docker compose commands + dev install readme (#7002) Add segment groups (#6966) Add screenshot nightly test for wkorg (#7030) Workaround for WebGL crash for datasets with many segmentation layers (#6995) Fix download of public annotation, include access ctx in user cache key (#7025) Fix that changing a segment color could lead to a crash (#7000) Add more error chaining to annotation download (#7023) Guard against NaNs in shader (#7018) Store editable mappings in multiple fossildb columns+keys (#6903) Context action to move tree to group (#7005) Release 23.05.0 (#7014) Remove vault cache when reloading dataset (#7007) Fix viewing of public datasets (#7010) Update screenshots scalebar positioning (#7003) Update team members (#6999)
…#6995) * reduce shader complexity when having multiple segmentation layers (shader needs to be compiled more often then, though) * fix tests * clean up * update changelog
* Release 23.05.0 * Guard against NaNs in shader (#7018) * guard against nan when deciding whether to use performance optimization in shader * update changelog * Workaround for WebGL crash for datasets with many segmentation layers (#6995) * reduce shader complexity when having multiple segmentation layers (shader needs to be compiled more often then, though) * fix tests * clean up * update changelog * Release 23.05.1 * fix incorrect merge
* Release 23.05.0 * Guard against NaNs in shader (#7018) * guard against nan when deciding whether to use performance optimization in shader * update changelog * Workaround for WebGL crash for datasets with many segmentation layers (#6995) * reduce shader complexity when having multiple segmentation layers (shader needs to be compiled more often then, though) * fix tests * clean up * update changelog * Release 23.05.1 * Fix access check in time tracking controller (#7055) * Release 23.05.2 --------- Co-authored-by: Florian M <fm3@users.noreply.github.com>
…ty-list-drawings * 'master' of github.com:scalableminds/webknossos: (25 commits) Fix issues with styling in dark mode on login page (#7052) Fix nightly by setting missing token (#7048) Release 23.05.1 (#7042) DRY types in update_actions.ts (#7036) Remove some spammy logging from backend (#7039) Use zarr string fill values (#7017) Fix voxel offset for Neuroglancer Precomputed datasets (#7019) Log when user is activated (#7027) Fix exception in applying UpdateTreeGroupVisibility skeleton action (#7037) Fix organization storage layouting (#7034) Update docker compose commands + dev install readme (#7002) Add segment groups (#6966) Add screenshot nightly test for wkorg (#7030) Workaround for WebGL crash for datasets with many segmentation layers (#6995) Fix download of public annotation, include access ctx in user cache key (#7025) Fix that changing a segment color could lead to a crash (#7000) Add more error chaining to annotation download (#7023) Guard against NaNs in shader (#7018) Store editable mappings in multiple fossildb columns+keys (#6903) Context action to move tree to group (#7005) ...
For a dataset with the following layers
... wk crashed for me with "Medium" hardware utilization. With "Very Low" it did not crash. Through iterative shader editing, I found out that the complexity of the shader code was effectively causing the crash. I assume that a lower HW utilization means that more VRAM is available for the shader code and thus doesn't cause a crash?
For that particular dataset constellation, compiling the shader code for all segmentation layers is not necessary, as we currently can only render one segmentation at a time, anyway. Therefore, I adapted the code to take this into account.
The workaround doesn't change the behavior for color-only datasets, but a dataset with six uint8 color layers doesn't crash for me in the first place.
The downside of this approach is that the shader has to be compiled more often when changing layer visibilities. However, the shader compilation is cached (so, toggling between two layers should always be fast after the first toggle). In the end, it's better than crashing, I'd argue.
URL of deployed dev instance (used for testing):
Steps to test:
Issues:
(Please delete unneeded items, merge only when none are left open)