When ran with --mode demo the results look good with Vulkan, but with D3D11 one gets a warning due to MSAA, and nothing on screen:

Resolve source and destination formats do not match

This is from QRhi when it is about to generate the ResolveSubresource.

Same for Vulkan (but only validation warning, rendering looks correct with NVIDIA at least, which is somewhat confusing)

vkDebug: Validation: 0:  [ VUID-VkSubpassDescription-pResolveAttachments-00850 ] Object: VK_NULL_HANDLE (Type = 0) | ValidateCreateRenderPass():  Subpass 0 pColorAttachments[0] resolves to an attachment with a different format. color format: 37, resolve format: 109. The Vulkan spec states: If pResolveAttachments is not NULL, each resolve attachment that is not VK_ATTACHMENT_UNUSED must have the same VkFormat as its corresponding color attachment (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkSubpassDescription-pResolveAttachments-00850)

This is because the postprocessing effects like to work with a float texture. However, multisample resolve between textures is only valid when the formats match (in Vulkan and D3D at least). So resolving a RGBA8 renderbuffer/texture into a RGBA32F texture is invalid, even though some implementations seem to handle this (e.g. with Vulkan on NVIDIA I get a validation warning but no visual errors, etc.). OpenGL just works, but that's because glBlitFramebuffer allows this explicitly.

The problem is not there when either MSAA is not used (because then we render directly into the texture, be it RGBA8 or RGBA32F), or when effects are not used (because then the texture into which we are resolving is RGBA8, not RGBA32F)

In addition using a RGBA8 renderbuffer also loses precision, compared to RGBA32F.

So what we need is a way to tell our preferred format to QRhiRenderBuffer, instead of letting it default to whatever it feels like (RGBA8, typically).