Vulkan API : max MSAA samples supported is VK_SAMPLE_COUNT_8_BIT

Question

I am writing Vulkan API based renderer. Currently I am trying to add MSAA for color attachment. I was pretty sure I could use VK_SAMPLE_COUNT_16_BIT ,but limits.framebufferColorSampleCounts returns bit flags that allow MSAA level up to VK_SAMPLE_COUNT_8_BIT (inclusive)

I run on a brand new NVIDIA QUADRO RTX 3000 card. I also use latest NVIDIA driver: 441.28 I checked the limits in OpenGL and GPU caps viewer shows

GL_MAX_FRAMEBUFFER_SAMPLES = 32

How does it make sense? is the limit dictated by the Vulkan API only? And if the hardware doesn't support more than x8 then does it mean OpenGL driver simulates it on CPU, e.g via stuff like supersampling? That's what I was said by several rendering developers at khronosdev.slack ? Does it make sense? Doesn't a vendor have to compile with the standard and either implement MSAA the right way or not to implement at all?

Is that possible that OpenGL doesn't "really" support more than x8 MSAA ,but the drivers simulate it via stuff like supersampling?

UPDATE

This page explains the whole state of MSAA implmentation for OpenGL and actually it becomes clear from it why Vulkan doesn't provide more than x8 samples on my card. Here is the punch line:

Some NVIDIA drivers support multisample modes which are internally implemented as a combination of multisampling and automatic supersampling in order to obtain a higher level of anti-aliasing than can be directly supported by hardware.

Windsor

Answer 1

framebufferColorSampleCounts is flags, not a count. See this enum for the values: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkSampleCountFlagBits.html

15 offers VK_SAMPLE_COUNT_1_BIT, VK_SAMPLE_COUNT_2_BIT, VK_SAMPLE_COUNT_4_BIT or VK_SAMPLE_COUNT_8_BIT.

This answers why you get 15, rather than a power of two, but it still begs the question why the NVidia driver is limiting you more than the OpenGL driver. Perhaps a question for the NVidia forums. You should double-check that your driver is up to date and that you're actually picking your NVidia card and not an integrated one.

Hackneyed

I am running on the dedicated one 100% Also using CUDA and more NVIDIA APIs in the app. So there is no way I can use Intel card here. – Windsor

Here the author treats this flag just like regular integer value: github.com/SaschaWillems/Vulkan/blob/master/examples/… – Windsor

Were do I actually treat is an integer value? I used VkSampleCountFlags where required, unless I missed a spot. – Furnishings

@SaschaWillems perhaps OP is referring to this assert: assert((deviceProperties.limits.framebufferColorSampleCounts >= sampleCount) && (deviceProperties.limits.framebufferDepthSampleCounts >= sampleCount));. – Hackneyed

Answer 2

I've also come across a similar problem (not Vulkan though, but OpenGL, but also NVidia): on my NVidia GeForce GTX 750 Ti, the Linux driver nvidia reports GL_MAX_SAMPLES=32, but anything higher than 8 samples results in ugly blurring of everything including e.g. text, even with glDisable(GL_MULTISAMPLING) for all rendering.

I remember seeing the same blurring problems when I enabled FXAA globally (via nvidia-settings --assign=fxaa=1) and ran KWin (KDE's compositing window manager) with this setting on. So I suspect this behavior with samples>=9 is because the driver enables FXAA in addition to (or instead of) MSAA.

Aubade

Another reason for blurriness is a combination of two things: - At high multisample levels the driver often actually does supersampling instead. - People often set up the projection incorrectly so all drawing is done at a slight offset from pixel centres. With multisampling the offset is invisible because it only affects the edges/intersections of polygons, but with supersampling it is immediately visible as a blur on any surface. – Offenseless