(七) vulkan2 - Validation layers

2023-04-15 14:44 作者:FineClassFuture 0人读过 | 我要投稿

准备

前面三角形运行成功了，开始解除SDK系统安装

sudo apt autoremove vulkan-sdk libvulkan-tools

设定工作目录/opt/vulkan

下载vulkansdk-linux-x86_64-1.3.243.0.tar.gz解压

运行vkcude测试

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/vulkan/1.3.243.0/x86_64/lib/

./1.3.243.0/x86_64/bin/vkcube

如果已经安装了使用vulkan的microsoft-edge-stable或obs-studio或vlc，则系统中已经有libvulkan.so.1，需要注意和下载的SDK的版本是否一致

whereis libvulkan.so.1

libvulkan.so.1: /usr/lib/x86_64-linux-gnu/libvulkan.so.1

ls -l /usr/lib/x86_64-linux-gnu/libvulkan.so.1

/usr/lib/x86_64-linux-gnu/libvulkan.so.1 -> libvulkan.so.1.3.243

我这里和SDK一致

概念

直接使用网页翻译成中文查看，看看和自己的理解是否一致

Common operations in validation layers are:

Checking the values of parameters against the specification to detect misuse

根据规范检查参数值以检测误用
Tracking creation and destruction of objects to find resource leaks

跟踪对象的创建和销毁以查找资源泄漏
Checking thread safety by tracking the threads that calls originate from

通过跟踪调用源自的线程来检查线程安全性
Logging every call and its parameters to the standard output

将每个调用及其参数记录到标准输出中
Tracing Vulkan calls for profiling and replaying

追踪 Vulkan 需要分析和重放

下面是诊断中函数实现的示例验证层可能如下所示：

VkResult vkCreateInstance(const VkInstanceCreateInfo* pCreateInfo, const VkAllocationCallbacks* pAllocator,

VkInstance* instance)

{

if (pCreateInfo == nullptr || instance == nullptr) {

log("Null pointer passed to required parameter!");

return VK_ERROR_INITIALIZATION_FAILED;

}

return real_vkCreateInstance(pCreateInfo, pAllocator, instance);

}

前面的认识：

这样就很清楚“validation layers”是什么东西了（翻译为“验证层”也能理解）

其实就是一种debug和release模式（极端且更接近的是assert断言）

（所以不用正确翻译，就直接说是 “使能调试检查”）

在编写代码时使用debug模式，尽可能地“打印”/检查出潜在的错误；发布时release模式，去掉多余的调用/封装/检查来提高“性能”

没有问题，后面还有补充内容。

这些验证层可以自由堆叠以包含所有您感兴趣的调试功能。对于调试版本，您只需启用验证层即可，并为发布版本完全禁用它们，这为您提供了两全其美！

Vulkan没有内置任何验证层，但LunarG Vulkan SDK 提供了一组很好的层来检查常见错误。他们也是完全开源，因此，您可以检查错误。使用验证层是避免应用程序中断的最佳方法。

验证层只有在系统上安装后才能使用。例如，LunarG 验证层仅在具有已安装 Vulkan SDK中。

Vulkan 中以前有两种不同类型的验证层：实例和特定于设备。这个想法是实例层只会检查与全局 Vulkan 对象（如实例）和设备特定层相关的调用、只会检查与特定 GPU 相关的调用。设备特定层现已弃用，这意味着实例验证层适用于所有Vulkan调用。规范文档仍建议您启用验证设备级别的层以及兼容性，这是某些人所要求的实现。我们将简单地在逻辑上指定与实例相同的层设备级别，我们将在后面看到。

和理解的是差不多一个意思。

继续看。

所有有用的标准验证都捆绑到 SDK 中包含的层中，该层称为 VK_LAYER_KHRONOS_validation

下一个内容，前面删除掉的

vkCreateDebugUtilsMessengerEXT

vkDestroyDebugUtilsMessengerEXT

这两个有啥用？

为什么在创建instance时设置了callback还要调用vkCreateDebugUtilsMessengerEXT再设置一遍？

动手

先说Instance，前面的理解

Instance百度翻译：例子; 事例; 实例;

我喜欢取第一个概念，转述为创建一个“例子”（应用）并告知要求和用途

现在，用windows窗口中概念来说，vulkan instance就是“窗口”(VULKAN API)的handle; 用linux中概念来说，一个vulkan instance就是VULKAN API的descriptor (linux下有 file descriptor简称fd);

创建一个窗口，拿到handle; 创建/打开一个文件，拿到fd。

使用vulkan api，拿到instance。

（vkDestroyInstance 释放资源，才会去检查）

创建surface，不释放，然后

1. 添加教程中的CreateDebugUtilsMessengerEXT、DestroyDebugUtilsMessengerEXT

2. 不添加CreateDebugUtilsMessengerEXT、DestroyDebugUtilsMessengerEXT

没有任何区别

还得看spec，https://registry.khronos.org/vulkan/specs/1.3-extensions/pdf/vkspec.pdf

callback传递给vkCreateInstance()，只会在vkCreateInstance和vkDestroyInstance执行时才有回调对应的callback。其他时候需要使用vkCreateDebugReportCallbackEXT或者vkCreateDebugUtilsMessengerEXT来使能回调对应的callback。

这样就清楚了为什么上面测试都一样。