Strange validation layer messages

Hi,

I’ve just started with a few tutorials on Vulkan. After enabling validation layers, I get the following messages after calling vkCreateDevice:

vkCreateSampler: parameter pCreateInfo->flags must be 0
vkCreateSampler: value of pCreateInfo->anisotropyEnable (1258318117) is neither VK_TRUE nor VK_FALSE
vkCreateSampler: value of pCreateInfo->compareEnable (-2) is neither VK_TRUE nor VK_FALSE

This happened with both 1.0.42.1 and the latest 1.0.49.0 and occured in different code bases, including my own (created from Staging buffer - Vulkan Tutorial) and the tutorial code at API without Secrets: Introduction to Vulkan* Part 2: Swap Chain (after implementing the debug callback, obviously). I do not remember it happening the first time I ran the tutorial code, however I can not reproduce it not happening.

The Debug callback is loaded after adding the “VK_LAYER_LUNARG_standard_validation” layer and the VK_EXT_DEBUG_REPORT_EXTENSION_NAME extension to the instance creation info. The code loading the callback is below and the callback itself just prints the message.

VkDebugReportCallbackCreateInfoEXT createInfo = {};
createInfo.sType = VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT;
createInfo.flags = VK_DEBUG_REPORT_ERROR_BIT_EXT | VK_DEBUG_REPORT_WARNING_BIT_EXT;
createInfo.pfnCallback = CALLBACK_Debug;

if (vkCreateDebugReportCallbackEXT(Vulkan.Instance, &createInfo, nullptr, &Vulkan.DebugCallback) != VK_SUCCESS) {
std::cout << “Failed to set up debug callback!” << std::endl;
return false;
}

return true;

I could not find any information about this. It seems to originate from something internal, as I have not called vkCreateSampler anywhere and all structs are default-initialized with braces. Is this known behaviour or even expected? Or something to be ignored? Or perhaps it has something to do with my GPU? Or perhaps I simply made a strange mistake multiple times?

      • Updated - - -

Enabling more detailed debugging flags also tells me there is in fact a sampler object being created. There is the following message right after the vkCreateSampler warning messages I posted above.

OBJ[0xa] : CREATE Sampler object 0x6

No, it is not normal behavior.
Also I do not get these errors trying the code of the vulkan-tutorial you link.

If you add a debug break point to the debug message callback function that outputs the message, the call stack should tell you where the message originates from. I don’t see any sampler getting created in the vulkan tutorials code you posted, but the call stack from the debug break point should direct you to that point.

Yes, I had already done this, of course. Maybe it wasn’t clear, but there really is no call to vkCreateSampler in my code. The call stack points me to vkCreateDevice.

I also noticed today that there is a slight difference in the following message:

vkCreateSampler: value of pCreateInfo->anisotropyEnable (1342204197) is neither VK_TRUE nor VK_FALSE

The difference being the number between parenthesis, which changes can apparently change, seems like some pointers is pointing to an invalid location. I thought maybe it’s a 64-bit thing, so I compiled for 32 bits as well, which, interestingly, results in ONLY the first validation layer message. Switching back to 64 gives me all three again and changes the number between parenthesis.

Update to 1.0.51 SDK, if it changes anything.

You should state your platfom for our information. I.e. OS + GPU + driver. And those should preferrably be updated too.

Try VK_LAYER_LUNARG_api_dump to see what is called. Try it with, and without other layers enabled, if it changes anything.

is it possible that you just enable all instance layers available on your setup? If so you may have enabled other layers beside the validation only layers and one of that may create a sampler and cause the validation layer message.

I use Windows 10, GeForce GTX 980M and have just updated the drivers. No change after that or updating the SDK to 1.0.51.

There are no other layers enabled. There are no device features enabled. There are three instance extensions enabled: VK_EXT_debug_report, VK_KHR_surface, VK_KHR_win32_surface. One device extension: VK_KHR_swapchain. I have tried disabling the swapchain extension, it did not change the outcome. The only thing I do not control up to this point is the window and surface creation, done with glfw.

Using VK_LAYER_LUNARG_api_dump with and without other layers does not seem to change much; in both cases a call to vkCreateSampler is in there. Between the call to vkCreateDevice and the next line of code, the api dump outputs the following api calls (with the swapchain extension disabled):

  • vkCreateDevice
  • vkCreateCommandPool
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkAllocateCommandBuffers
  • [Here come in the validation layer messages]
  • vkCreateSampler
  • vkCreateDescriptorSetLayout
  • vkCreatePipelineLayout
  • vkCreateDescriptorPool
  • vkAllocateDescriptorSets

