Don't build live verification tests by default. These are meant as manual tests for
developers to run to diagnose issues or verify correctness on a real system.
Since device layers are pretty much ignored, make sure that they don't
change any behavior.
Also add a few "load" entrypoint helper routines based on what was already
done elsewhere in the test system.
Some things need to be verified against real drivers. The supporting code in test_util and
test_environment make it easy to write application code which works against real drivers and
layers. This allows quickly verifying loader behavior out in the wild.
Add tests for unknown device functions queried with both vkGetDeviceProcAddr
and vkGetInstanceProcAddr. Also loops enough times to exhaust the available
unknown function supply.
Had to fix the vk_layerGetPhysicalDeviceProcAddr in TestLayer to make the tests
pass.
MacOS currently skips tests which use vkGetInstanceProcAddr. This is due to the
need for unknown functions being lower priority and so do not warrent the time
needed to write the assembly necessary to resolve the issue fully.
The handling of unknown device functions queried with vkGetInstanceProcAddr
required an additional pointer dereference to get the dispatch table.
The VkDevice handle is a pointer to the `chain_device` member of
`loader_device`. This member is actually a pointer to `loader_dispatch`, or
put another way, the "start" of `loader_device`. Thus, to get access to the
dispatch table, we need to dereference the VkDevice passed into the function
then dereference the chain_device to get loader_dispatch`.
Add tests to verify that the 3 pre-instance functions are properly
intercepted by the layer when everything is well-defined.
Also include two fixes:
1) Disable environment variable value of 0 should be treated the same as not present
2) The vkEnumerateInstanceVersion override path was broken, missing a NULL check
If a meta layer which contains `override_paths` is active, all of the paths in
VK_LAYER_PATH are ignored when searchign for explicit layers. This may be changed
changed in the future but for now is better tested and documented.
Adds 2 tests:
* ZeroPhysicalDevices - Return VK_ERROR_INITIALIZATION_FAILED if the driver has zero
physical devices.
* ZeroPhyiscalDeviceExtensions - Return VK_SUCCESS if no physical device extensions are
found.
Previously the logic of loader_add_device_extensions could return an error from
enumerating device extensions. This was because the code would return immediately
if either an error was returned from the driver or the count was zero. Now the
logic will return an error only if the driver returned an error. Zero device
extensions won't be treated as an error and will simply return VK_SUCCESS.
The loader was logging some VUID failures and it was sending them to the general
message output. Send the information also to the validation stream to make sure
that if anyone enables validation filtering they will still see those errors
Update the loader VUID messages that were added in validating handles
so that thye include the validation flag when going through debug utils
messenger.
While the DEBUG level of logging is meant for verbose output, the actual extensions
enumerated rarely are useful for the purposes of debugging the loaders behavior.
With this in mind, the loader will now no longer print all the extensions found.
There was a regression with 1.3 that meant vkGetInstanceProcAddr wouldn't be
able to query itself if instance was set for 1.3. This commit makes it possible
to query for vkGetInstanceProcAddr with itself no matter the value of instance.
Verify that using vkGetInstanceProcAddr to get an entrypoint to a device
extension works when the extension is enabled, and crashes when the
extension isn't enabled.
Also, update a copyright notice date for my last commit.
Add 2 tests to verify that physical devices supporting instance
and device extensions (which are really physical device extensions)
are properly handled.
If any ICD failed to enumerate device groups here, we would fail the call entirely, which means a broken driver for device A could prevent you from using device B. Just skip over the failing ICD instead.
We had tests that verified that instance and device extensions defined
in a layer had the non-null pointers returned from the corresponding
vkGetXXXProcAddr functions, but we weren't verifying that the functions
actually got called.
This should throw an error message if a requested layer didn't load.
This could happen if the JSON file is present, but only a library
exists on the system for the wrong target (like 32 vs 64-bit).
If it did fail because of being the wrong bit-type, we report an info
message only, unless it was directly requested by the application.
Modify the improper bit-depth layer loading test so that it is now 4
tests:
- Verify bad explicit layer generates VK_ERROR_LAYER_NOT_PRESENT error
- Verify bad implicit layer generates only an info in the loader output
- Test case with both a bad implicit and explicit layer with INFO logging
we should see both messages.
- Test case with both a bad implicit and explicit layer with ERROR logging
we should see only the explicit failure message.
Report info failure for ICD wrong bit-type as well.
Finally, fixed a small compilation warning for disabled code.
If the JSON ICD Manifest contains an api_version that has a non zero variant
value, then the ICD should be skipped since it corresponds to a Vulkan variant.
Since it is possible that API versions given to the loader have a variant
component, the loader should know how to handle them. It shouldn't use a
variant other than 0, but that is up to the caller to handle.
The VK_MAKE_API_VERSION macro and the VK_API_VERSION_1_X macros are better to
use. This commit switches the tests over to the non-deprecated versions of the
macros.
The 1.2.175 header release saw the addition of API Variants. For the purposes
of the loader, this should always be set to 0. If this value isn't zero, the
loader should warn about it.
The older VK_VERSION_XXX macros are deprecated and cause confusion when they
report a MAJOR version that is above zero. All uses of the deprecated macro are
now replaced with the correct macro.
The loader disables implicit layers if their API version isn't the same or
greater than the application. Make sure this still works even with pre 1.0
versions.
We were completely re-creating the physical device lists every time
EnumeratePhysicalDevices was triggered in the loader. This could
cause applications to have out-dated physical device handles.
We need to copy existing handles that match devices whenever they're
found.
Expand override layer documentation to include override_paths
Add Versioning and Activation Interactions section which details some of the
more complex rules around when a layer is activated or not.
