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.
Add 4 tests:
* Shows the override_paths object in the layer manifest is being used to find a
layer.
* Shows that regular explicit layers are not found
* Shows that the log properly identifies meta layers which have an
override_paths object but shouldn't according to their manifest.
* Shows that implicit layers not in the override paths are not found.
Several version checks were underspecified and either caused false positives
or didn't catch version violations.
For example, a manifest version 1.2.0 is valid but would emit warnings implying
the version is less than 1.1.
Increasingly it is common to need more control over what the framework
environment does when adding layers. While only a refactor, this change
makes it easier to extend the functionality by adding data to the
TestLayerDetails struct.
The code to check whether the lib_path specified in add_layer_impl was
improved by using the `.stem()` functionality of the fs::path abstraction.
size_t was replaced with uint32_t where the compiler gave warnings.
It is good practice to make use of equality checks vs comparison checks where
possible. Here, the number of extensions is knowable, as its debug_report +
debug_utils + however many come from implicit layers, which some tests do.
This allows easily checking that the returned list of extensions or layers
is a valid permutation. Since the order of layers and extensions isn't
deterministic, tests cannot rely on the returned order to verify the output.
Add tests for:
ExplicitMetaLayer - meta layer found in explicit paths
MetaLayerNameInComponentLayers - meta layer contains itself
MetaLayerWhichAddsmetaLayer - when a meta layer enables another meta layer
InstanceExtensionInComponentLayer - instance extension propagation
DeviceExtensionInComponentLayer - device extension propagation
OverrideMetaLayer.OlderVersionThanInstance - Checks behavior of override layer
if the applications version is greater.
