Closed Bug 1494538 Opened Last year Closed Last year
Update accelerated features when GPU process is disabled
When GPU process is disabled, it does not update accelerated features. Then current gecko always fallback to BasicCompositor in this case.
During fallback to BasicCompositor, some graphic errors are printed by trying D3D Compositor. They are like the following. (#0) Error Failed to connect GPU process (#1) Error [D3D11] failed to get compositor device. (#2) Error [D3D11] Failed to init compositor with reason: FEATURE_FAILURE_D3D11_NO_DEVICE (#3) CP+[GFX1-]: Could not get a DXGI adapter (#4) CP+[GFX1-]: Could not get a DXGI adapter (#5) CP+[GFX1-]: Could not get a DXGI adapter (#6) Error [D3D11] failed to get compositor device. (#7) Error [D3D11] Failed to init compositor with reason: FEATURE_FAILURE_D3D11_NO_DEVICE
Attachment #9012481 - Attachment description: patch - Rebuild accelerated features during disabling GPU process → patch - Update accelerated features when GPU process is disabled
Isn't it intentional that we fallback to BasicCompositor when the GPU process has failed repeatedly? The assumption is that something in the graphics driver is crashing, so we don't want to run it in the parent process, since then it would crash the whole browser. Is that different from what this is trying to do?
Yea, it seems like intentional to fallback to BasicCompositor. In this case, it seems better to make it explicitly. gecko does not make it explicitly and tries to allocate D3D compositor and then failed and fallbacks to BasicCompositor.
During disabling GPU process, GPUProcessManager only disables HW_COMPOSITING if the GPU process is disabled by DeviceReset in GPU Process. GPUProcessManager::OnRemoteProcessDeviceReset() https://dxr.mozilla.org/mozilla-central/source/gfx/ipc/GPUProcessManager.cpp#505
(In reply to Sotaro Ikeda [:sotaro] from comment #6) > During disabling GPU process, GPUProcessManager only disables HW_COMPOSITING > if the GPU process is disabled by DeviceReset in GPU Process. But gecko virtually disabling HW_COMPOSITING because compositor device does not exist in parent process.
It seems that some code expects to initialize D3DDevice. nsWindow::GetLayerManager() calls gfxWindowsPlatform::UpdateRenderMode() before creating Compositor. But it does not work as to create D3DDevice. https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#3956 But the UpdateRenderMode() does not create D3DDevice. The D3DDevice is created only when device reset happens. It is done by gfxWindowsPlatform::HandleDeviceReset(). https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#404 HandleDeviceReset() was added by Bug 1183910. Then always fallback to BasicCompositor during disabling GPU process seems to continued about 3 years.
Then it seems better just explicitly fallback to software for now in this case.
Attachment #9012823 - Flags: review?(matt.woodrow)
Comment on attachment 9012823 [details] [diff] [review] patch - Fallback to sofware when GPU process is disabled on Windows Review of attachment 9012823 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/ipc/GPUProcessManager.cpp @@ +196,5 @@ > // crash, then we need to tell the content processes again, because they > // need to rebind to the UI process. > HandleProcessLost(); > + > + // On windos, always fallback to software. Windows
Attachment #9012823 - Flags: review?(matt.woodrow) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/948d251c50ee Fallback to sofware when GPU process is disabled on Windows r=mattwoodrow
You need to log in before you can comment on or make changes to this bug.