| commit | a90793e52ee4d30738154e5647605561c4696dad | [log] [tgz] |
|---|---|---|
| author | Arno <arno@lunarg.com> | Mon Dec 30 13:53:47 2024 +0100 |
| committer | arno-lunarg <111733687+arno-lunarg@users.noreply.github.com> | Thu Jan 02 12:15:32 2025 +0100 |
| tree | 2bbf1070fd376006266f146d8020a59ab7992cb3 | |
| parent | 38636311d05c399748e7953a8e475cc2c47818d4 [diff] |
tests: Reworked a bit driver info printing logic A funny issue showed up while investigating issue #9109 When ran on his own, NegativeDeviceFeatureProperty.PhysicalDeviceFeatures2 would fail (expected error not emitted), but would succeed when running the whole NegativeDeviceFeatureProperty test suite. I traced back the issue to the driver info printing logic: for this info to be printed, the VK_KHR_get_physical_device_properties2 ext is needed. It was automatically added when trying to print the driver info, but only if said info had not already been printed. This explains the issue I was seeing. I decided to just stop adding this extension under the hood. Caveat is if running a 1.0 test that does not add this extension, driver info will now not be printed. I personnally don't like when extensions or features are activated under the hood, to avoid the type of problems described above. But being to print driver info no matter what is convenient, so I will abide by team ruling on that matter. Also, the "print driver info logic" just works out of luck. Not much value in spending the time to do it properly, so I won't. I described the problem in a new comment, inlined here: The logic behind "printing the driver info only once" works out of luck. The test suite implicitly relies on the fact that VVL shared library loads and unloads (between tests) happen in the same memory region, preserving statically initialised values. At least simple values like "driver_printed", that do not get destroyed or memset to 0.
Vulkan is an Explicit API, enabling direct control over how GPUs actually work. By design, minimal error checking is done inside a Vulkan driver. Applications have full control and responsibility for correct operation. Any errors in how Vulkan is used can result in a crash. This project provides Vulkan validation layers that can be enabled to assist development by enabling developers to verify their applications correct use of the Vulkan API.
For those who don't want to build from source, there are few ways to get working binaries to use
Before submitting an issue to the validation layers or reaching out to the developers it may be prudent to reach out to the community first. These resources can be helpful to refine your issue, work out an application/driver bug, etc.
The Validation Layers are broken up as many smaller internal “Validation Objects” each tasked with their own job. Core Checks is what is enabled by default, but there are other validation objects that can be additionally enabled, such as Synchronization Validation, GPU Assisted Validation, and more. There are also a few limitations stemming from the Validation layers being a Vulkan layer.
Updates to this repository which correspond to a new Vulkan specification release are tagged using the following format: v<version> (e.g., v1.3.266).
Note: Marked version releases have undergone thorough testing but do not imply the same quality level as SDK tags. SDK tags follow the vulkan-sdk-<version>.<patch> format (e.g., vulkan-sdk-1.3.266.0).
This scheme was adopted following the 1.3.266 Vulkan specification release.
Weekly automated (and untested) tags are generated with the following format: snapshot-<year>wk<week-number>, eg. snapshot-2024wk06.
This work is released as open source under a Apache-style license from Khronos including a Khronos copyright.
See LICENSE.txt for a full list of licenses used in this repository.
While this project has been developed primarily by LunarG, Inc., there are many other companies and individuals making this possible: Valve Corporation, funding project development; Google providing significant contributions to the validation layers; Khronos providing oversight and hosting of the project.