On Sat, 5 Aug 2023 12:28:16 GMT, Thorsten Fischer <[email protected]> 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
