OpenGL & Vulkan

[Kaldaien]

I am the primary developer on Special K, our overlay is running into problems with your driver's new DXGI Interop system when users enable Triple-Buffering in OpenGL.

Currently the driver is creating a D3D12 SwapChain in ALL games irrespective of the graphics API they are using when this is turned on. Consequently, games that are D3D11 and have nothing to do with either OpenGL or Vulkan are getting a second SwapChain created. This causes weird problems for us because any time a game simultaneously uses D3D11 and D3D12, we disable D3D11 features to avoid conflicts with third-party overlays that use D3D11On12.

For NVIDIA's implementation of this same feature, they do two things differently:

1) They use D3D11, 

2) Their OpenGL/Vulkan driver (nvoglv64.dll) only creates the interop SwapChain and device when a game actually swaps OpenGL buffers or acquires a Vk image (it destroys the interop SwapChain and creates a new one whenever the game's window is resized also, whereas your implementation appears to be creating a second window).

I don't think 1 is particularly relevant here, but it does lessen compatibility issues overall with third-party overlays that may respond to a D3D12 SwapChain by using D3D11On12.

Also, there's some weird choice of SwapChain parameters when your D3D12 SwapChain is created:

+-------------+-------------------------------------------------------------------------+
| Resolution. | 120x 1 @ nan Hz |
| Format..... | DXGI_FORMAT_B8G8R8A8_UNORM |
| Buffers.... | 3 |
| MSAA....... | Not Used (or Offscreen) |
| Mode....... | Windowed |
| Scaling.... | Stretched |
| Scanlines.. | Progressive |
| Flags...... | 0x0840 |
| SwapEffect. | Flip Sequential |
+-------------+-------------------------------------------------------------------------+
07/15/2023 18:32:03.081: [ DXGI ] >> Removing Scaling Mode (DXGI_MODE_SCALING_STRETCHED) Because It Prevents Native Resolution

In particular, the scaling mode. If you intend to transition this SwapChain to Fullscreen Exclusive, then having that scaling mode will prevent DXGI from selecting the display's native resolution. Special K removes the scaling mode by default to prevent games from accidentally doing this.

See the Remarks section on DXGI's documentation for more: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/bb173066(v=vs.85)#remarks

[dipak]

Hi @Kaldaien ,

Thanks for reporting it. I have whitelisted you and moved the post to the OpenGL forum.

I will forward the issue to the OpenGL team.

Thanks.

[dipak]

Just FYI, we have created an internal bug ticket to track this issue. Will keep you posted on its progress.

Thanks.

[Ken_Z1]

Hi @Kaldaien,

This is regarding your comment "Currently the driver is creating a D3D12 SwapChain in ALL games irrespective of the graphics API they are using when this is turned on. Consequently, games that are D3D11 and have nothing to do with either OpenGL or Vulkan are getting a second SwapChain created."

Could you tell me the D3D11 app you used (ideally with source code) when such phenomenon was observed? It can be helpful for our problem solving. 

Thanks.

[Kaldaien]

I don't have source code for these games. You can easily reproduce this in any Unity engine game, they all start by creating a dummy OpenGL context and setting a pixel format, then they throw away this context and render stuff in D3D.

For NVIDIA and Special K's own implementation of OpenGL presentation using DXGI, we defer the creation of any kind of interop device and SwapChain until software actually swaps buffers. This avoids all the ridiculous stuff that can happen because engines and overlays are creating GL contexts during initialization that they never actually use.

[Ken_Z1]

Hi @Kaldaien,

Thanks for your feedback and idea sharing.

We tried Cities:Skylines and Ori and the Will of the Wisps, which are all D3D11 Unity-based apps. These apps per se don't load our OpenGL driver so we don't think dummy OpenGL context is introduced by them. However, it will be loaded as long as Special K injection program is active. Therefore, we speculate that our driver's behavior is actually in response to OpenGL function calls in Special K. Does Special K create dummy OpenGL context and call functions like wglMakeCurrent() at initialization phase? It may help explain why D3D12 SwapChain exists regardless of what graphics API is in use.

Also, regarding the comment "This causes weird problems for us because any time a game simultaneously uses D3D11 and D3D12, we disable D3D11 features to avoid conflicts with third-party overlays that use D3D11On12." We prefer concrete description of "weird problems" or "conflict". Pls tell us the specific functionality in Special K that doesn't work in this case. Your clarification can be helpful. Based on our experiments using the aforementioned 2 apps, Special K injection is successful. FPS works fine and control panel shows up with no problem.

Finally, we admit that our implementation of OpenGL presentation using DXGI might be different from that of others, especially the timing and logic of internal behavior. However, we are 100% sure that in OpenGL driver we destroy and recreate a new SwapChain when window resizing is detected, while in Vulkan it's app's responsibility to do so. Your suggestion about SwapChain parameters is accepted.

Thanks.