Adding check and test for triple buffering

[SzilardPapp-Arm]

Adding a check to determine if double buffering is being used and recommend using triple buffering instead if it's more suitable for the application.
message:
"Warning: A Swapchain is being created with minImageCount set to 2, which means double buffering is going to be used. Using double buffering and vsync locks rendering to an integer fraction of the vsync rate. In turn, reducing the performance of the application if rendering is slower than vsync. Consider setting minImageCount to 3 to use triple buffering to maximize performance in such cases."

[CLAassistant]

All committers have signed the CLA.

[SzilardPapp-Arm]

Hi @mark-lunarg,

I bumped into a previous issue:
KhronosGroup/Vulkan-Docs#909
"For example, on Android, if you ask for 2 images AND MAILBOX, you'll get 3 images."

Based on that, is it sufficient to check minImageCount only to determine whether double buffering is being used?
Should it be moved to an arm specific best practice?

[mark-lunarg]

@SzilardPapp-Arm, I'm not too current on swapchains, but maybe we should warn if they asked for fewer images than GetSwapchainImagesKHR returned, or if they didn't call GetSwapchainImagesKHR at all? If you want to keep this check, you could just skip it if Mailbox mode is asked for? In what way is this check ARM-specific?

[SzilardPapp-Arm]

The scope of this check would be only to recommend using triple buffering over double buffering if someone is into performance on those circumstances I mentioned in the warning. First I thought that if minImageCount is 2, that means we are using double buffering, but I'm not sure anymore which condition(s) has/have to met to be able to determine this.
Or is it just generally true that if you are using "VkSurfaceCapabilitiesKHR.minImageCount+1" then it definitely should be triple buffering regardless of presentation mode?
What do you think @mark-lunarg ?

[JoseEmilio-ARM]

I don't think this is an Arm-specific check, see threads here and here. From the point of view of this check, it does not matter if the application is using more images than the developer asked for. If the developer asks for 2 images, it is the layer's job to flag that using less than 3 images might have an impact on performance.

[SzilardPapp-Arm]

We are happy with the current implementation.
Do you have any concerns @mark-lunarg?

[mark-lunarg]

Running through internal CI.

[mark-lunarg]

Touched up commit msgs and pushed to Master -- Thanks @SzilardPapp-Arm, hopefully the first of many.

[SzilardPapp-Arm]

@mark-lunarg
Thanks, I have 3 more in my pocket. :)

[msharov]

I have a complaint about this recommendation, as it is incomplete. Triple buffering can improve performance only if the frame rendering times are both close to the vsync time and very inconsistent.

A clearer way to word the suggestion would be to explain that double buffering requires one frame to be rendered during each vsync in order to keep up with the display refresh rate, while triple buffering requires two frames to be rendered during two vsyncs to keep up.

If your frame render times are consistently longer than the vsync time, triple buffering will NOT help you. All you gain is extra latency. You really need each long-render frame to alternate with short-render frames. Since this scenario is not very likely, I question your pushing the triple buffering on everyone. I'd imagine most gamers would prefer lower latency over eliminating an occasional stutter.