Trying to understand Nvidia's shenanigans with the presentation engine
So I've been trying tu learn Vulkan for the past few days, and am already confused by how the presentation engine is supposed to work under nvidia's implementation.
First, if I create a swapchain with, let's say, 4 images, then, for every possible present mode, the indices that vkAcquireNextImageKHR returns are always sequential, that is, it will go 0, 1, 2, 3, 0, 1, 2, 3, ...
Here's the confusing bit: if I choose VK_PRESENT_MODE_MAILBOX_KHR i expect the driver to hold onto one image for any whole frame, and only let me acquire the other 3 images, but this is not what happens.
Maybe this could be explained by the fact that the driver copies the contents of the currently-being-displayed image onto some hidden buffer?
Second: why is it that vkAcquireNextImageKHR never blocks but vkQueuePresentKHR does? I'm talking about VK_PRESENT_MODE_FIFO_KHR in particular here, in fact after some cpu profiling i found out that what happens is basically:
- acquire image 0
- render to 0
- present 0 ----> waits for first vsync event
- acquire image 1 (non blocking)
- render to 1
- present 1 ----> waits for vsync
- ...
So basically with VK_PRESENT_MODE_FIFO_KHR you're stuck with double buffering whatever your swapchain image count is?
Anyway, I use a GTX 1660 Ti in Windows 10 1903, 431.60 DCH driver.
Also, I wanted to see if maybe the Vulkan developer drivers from nvidia were any better but it is literally impossible for me to install them, I keep getting "This version of Windows is not supported", for either standard or DCH version (and trust me, I tried getting rid of these DCH driver by following this and other tutorials and also repeatedly nuking my drivers with DDU but I literally cannot install standard driver I don't even know)
Posted Jul 24, 2019, 9:16 PM UTC
No, Vulkan does not guarantee any sequence.
Common misconception. Vulkan also does not guarantee driver holding onto anything.
Also it's not necessarily so simple. We like to think these images are the GPU frontbuffer and backbuffers, like this is DOS or something. But modern OSs do composition (definitely in windowed mode), and they might want to have their own internal canvas to do so.
We discussed this before fruitlessly AFAICT.
But simply; and the answer may annoy you at this point; because Vulkan allows such behavior.
Perhaps because DXGI behaves that way...?
Don't abuse this, but if you think this is a problem that Vulkan allows this, report it at https://github.com/KhronosGroup/Vulkan-Docs/issues/ or perhaps better at https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/ where they should route you to spec or the driver makers. It also has decent chance to get attention of actual NV devs.
They expose
IMMEDIATEmode, but, I think, would otherwisely behave the same.Weird; it works for me. I assume you have the x64 version?
First I want to thank you for taking the time to reply to me.
Indeed I didn't expect any sequence, I was just stating my observations, but I get that I wasn't very clear.
Uhm... I guess I shouldn't try to analyze the behavior of the driver and just trust it, at the end.
Yup, 64 bit Windows 10 Pro 1903. They won't install just like normal release standard drivers won't; I'm stuck with DCH. This wouldn't be a problem normally, but now it seems to be the cause of this "incompatibility", even though the DCH version doesn't install either. So weird.
Bonus question: what does Maximum Pre-Rendered Frames in the Nvidia control panel translate to, in Vulkan? (I guess that option doesn't apply to Vulkan directly, right?)
Well, trust is a weakness. Just keep in mind that what is not forbidden, is allowed.
Actually on this point I had a nice quote from X illustrating it:
Me as well, but it installed without issue. Did you use the proper link: https://developer.nvidia.com/vulkan-beta-42594-windows-10-dch
I would say nothing, as you are (should be) in explicit control of this in Vulkan directly.
I since discovered that MAILBOX on Nvidia is broken and behaves like IMMEDIATE should (see my other comment); I quickly verified it and indeed it tears, so there's no point in speculating on why it does what it does IMO.
I know, my question was more like: what does it correspond to, if one were to implement said functionality in Vulkan.
Uh, the plot thickens it seems. I used that exact link, and just to verify I downloaded it from your link and it is still complaining. It's Italian, but the error translates to:
I suppose it maps to the number of in-flight frames pretty well; I'm not 100% sure how the driver enforces this, though it may very well track the number of pending present submissions. How many frames you allow to be in-flight isn't something the vulkan API exposes but is usually implicitly given by the application developer in the form of fencing prior to presenting.
I was thinking about that too, but I don't get how increasing the number of in-flight frames would increase input lag, which is supposedly a common side effect of maximum pre-rendered frames: in FIFO mode, the number of in-flight frames is totally irrelevant because of the blocking nature of vkQueuePresentKHR, whereas with MAILBOX frames that are too old are discarded when a new one gets presented.
Perhaps it's more of a combination of swapchain image queue size and in-flight frames; frames are only discarded (or blocked for) if said queue gets full.