Clear GL memory when Chrome goes to background |
||||||
Issue descriptionI am investigating if we can just clear all the memory used by "GPU process" when we run in-process-gpu mode on low-end devices. I found that the browser process has 2MB more GL allocations when GPU is in-process. Instead of killing GPU process in background and making GPU separate process in low-end devices, we can just delete all these GL allocations when Chrome is in background. In a related issue 725303 we can reduce the extra allocations on native heap by just clearing all the shader cache. This would be as good as killing GPU process.
,
Jun 2 2017
,
Jun 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/620bb1e36c3e115f91473d366035acf7dc933ec4 commit 620bb1e36c3e115f91473d366035acf7dc933ec4 Author: aelias <aelias@chromium.org> Date: Fri Jun 02 18:55:54 2017 Call glReleaseShaderCompiler when GLRenderer loses visibility. This call is a hint that the driver should release RAM caches that it may have built to optimize shader compilation from strings. We should call it to save RAM when we expect that we will not be compiling any shaders anytime soon. The browser going into background is a simple, deterministic time where we can establish that. Notes: - On Android, visibility loss results in GLRenderer (and Display) destruction instead of a SetVisibility call, so also add a call in CleanupSharedObjects(). - I plan to hook up ANGLE ShaderTranslatorCache clearing to this signal in a later patch, as mentioned in the TODO in shader_translator_cache.h. BUG= 725306 , 725303 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2916263002 Cr-Commit-Position: refs/heads/master@{#476740} [modify] https://crrev.com/620bb1e36c3e115f91473d366035acf7dc933ec4/cc/output/gl_renderer.cc
,
Jun 5 2017
Just got back int he office and catching up on things. Is there additional work we need to do here? Perhaps dropping shader caches as well as passing the hint? Is that something you were working on, or would you like me to take a look. If you're looking at this, feel free to re-assign the bug to yourself, otherwise I can take a look this week.
,
Jun 13 2017
Sorry for the late reply. I think calling glReleaseShaderCompiler still does not release the GL memory that is kept around by Chrome I guess. Attaching a trace that has 5 dumps. First dump is Chrome in foreground, 4th dump is Chrome in background. The 4th dump still shows 4MB of GL memory. https://drive.google.com/file/d/0B7f4beGia2iHRUtuQnB6SG1jNUE/view?usp=sharing
,
Jun 13 2017
I tried looking at this and didn't get far. I could really use some help.
,
Jun 13 2017
re #5 - is this better than before the change? Or is the change just a no-op? I would look into just fully dropping the GL contexts when we background (treating it as though the context is lost). Even doing this in a very hacky way is probably fine. It would be nice to measure the impact of this and see how much memory is left - hopefully not much (but it will be driver dependent). Basically, you'd want to call GpuChannelManager::LoseAllContexts on background (see https://cs.chromium.org/chromium/src/gpu/ipc/service/gpu_channel_manager.cc?rcl=4ddaa6f836d00180fc6302b25863d04347d8f274&l=177) ssid@, do you have time to try this out and take some measurements? Otherwise feel free to assign back to me. Thanks!
,
Jun 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/12fd478c980c2af7ea532d7470a350acc19c3a9d commit 12fd478c980c2af7ea532d7470a350acc19c3a9d Author: Siddhartha <ssid@chromium.org> Date: Mon Jun 26 20:23:24 2017 Clear GL context when Chrome goes to background on low end devices Clear all the GL contexts and program cache when Chrome goes to background for low end devices to keep Chrome alive and small in background. These get created again when it comes to foreground. Do not clear channels with WebGl contents since it might break websites. BUG= 725306 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I746108c9e3ff764666edc64605d92c392b45b96e Reviewed-on: https://chromium-review.googlesource.com/538076 Commit-Queue: siddhartha sivakumar <ssid@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org> Cr-Commit-Position: refs/heads/master@{#482377} [modify] https://crrev.com/12fd478c980c2af7ea532d7470a350acc19c3a9d/gpu/ipc/service/gpu_channel.cc [modify] https://crrev.com/12fd478c980c2af7ea532d7470a350acc19c3a9d/gpu/ipc/service/gpu_channel.h [modify] https://crrev.com/12fd478c980c2af7ea532d7470a350acc19c3a9d/gpu/ipc/service/gpu_channel_manager.cc [modify] https://crrev.com/12fd478c980c2af7ea532d7470a350acc19c3a9d/gpu/ipc/service/gpu_channel_manager.h [modify] https://crrev.com/12fd478c980c2af7ea532d7470a350acc19c3a9d/gpu/ipc/service/gpu_channel_manager_unittest.cc [modify] https://crrev.com/12fd478c980c2af7ea532d7470a350acc19c3a9d/services/ui/gpu/gpu_service.cc
,
Jun 28 2017
Do we still need the CL in #3 after #8?
,
Jun 28 2017
I'm not sure how large the win is for #3 but it seems appropriate in principle and there's no reason to revert it. #8 doesn't apply for higher-end devices and pages with WebGL, and I'm also not 100% sure that clearing all contexts will clear this memory on all drivers, given that shader compilation is basically a side helper that's orthogonal to contexts.
,
Jun 28 2017
Seems reasonable to keep both. Thanks.
,
Jul 18 2017
,
Mar 14 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ssid@chromium.org
, May 23 2017