Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDXGIOutput::FindClosestMatchingMode fails when passing in certain ID3D12Devices as argument. #824

Open
hsiversson opened this issue May 24, 2023 · 2 comments
Labels

Comments

@hsiversson
Copy link

Hello,

We recently discovered that the call to FindClosestMatchingMode on the IDXGIOutput instance always fail with a E_INVALID_CALL return code when certain ID3D12Devices are passed in as the third argument IUnknown *pConcernedDevice.

Enabling the D3D12 Debug Layer does not provide any additional information about the issue apart from an internally thrown com_ptr exception.

I've tested converting to the newer IDXGIOutput1::FindClosestMatchingMode1 function, but it throws the same error.

We suspect this might be due to our usage of the D3D12 Agility SDK, and that this function was never updated to properly support it.
We're currently using D3D12 Agility version 1.606.4.

For now, we can get away without passing any device, since we do all our format checking before even reaching this point.
But it is such a small thing that can easily go unnoticed. (We've had this issue for at least a year)

ID3D12Device* ourDevice; // Assume this is a valid device
IUnknown* d3D12Device = ourDevice;

DXGI_MODE_DESC validatedMode = {};
HRESULT result = output->FindClosestMatchingMode(someModeDesc, &validatedMode, d3D12Device);

I can provide more details and testing if needed as we have a solid repro case for this.

@jenatali
Copy link
Member

D3D12 devices are never a valid input. Enabling the DXGI debug layer would provide an output message indicating that the passed in device doesn't support the IDXGIDevice interface.

@hsiversson
Copy link
Author

@jenatali
Thanks for clarifying!
If this is the case, I would probably suggest to update the MSDN documentation to clarify the usage of the parameter.

Currently it just specifies this:

[in, optional] pConcernedDevice
Type: IUnknown*
A pointer to the Direct3D device interface. If this parameter is NULL, only modes whose format matches that of pModeToMatch will be returned; otherwise, only those formats that are supported for scan-out by the device are returned. For info about the formats that are supported for scan-out by the device at each feature level:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants