Why need create framebuffers for swapchain count images ?

Why not use one frame buffer ?
I look examples Sasha Williams and see:
for (i = 0; i < info.swapchainImageCount; i++) {
attachments[0] = info.buffers[i].view;
res = vkCreateFramebuffer(info.device, &fb_info, NULL,
&info.framebuffers[i]);
}

And why do one render many times in differents cmd_buffers ?

[b]VkRenderPassBeginInfo renderPassBeginInfo = vkTools::initializers::renderPassBeginInfo();
renderPassBeginInfo.renderPass = renderPass;
renderPassBeginInfo.renderArea.offset.x = 0;
renderPassBeginInfo.renderArea.offset.y = 0;
renderPassBeginInfo.renderArea.extent.width = width;
renderPassBeginInfo.renderArea.extent.height = height;
renderPassBeginInfo.clearValueCount = 2;
renderPassBeginInfo.pClearValues = clearValues;

	VkResult err;

	for (int32_t i = 0; i &lt; drawCmdBuffers.size(); ++i)
	{
		// Set target frame buffer
		renderPassBeginInfo.framebuffer = frameBuffers[i];

		err = vkBeginCommandBuffer(drawCmdBuffers[i], &cmdBufInfo);
		assert(!err);

		vkCmdBeginRenderPass(drawCmdBuffers[i], &renderPassBeginInfo, VK_SUBPASS_CONTENTS_INLINE);[/b]

As for first question:
you can have single frame buffer if you have IMMEDIATE_KHR present mode. If you are double buffering, then you obviously have two Frame Buffers etc.

2nd Q:
One does not render to Command Buffers. Command buffers are something like script files or *.exe file.
That technique you are listing from SW is that you prepare the “script file like” thing once (for each frame buffer) – imagine it done e.g. on a typical loading screen and then when actual rendering is going on you just have to choose and execute the right command buffer (and do not have to waste cpu time by changing half the state manualy every frame).

krOoze but on GPU always submit all cmd buffers !
That’s why I said it renders all the time.
When we do QueueSubmit.
And the question arises why to do render several times the sames cmd_bufffers.
They are(cmd_bufffers) the same !

cmd_bufffer1 the same as cmd_bufffer2 !
Or do this because Vulkan very power full and fast ? :slight_smile:

[QUOTE=Ronniko;40603]cmd_bufffer1 the same as cmd_bufffer2 !
Or do this because Vulkan very power full and fast ? :)[/QUOTE]

That is not true. The command buffers refer to different framebuffers, so they actually differ (see vkCmdBeginRenderPass).

If you don’t want to duplicate the render commands inside the command buffer, use secondary command buffers.

I’m not 100% sure, but maybe you’re misunderstanding things. Just because you have multiple command buffers with almost the same content does not mean you render multiple times. Having multiple CBs allows you to start with one of them at a certain pipeline stage while the other is getting presented and allows you to optimize your rendering schedule.

Many NVIDIA cards not support VK_PRESENT_MODE_IMMEDIATE_KHR

PS: Sasha Williams code from example Vulkan triangle. Where rendering only one color triangle.

For thats reason on AMD render work fine with one frame buffer when set VK_PRESENT_MODE_IMMEDIATE_KHR.
But for normal render on NVIDIA we must reinvent crutches :slight_smile:
For thats reason i think AMD best of the best.

[QUOTE=Ronniko;40603]krOoze but on GPU always submit all cmd buffers !
That’s why I said it renders all the time.
When we do QueueSubmit.
And the question arises why to do render several times the sames cmd_bufffers.
They are(cmd_bufffers) the same !

cmd_bufffer1 the same as cmd_bufffer2 !
Or do this because Vulkan very power full and fast ? :)[/QUOTE]

You could say the same thing about anything you want to change from a command buffer. Why can’t you just swap one piece of memory for another? Why do you have to rebuild the whole command buffer just to change a single push constant, dynamic uniform address, or even just use a different uniform buffer altogether? It’s just memory, right?

Command buffers work because they do all of the work needed to render something. And yes, where something will be rendered is a big part of “all of the work”. The specific address of that specific output image is not something that the rendering system can just ignore or patch in later.

If you don’t like that, you can build secondary command buffers which can render to anything, then use them with image-specific primary command buffers. Or you can render to non-swapchain images and blit/resolve into them at the end in a separate, image-specific command buffer.

[QUOTE=Ronniko;40606]For thats reason on AMD render work fine with one frame buffer when set VK_PRESENT_MODE_IMMEDIATE_KHR.
But for normal render on NVIDIA we must reinvent crutches :slight_smile:
For thats reason i think AMD best of the best.[/QUOTE]

