Additional things to consider: - Adding CI test variants that disable the GPU process for ASAN/etc testing on Windows; ASAN/TSAN on Linux as well if Linux ever ships the GPU process - Would falling back to software WebRender only in the parent process if we ever tried the GPU process reasonable? It would lower the attack surface. - Don't we collect telemetry on the GPU_PROCESS feature status?
Bug 1870021 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Additional things to consider: - Adding CI test variants that disable the GPU process for ASAN/etc testing on Windows; ASAN/TSAN on Linux as well if Linux ever ships the GPU process - Would falling back to software WebRender only in the parent process if we ever tried the GPU process reasonable? It would lower the attack surface. - Don't we collect telemetry on the GPU_PROCESS feature status? - We could tweak the fallback algorithm further without always crashing. If it ever was declared stable, then we could never take the GPU process away, and crash the parent if it has N GPU process crashes in a row that weren't stable.
Additional things to consider: - Adding CI test variants that disable the GPU process for ASAN/etc testing on Windows; ASAN/TSAN on Linux as well if Linux ever ships the GPU process. Similar tests for Android. - Would falling back to software WebRender only in the parent process if we ever tried the GPU process reasonable? It would lower the attack surface. - Don't we collect telemetry on the GPU_PROCESS feature status? - We could tweak the fallback algorithm further without always crashing. If it ever was declared stable, then we could never take the GPU process away, and crash the parent if it has N GPU process crashes in a row that weren't stable.