• Add exact, bits, minmul, minpot, maxpot new limit types
• Add python workarounds to fix capabilities limitype from vk.xml
• Fix noauto capabilities being interpreted incorrectly.

The Profiles Library Debug build is supposed to announce why a profile is not supported by a device, which is important for figuring out issues like:

VP_ANDROID_baseline_2021.json unsupported on ShieldTV
https://github.com/KhronosGroup/Vulkan-Profiles/issues/87

The problem was that genvp.py wasn't generating messages at every location where a profile was determined to be unsupported. These changes add messages (some more helpful than others) for all cases where support is determined to be lacking, to the generator and thus also to the generated code.

The extra debug messages confuse the MockDebugMessageCallback, which expects an exact set of messages in an exact order. Since the test doesn't mock the running device, running the test on different devices will produce different sets of messages, which cannot be easily accommodated in a generic test. So these changes also include a minor change to MockDebugMessageCallback logic, to emit unexpected messages received (for informatory purposes) without failing the test; then the test only fails if it finishes and not all expected messages were received in order.

Promoted struct should be checked against the vulkan API version instead of extension. Effective API version is determined as in validation layers. Removed TransferDeviceValues as it's no longer needed, since all checks are correct and proper warnings will be emitted. #103 will have to be rebased and updated from this

Reworked settings on layer tests to use a programmatic method instead of relying on environment variables.

This change allows tests to add a structure containing environment variable settings to the CreateInstance() pNext chain.

Incorporated review feedback, other than the layer path, which will need to be addressed with and through CI.

<answered, mostly> Open questions:

• Include all settings or just the relevant layer-specific ones?
• Struct names, default constructor, namespace issues?
• Default values for settings in VkProfileLayerSettingsEXT structure
• Left VK_LAYER_PATH in tests -- it is unusual to set this variable inside the tests themselves. Typically it is set before (and outside) running the tests to control which layer is getting tested. It is also a no-op on Android.
• Significant overlap of the LayerSettings and the VkProfileLayerSettingsEXT structures

Basically, is this suitable for using across all the layer tests or are modifications or improvements desired? All feedback is good feedback.

Added infrastructure and associated files to build the VpLibrary_test_api_create_device_android test for Android along with an installable test package. The resulting APK can then be installed and run on an Android device.

Initial cmake command (see BUILD.md for specifics):

cmake -Bandroid-build \
  -DCMAKE_TOOLCHAIN_FILE=/home/mark/gdev/android-ndk-r21d/build/cmake/android.toolchain.cmake \
  -DANDROID_PLATFORM=28 \
  -DANDROID_BUILD_TOOLS=30.0.3 \
  -DANDROID_ABI=arm64-v8a

Change into the android-build dir and run:

cmake --build . --parallel

Install the APK as follows:

adb install -r apk/out/VpLibrary_test_api_create_device_android.apk

And run the test:

adb shell am start -a android.intent.MAIN -c android-intent.category.LAUNCH -n com.example.VpLibrary_test_api_create_device_android/android.app.NativeActivity --es args --gtest_catch_exceptions=0

Test output goes to logcat, which you can pull and scrape looking for VpLibrary_test_api_create_device_android:. You should observe something like the following:

01-31 14:01:51.710  I VpLibrary_test_api_create_device_android: Intent args = --gtest_catch_exceptions=0
01-31 14:01:51.710  D VpLibrary_test_api_create_device_android: filter = --gtest_catch_exceptions=0
01-31 14:01:51.724  I VpLibrary_test_api_create_device_android: [ RUN      ] library_api.vpCreateDevice
01-31 14:01:51.735  I VpLibrary_test_api_create_device_android: [       OK ]library_api.vpCreateDevice (10 ms)
01-31 14:01:51.735  I VpLibrary_test_api_create_device_android: [ RUN      ] library_api.vpGetPhysicalDeviceProfileSupport
01-31 14:01:51.738  I VpLibrary_test_api_create_device_android: [       OK ]library_api.vpGetPhysicalDeviceProfileSupport (3 ms)
01-31 14:01:51.738  I VpLibrary_test_api_create_device_android: ==== Tests PASSED ====

For the 2022 roadmap, the profiles library has the following checks for lineWidthGranularity:

  ret = ret && (s->properties.limits.lineWidthGranularity <= 0.5);
  ret = ret && (isMultiple(0.5, s->properties.limits.lineWidthGranularity));

The second check fails if lineWidthGranularity is 0, which should be allowed by the profile if the wideLines feature is not supported (only the supported limit was lowered from 1.0 to 0.5, the unsupported limit is still 0.0).

Further, it doesn't really make sense to check that the lineWidthGranularity is a multiple of anything, since as far as I can tell that is not required by the Vulkan specification. Perhaps instead it should be checking that the lineWidthRange is a multiple of the lineWidthGranularity (but only if wideLines is supported)?

I moved the Jenkins VulkanProfiles Linux configuration from Linux-Mesa to just Linux (because the Linux-Mesa machine was going to be unavailable for a time). I thought the tests should run on any Linux machine.

They ran correctly on aurelia: http://erusea:8080/job/VulkanProfiles/1845/BITS=64,BUILD_MODE=Release,label=Linux/console

But they failed on emmeria: http://erusea:8080/job/VulkanProfiles/BITS=64,BUILD_MODE=Debug,label=Linux/1845/console

Building remotely on Emmeria-Linux-AMD (Ubuntu Linux mesa AMD Ubuntu18) in workspace /home/lunarg/.jenkins/workspace/VulkanProfiles/64-bit/Debug
...
The following tests FAILED:
      3 - VpLibrary_test_api_create_device_header_only (Failed)
      4 - VpLibrary_test_api_create_device_with_source (Failed)
      6 - VpLibrary_test_profile_examples (Failed)
     14 - VkLayer_tests (Failed)

For now, I changed the test configuration to Aurelia-Linux-NVIDIA, because that seems to work. But I believe the tests should be able to run and pass on emmeria as well.

Setting debug.vulkan.khronos_profiles.simulate_capabilities SIMULATE_API_VERSION_BIT,SIMULATE_EXTENSIONS_BIT,SIMULATE_FEATURES_BIT,SIMULATE_PROPERTIES_BIT,SIMULATE_FORMATS_BITfails.

Error message: Value [...] is too long, 115 bytes vs a max of 92