For the intel code (which doesn’t have window or surface creation in the first tutorial code sample) the same happens, except that enabling both the api_dump and the standard_validation layer names seems to only activate whichever comes first. The rest of the output is identical.

The Vulkan SDK samples that I just built also give me a similar result. After enabling validation layers in [03-init_device] by adding this before the call to init_instance():

info.instance_extension_names.push_back(VK_EXT_DEBUG_REPORT_EXTENSION_NAME);
info.instance_layer_names.push_back(“VK_LAYER_LUNARG_standard_validation”);

, the resulting warning message I get is:

ParameterValidation(ERROR): object: 0x0 type: 0 location: 667 msgCode: 5: vkCreateSampler: parameter pCreateInfo->flags must be 0

In the example, the API calls shown by api_dump during the call to vkCreateDevice are:

  • vkCreateDevice
  • vkGetPhysicalDeviceProperties
  • vkGetPhysicalDeviceQueueFamilyProperties
  • vkGetPhysicalDeviceQueueFamilyProperties
  • vkGetPhysicalDeviceMemoryProperties
  • vkGetPhysicalDeviceProperties
  • vkGetPhysicalDeviceQueueFamilyProperties
  • vkGetPhysicalDeviceQueueFamilyProperties
  • vkGetPhysicalDeviceProperties
  • vkCreateCommandPool
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkAllocateCommandBuffers
  • [parameter validation error]
  • vkCreateSampler
  • vkCreatePipelineLayout
  • vkCreateDescriptorPool
  • vkAllocateDescriptorSets

It very much seems like something internal to Vulkan is going wrong. Anything else I can do to figure out a possible cause?

I forgot to mention, I am using visual studio community 2013.

the call to vkCreateDevice and the next line of code, the api dump outputs the following api calls (with the swapchain extension disabled):

  • vkCreateDevice
  • vkCreateCommandPool
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkCreateShaderModule
  • vkAllocateCommandBuffers
  • [Here come in the validation layer messages]
  • vkCreateSampler
  • vkCreateDescriptorSetLayout
  • vkCreatePipelineLayout
  • vkCreateDescriptorPool
  • vkAllocateDescriptorSets

Which of the above is the “next line of code”? If you are saying it happens during vkCreateDevice, then I see there much more spurious commands being called then just vkCreateSampler. Just curious…

If your reporting can be trusted, we excluded layers to be the guilty party (the explicit ones anyway).

GLFW should not matter if it truly happens inside vkCreateDevice duration.

It very much seems like something internal to Vulkan is going wrong. Anything else I can do to figure out a possible cause?

So that still leaves too many suspects: explicit layers, other injected dlls, the loader and the driver.
It would be odd the driver causes another roundtrip through layers. Somebody would also probably already noticed. Then again I also get a report in AMD about malformed driver json, and nobody complained yet, so possibly people just ignore it if shit just works…
Implicit layers should also (could be wrong) show with VK_DEBUG_REPORT_DEBUG_BIT_EXT. E.g. “Loading layer library <dllname>” report. There are not particulary many of implicit layers and usually are disabled anyway unless e.g. run through Steam.
Injected dlls would show in VS in debugging mode if you pause. It is in the Modules tab. There are bunch of benign dlls there, but sometimes e.g. mouse software package or screen cap soft gets the bright idea to inject itself to all processes.

My bet would be on a Implicit layer or injected dll to be the guilty party. Based on the api_dump command it looks like something that wants to draw something to screen. E.g. fps counter, mouse soft showing current DPI, maybe screen capture software or some such. Would also explain why there is not yet some “me too” report yet (i.e. it is a situation more specific to your PC).

One other thing you can try is to install the beta drivers: https://developer.nvidia.com/vulkan-driver

Another thing you could try is to make a breakpoint inside your debug callback function and let it stop there when you get this report. The callstack would have bunch of *.dlls there between your program and the callback. Something could be infered from that info… (I belive that is what Sasha above suggested).

Okay, with that hint about the call stack and injected dlls I’m pretty sure I have found the culprit to be bdcamvk64.dll, which is a dll related to recording software named Bandicam. Uninstalling it resolved the issue. There were more dlls in there, but I forgot to actually write that down before I uninstalled Bandicam. It makes sense I did not see the problem before, as I installed it a while after I started with Vulkan.