Yes, that’s wonderful… to the extent that using immediate present modes is a good idea.

[QUOTE=Ronniko;40606]For thats reason on AMD render work fine with one frame buffer when set VK_PRESENT_MODE_IMMEDIATE_KHR.
But for normal render on NVIDIA we must reinvent crutches :slight_smile:
For thats reason i think AMD best of the best.[/QUOTE]

Vulkan is aimed at different IHVs and different paltforms. Supporting optional features (or doing stuff wrong) does not make a particular implementation better than another.

If you read the specs you’ll notice that VK_PRESENT_MODE_FIFO_KHR is the only mode that must be supported by an implementation (that offers swapchain support). VK_PRESENT_MODE_IMMEDIATE_KHR is not required to be available.

So if you want your applications to work an all Vulkan devices you must actually check what modes are available if you want to use something other than VK_PRESENT_MODE_FIFO_KHR .

What about VK_PRESENT_MODE_FIFO_RELAX_KHR ?
For this mode need using several cmd buffers ?

[QUOTE=Ronniko;40610]What about VK_PRESENT_MODE_FIFO_RELAX_KHR ?
For this mode need using several cmd buffers ?[/QUOTE]

RELAX is just FIFO with tearing. It doesn’t change anything about how many images you have.

It should also be noted that if you use immediate present mode with only one swapchain image, you would be writing to the image that is currently being shown. So you’ll still need “several cmd buffers”. Unless you’re going to stall the GPU until the single swapchain image has been displayed. In which case I rather suspect you’ll lose far more performance than if you just double-buffered.

^ wait, what? The presentation engine should not hold on to that image very long (if at all). That’s why tearing happens. And that’s what people expect with “vsync off”.

BTW Is it really true NVIDIAs do not support it (yet)?

Current drivers (at least on my GTX980) support the following modes:

  • VK_PRESENT_MODE_FIFO_KHR
  • VK_PRESENT_MODE_FIFO_RELAXED_KHR
  • VK_PRESENT_MODE_MAILBOX_KHR

So no VK_PRESENT_MODE_IMMEDIATE_KHR (at least not yet).

With older drives FIFO didn’t vsync, but that has been fixed for some time now.

… I’m confused.

Tearing happens when you change images between vsyncs. Which means that the presentation image was using image X, then it switched to using image Y without doing that switch during a safe period (ie: the vsync).

Unless the presentation engine is copying data out of the presented image when you present it, I don’t see how the presentation engine could “not hold on to that image very long”. It has to hold on to it throughout the entire vsync, since that’s where it’s getting the data from to feed the display.

Granted, if it is copying it, then it’d probably be fine.

I guess, I haven’t thought about it until now. That’s one benefit of Vulkan, that it doesn’t let you believe in magic for long :slight_smile: I was thinking of old cards that wouldn’t even had space for two framebuffers, but that’s no longer relevant…

It almost certainly copies (or still magicaly use the one it gave you?). Otherwise, what would it display when you acquire the (single) image and do not present it back for a long time?
I am kinda compeled to test. To this point I used only one image for this mode, but now I see they use two in the examples too.

That could be why NVIDIA doesn’t provide IMMEDIATE. Because their presentation engine doesn’t copy. Maybe for them, swapchain images are used directly. And thus, IMMEDIATE wouldn’t be a reasonable way to present data, since it’s going to keep that image locked for almost a full frame time.

^ I don’t think so. Firstly, it works just fine in OGL. Secondly they may return minImageCount &gt; 1 which means they can always retain one Image. (Thirdly the underlying support is more of a function of OS/Windowing system support than anything else)

Possibly, they think MAILBOX mode and/or adaptive sync obsoletes it.

On AMD support:

  • VK_PRESENT_MODE_FIFO_KHR
  • VK_PRESENT_MODE_FIFO_RELAXED_KHR
  • VK_PRESENT_MODE_IMMEDIATE_KHR

But VK_PRESENT_MODE_MAILBOX_KHR not support !
If i run my program with VK_PRESENT_MODE_MAILBOX_KHR , my program crush.

PS: Stupid name MAILBOX. I remember song Secret Service - Ten O’clock Postman :slight_smile:

I don’t understand this expectation you seem to have that all hardware will support everything. The whole point of making features optional is so that hardware vendors/OSes/etc have implementation freedom.

Them taking advantage of this freedom is not something to be annoyed with. It’s something to be expected and dealt with. That’s the deal when you decided to take on low-level graphics work.

If you aren’t prepared to handle such hardware variance, then you should reconsider whether Vulkan is something you should be using.