Skip to content

When the renderer fails, try to fall back to D2D + WARP#19636

Merged
DHowett merged 5 commits intomainfrom
dev/duhowett/render-retry
Dec 9, 2025
Merged

When the renderer fails, try to fall back to D2D + WARP#19636
DHowett merged 5 commits intomainfrom
dev/duhowett/render-retry

Conversation

@DHowett
Copy link
Member

@DHowett DHowett commented Dec 9, 2025

This commit also ups the number of render failures that are permissible to 6 (one try plus 5 retries), and moves us to use an exponential backoff rather than a simple geometric one.

It also suppresses the dialog box in case of present failures for Stable users. I feel like the warning dialog should be used for something that the user can actually do something about...

Closes #15601
Closes #18198

This commit also ups the number of render failures that are permissible
to 5, and moves us to use an exponential backoff rather than a simple
geometric one.

It also suppresses the dialog box in case of present failures. I feel
like the warning dialog should be used for something that the user can
actually do something about...
auto tries = maxRetriesForRenderEngine;
while (tries > 0)
HRESULT hr{ S_FALSE };
for (auto attempt = 0; attempt < maxRetriesForRenderEngine; ++attempt)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably complains in x86 because attempt is int and maxRetriesForRenderEngine is unsigned int.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ALWAYS

if (attempt > 0) [[unlikely]]
{
// Add a bit of backoff.
// Sleep 100, 200, 400, 600, 800ms before failing out and disabling the renderer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be 100, 200, 400, 800, 1600, no? That's 3.1s which seems fine to me (re: your other question).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, so, no. after the fifth failure we don't retry agian. it's actually max TRIES, not max RETRIES. We can change that to be retries though

Copy link
Member

@lhecker lhecker Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1.5s also seems fine to me. It probably doesn't matter too much. I think "max tries" may be better than retries... 🤔

@DHowett
Copy link
Member Author

DHowett commented Dec 9, 2025

I added some tracepoints to the rewritten render loop,

DH: Renderer returned E_PENDING The data necessary to complete this operation is not yet available.
DH: Sleeping for 100
DH: Renderer returned E_PENDING The data necessary to complete this operation is not yet available.
DH: Sleeping for 200
DH: Renderer returned E_PENDING The data necessary to complete this operation is not yet available.
DH: Sleeping for 400
DH: Renderer returned E_PENDING The data necessary to complete this operation is not yet available.
DH: Sleeping for 800
DH: Renderer returned E_PENDING The data necessary to complete this operation is not yet available.
DH: RENDERER FINALLY FAILED WITH E_PENDING The data necessary to complete this operation is not yet available.
@DHowett DHowett enabled auto-merge (squash) December 9, 2025 22:39
@DHowett DHowett merged commit 45c5370 into main Dec 9, 2025
22 checks passed
@DHowett DHowett moved this from To Cherry Pick to Cherry Picked in 1.24 Servicing Pipeline Dec 9, 2025
DHowett added a commit that referenced this pull request Dec 9, 2025
#19636)

This commit also ups the number of render failures that are permissible
to 6 (one try plus 5 retries), and moves us to use an exponential
backoff rather than a simple geometric one.

It also suppresses the dialog box in case of present failures for Stable
users. I feel like the warning dialog should be used for something that
the user can actually do something about...

Closes #15601
Closes #18198

(cherry picked from commit 45c5370)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgiXh2E
Service-Version: 1.24
@DHowett DHowett moved this from To Cherry Pick to Cherry Picked in 1.23 Servicing Pipeline Dec 17, 2025
DHowett added a commit that referenced this pull request Dec 17, 2025
#19636)

This commit also ups the number of render failures that are permissible
to 6 (one try plus 5 retries), and moves us to use an exponential
backoff rather than a simple geometric one.

It also suppresses the dialog box in case of present failures for Stable
users. I feel like the warning dialog should be used for something that
the user can actually do something about...

Closes #15601
Closes #18198

(cherry picked from commit 45c5370)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgiXh2I
Service-Version: 1.23
@DHowett DHowett deleted the dev/duhowett/render-retry branch January 15, 2026 17:10
@DHowett DHowett moved this from Cherry Picked to Shipped in 1.23 Servicing Pipeline Jan 15, 2026
@DHowett DHowett moved this from Cherry Picked to Shipped in 1.24 Servicing Pipeline Feb 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants