gpuinfo.org | Source for the GPU hardware databases launch page | GPU library

If a device supports geometry shaders and also VK_KHR_multiview, that doesn't mean that both can be used in conjunction. That only works if the multiviewGeometryShader property is true. When we looked at this in detail last year, we couldn't find any device (besides some NVIDIA Quardo, I think) that supported multiview with geometry or tessellation shaders.

That means that you'll not be able to use geometry shaders with the VK_KHR_multiview extension for now. A good alternative could be to use geometry shader instancing and use the geometry shader instance's invocation id to direct rendering into different layers:

When compiling GLSL using glslang into SPIR-V of any form, the available set of extensions does not care about the nature of the platform you are compiling on. After all, the whole point of an intermediate language is to be able to pre-compile your shader on one platform, then ship it in compiled form to the place where the user will execute it. That is when any extensions will be checked against the available set of extensions for that platform.

So basically, glslang assumes any extensions which could be valid for the target language are valid.

However, when compiling GLSL into SPIR-V for Vulkan consumption, the set of extensions that glslang is aware of are those extensions which are appropriate for Vulkan consumption. These extensions can be found in this GLSL Github repo. This set of extensions is specific to Vulkan.

In macOS, there's no queue count or queue family count in Metal Devices (as of July 2019), so one could create 1 or any number of queues and get full utilization of the device.

However, as noted in a GitHub issue, some programs with hardwired assumptions crashes when there's only 1 queue family, so they made MoltenVK report 4 queue families to fix it (see pull request 450).

Why "should" it be a hardware limitation?

With 4 exceptions, every Windows implementation is limited to 4096 allocations. And those exceptions are either open-source RADV hacked to run on Windows or early drivers that returned bogus values.

So clearly, Windows as an OS is imposing this limitation. After all, the OS owns the GPU and must be involved in any memory allocations.

It is the right of the OS to prevent a process from engaging in pathological behavior. Windows seems to think that making lots of GPU allocations is pathological, so the WDDM model imposes a low-but-reasonable limit on GPU allocations.