Windows: Client wrapper: Support querying the graphics adapter used

[jnschulze]

This PR adds a method to the Windows client wrapper which allows plugins to query the IDXGIAdapter chosen by Angle.

Background https://github.com/flutter/engine/pull/26840 introduces a new texture variant for sharing Direct3D textures with Flutter. However, the corresponding D3D device needs to be created using the same adapter as the D3D device used by Angle.

The DXGIAdapter returned by FlutterView::GetGraphicsAdapter can be passed to D3D11CreateDevice(the_adapter, D3D_DRIVER_TYPE_UNKNOWN, ....).

Pre-launch Checklist

• [x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
• [x] I read the Tree Hygiene wiki page, which explains my responsibilities.
• [x] I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• [ ] I listed at least one issue that this PR fixes in the description above.
• [ ] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• [x] I updated/added relevant documentation (doc comments with ///).
• [x] I signed the CLA.
• [x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[flutter-dashboard[bot]]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[flutter-dashboard[bot]]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[flutter-dashboard[bot]]

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

[flutter-dashboard[bot]]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[jnschulze]

This seems reasonable; but we'll want to add a test for this. Is there a reasonable way to produce a mock value for an IDXGIAdapter?

Sure, sry, writing a test had been on my mind for quite some time, but I somehow lost of track of this ticket. Marking this as WIP for now.

[cbracken]

This seems like something we can test now that we support fixture tests. See https://github.com/flutter/engine/blob/a9ccffd0f64bfcecea34c72a1d964ef06bd20506/shell/platform/windows/flutter_windows_unittests.cc#L33-L39 for a minimal example.

We probably can't test for a specific value in a non-fragile way, but we could verify the returned value is non-null and maybe verify the D3D_FEATURE_LEVEL is greater than some value?

[cbracken]

@stuartmorgan @loic-sharma for thoughts on any potential alternatives.

While, I'm not a huge fan of adding API that's exposing something that's exposing what is sort of an implementation detail of our surface management and also appears to be Direct3D version-dependent, I can see why D3D APIs would want to know the adapter associated with the surface (via a ID3D11Device) for D3D texture management.

A few things to consider:

• Behaviour with software fallback
• What happens when we eventually bump our minimum supported OS version to Win 10 and therefore could make use of Skia's Direct3D 12 backend? Similar question for impeller.

[jnschulze]

@stuartmorgan @loic-sharma for thoughts on any potential alternatives.

While, I'm not a huge fan of adding API that's exposing something that's exposing what is sort of an implementation detail of our surface management and also appears to be Direct3D version-dependent, I can see why D3D APIs would want to know the adapter associated with the surface (via a ID3D11Device) for D3D texture management.

A few things to consider:

• Behaviour with software fallback
• What happens when we eventually bump our minimum supported OS version to Win 10 and therefore could make use of Skia's Direct3D 12 backend? Similar question for impeller.

DXGI is meant as a common denominator between different DirectX versions, so it works with DirectX 12 as well. It even allows texture sharing between different versions, i.e. plugins could use a different D3D version than Flutter.

In case of software rendering, this will return a virtual adapter (DXGI_ADAPTER_DESC.Name will be set to "Microsoft Basic Render Driver").

[cbracken]

DXGI is meant as a common denominator between different DirectX versions, so it works with DirectX 12 as well. It even allows

Ah you're right -- I think when I'd written that comment I was looking at GetDevice (which fetches an ID3D11Device), from which we return the version independent adapter. I should have fixed my comment when I re-looked at the public API. Looks good either way. Thanks!

[cbracken]

Looks like there was an infra issue with the Mac iOS Engine build. I've kicked off a re-run; if that doesn't work, you may need to rebase to tip-of-tree (which is red right now, so might need to wait till that's passing too).

[zanderso]

Landing this is blocked on https://github.com/flutter/flutter/issues/111193