Repository navigation
Draw the window with DX12 on Intel and retry a crashed renderer only after a driver update - #124
Merged
Merged
Conversation
…de until the driver changes
…ide the driver The failure reporter now notes beside the renderer marker what ended the launch: the module it crashed in, "unknown" or "terminated". Only a crash in a known graphics driver or loader module waits for a driver update; any other end, a launch with no note and 0.3.3's entries are retried after clean launches as before. A saved Window drawing choice is checked against the drivers the GPUs have now, so a driver update restores it. The Intel DX12 preference now applies only among the backends of the GPU wgpu's order chooses, so it never changes the GPU.
The renderer marker records the thread that lists adapters, creates the device and draws. The reporter passes the crash record's thread, and a driver-module crash on any other thread, or on an unnamed one, is noted with its thread and retried after clean launches. Capture and encoder threads run in the same user-mode drivers while the marker is live. A key counts as naming its driver only with a dotted version, so wgpu's vendor text does not keep a backend aside. Newer AMD D3D12 and D3D11 drivers (amdxx64, amdxn64) join the driver list.
…x/intel-renderer # Conflicts: # host/src/gui/mod.rs
Backends can list two identical cards in different orders, and vendor and device ids cannot tell which DX12 adapter is the chosen card. wgpu's DX12 PCI bus id is looked up by those same ids, so it cannot either. With a twin listed, the Intel DX12 preference is skipped and the selection is kept.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change
The window renderer (
host/src/gui/renderer.rs) only affects the app's own window. Capture and encoding are unchanged.Candidatecarries the adapter's PCI vendor and device for this. The Troubleshooting "Window drawing" choice andWGPU_BACKENDstill narrow the wgpu instance beforepick()runs, so Vulkan chosen either way still draws with Vulkan.renderer/<launch>.faultbeside a launch's renderer marker. It holds the module the crash was in (resolved as for the crash report),unknownfor a crash in no module it could name or one seen only by its exit code, orterminatedfor an end without a crash. A crash in a driver module counts as the window's only when the crash record's thread is the marker's thread. Otherwise the note leads with the thread (thread <id>: <module>, orunnamed thread: <module>when the record or the marker names no thread). Capture (D3D11 duplication) and encoder probing run in the same user-mode drivers while the marker is live, so a crash on those threads, or in our own code inside a driver, is not taken for a window driver crash. The note is written only while the marker exists, before the crashed process is released. The next launch's sweep stores it in the history entry asfault. A marker without a note, such as one left with no reporter running, counts asunknown.faultis a known graphics-driver or loader module on the window's thread, and the key names a driver version. A driver version means digits separated by dots (31.0.101.2111), as DXGI gives. When DXGI does not list the adapter, the key falls back to wgpu's driver text, which can be a vendor string that stays the same across updates, so it does not count. Every other failure keeps the oldRETRY_AFTERclean-launch retry: another thread's crash, a crash record without a thread, our own module, another program's module,unknown,terminated, or a key without a driver version. A driver crash stays noted if the same backend later fails for another reason.igvk(Vulkan driver, the 0.3.3 crash),igd(Direct3D drivers, GMM),igc(shader compiler),igxelpicd(Xe OpenGL).amdvlk(Vulkan),atio6axx(OpenGL),atidxxandatiumd(Direct3D),amdxxandamdxn(newer drivers' D3D12 and D3D11),amdxc(DX12 shader compiler).nvoglv(OpenGL and Vulkan),nvwgf2umandnvd3dum(Direct3D),nvldumd(UMD loader),nvgpucomp(shader compiler).vulkan-1.dll,opengl32.dll.chosen_plan()and the Troubleshooting "avoiding" status now count only failures recorded on the GPUs and drivers DXGI lists now. A failure on a GPU that now has another driver no longer sets the saved choice aside. A GPU that DXGI does not list cannot show its driver, so its failures still apply.fault. Their crash records were removed once reported, so the old data cannot tell where they crashed. They keep the clean-launch retry, which is how 0.3.3 treated them. On the Intel PCs from the field crash scan, Vulkan is no longer the default anyway.faultis left out when absent, and 0.3.3 ignores it when reading, so a downgrade can still read the file.Window renderer selectedline gainsreason=:intel defaultwhen the Intel rule changed the backend,avoiding crashed backendwhen avoidance changed the pick, ordefaultotherwise. Itsavoidedlist shows only entries for the adapters listed now, with theirfault.fault=andretry=(after a driver updateorafter clean launches).Tests
New or updated tests in
renderer.rs:amdxx64.dllandamdxn64.dll, and rejects others: our own exe, ntdll, KERNELBASE, d3d12core, overlay and hook modules,unknown,terminated, and notes of another thread's crash.unknownandterminatedare noted as they are.terminatedfailure, and is retried after a driver version change.unknownandterminatedare retried afterRETRY_AFTERclean launches. The same holds for an enumerate-stage failure.terminatedand a marker with no note are retried afterRETRY_AFTERclean launches. A note without a marker is removed, and the reporter writes none when there is no marker.Intel Corporation Intel driver,AMD proprietary driver 24.10.1), does not count as a known driver, and an igvk64.dll crash on it is retried afterRETRY_AFTERclean launches, then twice as long after a second failure.history.jsonand a 0.3.3 marker (no thread) load. The old entry is retried and the marker counts asunknown. A 0.3.3-shaped struct still reads the saved file. The reset clears them.WGPU_BACKEND=vulkanwins over the Intel default. Existing renderer tests pass, including Keep OpenGL out of the window renderer so AMD's driver can't crash startup #115's OpenGL test.Run on macOS:
cargo fmt --all --check,cargo clippy --workspace --all-targets -- -D warningsandcargo test --workspace, all passing. The reporter's Windows-only paths are covered by Windows CI.Release notes
On some PCs with Intel graphics, EternalMonitor could close as it started because Intel's Vulkan driver crashed while the window was created. The window now draws with DirectX 12 on Intel graphics. When a drawing method crashes inside the graphics driver while it creates or draws the window, EternalMonitor keeps it aside until the driver is updated. Other failed starts try it again after a few launches, as before.