RFR: 8313648: JavaFX application continues to show a black screen after graphic card driver crash

[Michael Strauß]

On Sat, 5 Aug 2023 12:28:16 GMT, Thorsten Fischer <duke at openjdk.org> wrote:

> Hi,
> 
> I did open the bug report. Some notes to this PR:
> 
> My colleagues and I are able to reproduce this bug regularly, even though it takes sometimes up to 3 or 4 weeks until the D3DERR_DEVICEHUNG error shows up. We are currently evaluating two versions of fixes, but until now we do not have any results. I will post them as soon as I got them.
> 
> Version 1 (this version): Based on the observation, that the TestCooperativeLevel/CheckDeviceState method returns D3D_OK again after about 20 - 60 seconds, the reinitialize is called after the first time the state is returning D3D_OK. The 'isHung' flag stores the information until then.
> 
> Version 2: calls reinitialize directly after D3DERR_DEVICEHUNG has been returned. Basically
> if (hr == D3DERR_DEVICEREMOVED || hr == D3DERR_DEVICEHUNG  ) { .. }
> 
> I did not modify the validatePresent method, as for our workaround (see ticket) it was not necessary. At least the native call swapchain->present dows not return that error code (https://learn.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-idirect3dswapchain9-present). I did not look decisively into all the native calls behind D3DRTTexture#readPixels.
> 
> As I said I will post the results (prism.verbose output) for the 2 versions later as a base for discussions.

Microsoft's [documentation](https://learn.microsoft.com/en-us/windows/win32/direct3d9/dx9lh) states the following for Direct3D 9Ex devices:

> Devices are now only lost under two circumstances; when the hardware is reset because it is hanging, and when the device driver is stopped. When hardware hangs, the device can be reset by calling [ResetEx](https://learn.microsoft.com/en-us/windows/desktop/api/d3d9/nf-d3d9-idirect3ddevice9ex-resetex). If hardware hangs, texture memory is lost.

The current D3D pipeline doesn't call `ResetEx` when the device hangs, it releases and recreates the device instead. However, I think it is okay to do this. [Here's](https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3derr) what the documentation says about `D3DERR_DEVICEHUNG`:

> The device that returned this code caused the hardware adapter to be reset by the OS. Most applications should destroy the device and quit. Applications that must continue should destroy all video memory objects (surfaces, textures, state blocks etc) and call Reset() to put the device in a default state. If the application then continues rendering in the same way, the device will return to this state.

On a side note, I think we should remove the non-9Ex code paths from the D3D pipeline. We're not supporting Windows XP, are we?

-------------

Marked as reviewed by mstrauss (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1199#pullrequestreview-1716985038