I didn’t even know dll injection was a thing, though. I did not find a single running process that seemed related to bandicam, so it really makes me wonder. I’ll have to read some about that.

Thanks for your help!

Are there any typical ways to avoid these kinds of interferences when dealing with (GPU) debugging issues?

Okay, with that hint about the call stack and injected dlls I’m pretty sure I have found the culprit to be bdcamvk64.dll, which is a dll related to recording software named Bandicam. Uninstalling it resolved the issue.

Indeed, mon ami Hastings. My little grey cells told me one of these miscreants is the perpetraitor.

I didn’t even know dll injection was a thing, though. I did not find a single running process that seemed related to bandicam, so it really makes me wonder. I’ll have to read some about that.

Yeah I did not always knew either. In retrospect it is a bit of magical thinking. How did I ever think things like Fraps (video capture + showing FPS) and such work??

In Windows there is basically a registry list of dlls that are to be loaded with all executed processes. That’s why you don’t see any Bandicam process. The injected dll does all the work INSIDE other processes. It usually then asks for “hooks” on system calls it is interested in, and so intercepts them.

bdcamvk64.dll is probably an Vulkan Implicit Layer though. (You can read https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md) Which is not that dissimilar from the above. The advantages is they are not always loaded. They have enable, and disable (veto) keyword (https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md#layer-manifest-file-format). If you do not want to fully uninstall the software, then you can use the disable keyword via environment variable to disable the Implicit layer temporarily for subsequent executed Vulkan apps. Unfortunatelly (TMK) there is no “disable all implicit layers” keyword (yet).

You’re correct, the bandicam dll is an implicit layer. I found it in my registry after browsing through the link you gave me. I spoke to one of the bandicam devs earlier and he told me about a batch file called “UnregVulkanLayer.bat”, which removes it from the registry. Similarly, there’s one to add it again. Like you say, the layer can be disabled through an environment variable (as described here) For anyone interested, for bandicam, the environment variable to disable this layer is (right now) “VK_LAYER_bandicam_helper_DEBUG_1”, which can be found in the JSON referenced by the registry. A name more consistent with the others would be something starting with DISABLE, but anyway… The value of this environment variable has to be something other than an empty string for it to disable the layer (I found this to be the case through trial & error).

There were a few more implicit layers I didn’t know about, amongst which RenderDoc, steam overlay and, interestingly, what I thought was my video driver, an implicit layer related to NVidia Optimus, which optimizes laptop battery lifetime. Disabling them does not change anything, only bandicam seems to have an influence on the validation layer messages, so it isn’t some weird interaction.

The documentation you linked mentions an environment variable for developers to override where layers are being looked for, VK_LAYER_PATH. I guess this might work to exclude any unknown layers? I imagine you’ll have to add the SDK path to this list as well to use the default explicit layers that come with the SDK.

You can direct the loader to look for layers in a specific folder by defining the “VK_LAYER_PATH” environment variable. This will override the mechanism used for finding system-installed layers.

If “VK_LAYER_PATH” exists, onlythe folders listed in it will be scanned for layers.

Okay, so, I explicitly enabled the implicit steam layer using the Enable environment variable available in their JSON. As mentioned in the table in this section, if a layer does not define an Enable keyword, it is always enabled, which is the case with the Bandicam layer. If I enable both the Bandicam and Steam layers, my application crashes (!). If I enable just the Steam layer, I get the same validation errors as with the Bandicam layer, minus the one about the flags parameter.

This begs the question: What happens if I run a Steam game that uses the Vulkan API, with Bandicam installed?

In conclusion, I still do not know WHY it happens. Would Steam and Bandicam have a very similar error in their code? Or is something else going on here?

The Bandicam developer told me it was an error in their code! Problem solved. The issue with the steam overlay was strange, but I’ll just blame it on the computer fairies. :stuck_out_tongue:

Thanks for all the help.

It is called “undefined behavior”. After you mis-use Vulkan, from that point in time forward anything can happen, including everything working just fine or your computer becoming sentient and chomping your head off.

More practically if the steam layer was after the offending layer in the chain and so it received the corrupted struct from bandicam it may have crash just because it received unexpected (illegal) Vulkan data (e.g. think trying to dereference unexpected nullptr and such).

Steam overlay is not necessarily bugless, mind you (there is at least one bug I know of).