D3D12 GPU renderer is locked to refresh rate

[slouken]

If you run testsprite --renderer gpu on Windows, it will use the D3D12 backend, and will run very quickly for a fraction of a second and then remain locked at 60 FPS.

This is unexpected behavior and this does not happen when SDL_GPU_DRIVER=vulkan

[flibitijibibo]

D3D12_SetSwapchainParameters would be the place to check, maybe a DXGI call is failing?

[slouken]

It seems correct, it's using SDL_GPU_PRESENTMODE_MAILBOX and setting max in-flight frames to 1...?

[slouken]

Ah, it's because D3D12_WaitAndAcquireSwapchainTexture() waits on a fence.

[slouken]

Interestingly the Vulkan backend has the same logic, but waiting on the fence doesn't block on vsync.

[thatcosmonaut]

It seems correct, it's using SDL_GPU_PRESENTMODE_MAILBOX and setting max in-flight frames to 1...?

MAILBOX is often not supported, so it would be falling back to Vsync in that case.

[slouken]

MAILBOX is often not supported, so it would be falling back to Vsync in that case.

It's being reported as supported on my AMD Radeon RX 7900 GRE

[slouken]

Oh... maybe this code should do something else?

static bool D3D12_SupportsPresentMode(
    SDL_GPURenderer *driverData,
    SDL_Window *window,
    SDL_GPUPresentMode presentMode)
{
    (void)driverData;
    (void)window;

    switch (presentMode) {
    case SDL_GPU_PRESENTMODE_IMMEDIATE:
    case SDL_GPU_PRESENTMODE_VSYNC:
        return true;
    case SDL_GPU_PRESENTMODE_MAILBOX:
#if (defined(SDL_PLATFORM_XBOXONE) || defined(SDL_PLATFORM_XBOXSERIES))
        return false;
#else
        return true;

[slouken]

It does indeed report that mailbox isn't supported in the Vulkan GPU backend.

[flibitijibibo]

I would hope that there's a DXGI query for this but I don't know the interface very well, all I can remember is that the actual swap behavior is done at Present() so it's not like Vulkan where you configure it at swapchain creation time... an actual D3D expert might be needed here.

[slouken]

As far as I can tell the present call has the correct (documented) parameters. There may be something more subtle going on with the fences and wait behavior? Maybe even though newer frames are dropped, we're still waiting on the fence for the frame that is going to be presented at vertical blank?

[thatcosmonaut]

In Mailbox frames are only dropped at present time, they still have to be rendered in order. The only timing constraint that the fences introduce is to prevent the CPU from getting way ahead of the GPU, if the frames are rendering fast it shouldn't limit the framerate.

[slouken]

Well, if I pass false to D3D12_INTERNAL_AcquireSwapchainTexture() in D3D12_WaitAndAcquireSwapchainTexture(), I observe the behavior I would expect, super fast application framerate. I'm sure that's not the correct fix, but maybe a clue to what's happening?

[thatcosmonaut]

I can't reproduce this...