1. 项目概述Vulkan 初始化路上的第一道坎很多从 OpenGL 转过来的同学第一次写出 Vulkan 的vkCreateInstance之后都会对着下一步发愣接下来该干嘛OpenGL 那套“glGetString(GL_VERSION)完事直接干活”的思路在 Vulkan 里彻底行不通了。Vulkan 是一个“显式 API”它把所有决策权都交给你但也把所有的调查工作都推给了你这块显卡到底支持哪些扩展、特性开没开、数量上限是多少、某个格式到底能不能拿来当渲染目标……这些问题驱动不会替你判断也不会给你“默认答案”。你必须主动调用一整套查询函数把信息拿回来再决定后面怎么创建逻辑设备、怎么配置交换链、怎么布置管线。这篇文章不聊画三角形聊的是画三角形之前那一段“查户口”的流程也就是标题里那串关键词Properties属性、Extensions扩展、Features特性、Limits限制、Formats格式以及最后怎么把查到的扩展真正“启用”起来。适合谁看两种人。第一种是刚跑通vkCreateInstance和vkCreateDevice的入门者你正需要把零散的代码片段串联成一套完整的“查询启用”链路。第二种是做多平台兼容的老手你想系统性整理一遍 Vulkan 1.1/1.2/1.3 时代查询流程有哪些变化哪些扩展已经核心化、哪些还非得手动启用。这篇文章里的代码骨架我实测跑过可以直接当模板抄。2. 属性查询基础实例层与设备层各查什么2.1 先分清三层对象实例、物理设备、逻辑设备Vulkan 的对象层级和 OpenGL 的“全局单例”思路完全不同。理解这三层对象的区别是理解查询函数归属的前提。实例VkInstance是应用和 Vulkan loader加载器之间建立的“会话”。创建实例时需要告诉 loader我要用哪些全局扩展、哪些验证层。OpenGL 没有这个概念Vulkan 把“应用与驱动之间的一次连接”显式建模成了对象。物理设备VkPhysicalDevice是显卡硬件本身。注意它不是一个可操作的对象而是“只读的体检报告”。你没有办法在物理设备上直接提交命令只能通过查询接口看它支持什么、不支持什么。每个实例下可能有多个物理设备比如笔记本上的核显和独显它们各自是一份独立的属性表。逻辑设备VkDevice才是你真正拿来干活的“工作手柄”。创建逻辑设备时你从物理设备的“体检报告”里圈出要用的特性、扩展、队列然后驱动为你在软件层面创建一个和硬件交互的接口。命令缓冲区提交、同步操作、内存分配……全部挂在 VkDevice 上。理解了这个三层结构你就能解释为什么有些查询函数的第一个参数是VkInstance比如vkEnumeratePhysicalDevices有些是VkPhysicalDevice比如vkGetPhysicalDeviceProperties而扩展又分成 Instance Extension 和 Device Extension 两种。对象层级不同查询入口和生命周期也完全不同。2.2 实例层查询版本、图层与实例扩展创建实例之前有两件“户口档案”值得先看一眼Vulkan 版本和实例扩展列表。先查版本。Vulkan 1.1 之后可以用vkEnumerateInstanceVersion拿到 loader 支持的 API 版本uint32_t apiVersion VK_API_VERSION_1_0; // 兜底值 PFN_vkEnumerateInstanceVersion vkEnumerateInstanceVersion reinterpret_castPFN_vkEnumerateInstanceVersion( vkGetInstanceProcAddr(nullptr, vkEnumerateInstanceVersion)); if (vkEnumerateInstanceVersion) { vkEnumerateInstanceVersion(apiVersion); } printf(Instance API Version: %d.%d.%d\n, VK_VERSION_MAJOR(apiVersion), VK_VERSION_MINOR(apiVersion), VK_VERSION_PATCH(apiVersion));在 Vulkan 1.0 环境下vkEnumerateInstanceVersion不存在所以先用vkGetInstanceProcAddr探测一下再调用这是老设备兼容性的基本操作。紧接着是图层Layer。图层是 Vulkan 特有的“拦截器”机制验证层Validation Layer就是最典型的图层。先枚举再创建是标准姿势uint32_t layerCount 0; vkEnumerateInstanceLayerProperties(layerCount, nullptr); std::vectorVkLayerProperties layers(layerCount); vkEnumerateInstanceLayerProperties(layerCount, layers.data()); for (const auto layer : layers) { printf(Layer: %s | spec %u | impl %u | %s\n, layer.layerName, layer.specVersion, layer.implementationVersion, layer.description); }然后是实例扩展。Vulkan 里扩展是“事后打补丁”的官方机制核心规范没覆盖的能力通过扩展来补充。比如我要在 Windows 上创建窗口 surfaceVK_KHR_surface和VK_KHR_win32_surface就是必须的实例扩展。查询方式和图层一样先问数量再拿数据uint32_t extCount 0; vkEnumerateInstanceExtensionProperties(nullptr, extCount, nullptr); std::vectorVkExtensionProperties extensions(extCount); vkEnumerateInstanceExtensionProperties(nullptr, extCount, extensions.data()); for (const auto ext : extensions) { printf(Instance Extension: %s (spec %u)\n, ext.extensionName, ext.specVersion); }这里第一参数传nullptr表示查询全局扩展如果传某个图层名返回的是该图层提供的扩展。后面讲设备扩展时还会遇到同一个函数族。2.3 设备层查询物理设备与队列族实例创建好之后接下来枚举物理设备uint32_t deviceCount 0; vkEnumeratePhysicalDevices(instance, deviceCount, nullptr); if (deviceCount 0) { // 没有可用的 Vulkan 物理设备直接退出 return; } std::vectorVkPhysicalDevice physicalDevices(deviceCount); vkEnumeratePhysicalDevices(instance, deviceCount, physicalDevices.data());拿到VkPhysicalDevice之后队列族Queue Family查询是紧接着必须要做的一件事。我见过很多初学者直接假设物理设备 0 号队列族一定能做图形计算结果在 Intel 核显或某些移动 GPU 上报VK_ERROR_INITIALIZATION_FAILED。正确做法永远是先查uint32_t queueFamilyCount 0; vkGetPhysicalDeviceQueueFamilyProperties(physicalDevice, queueFamilyCount, nullptr); std::vectorVkQueueFamilyProperties queueFamilies(queueFamilyCount); vkGetPhysicalDeviceQueueFamilyProperties(physicalDevice, queueFamilyCount, queueFamilies.data()); for (uint32_t i 0; i queueFamilyCount; i) { printf(Queue family %u: flags%s%s%s count%u\n, i, (queueFamilies[i].queueFlags VK_QUEUE_GRAPHICS_BIT) ? G : -, (queueFamilies[i].queueFlags VK_QUEUE_COMPUTE_BIT) ? C : -, (queueFamilies[i].queueFlags VK_QUEUE_TRANSFER_BIT) ? T : -, queueFamilies[i].queueCount); }VkQueueFlags的位组合告诉你这个队列族能干哪些活图形、计算、传输、稀疏绑定等。实际创建逻辑设备时要按队列族索引去填充VkDeviceQueueCreateInfo所以这里查到的数据是后续所有操作的基石。3. 扩展查询与启用从枚举到创建的完整链路3.1 实例扩展和设备扩展各管各的扩展分两个层级这个区分直接决定你在哪个阶段启用它。实例扩展作用于 loader 和实例层面影响的是“应用如何与 Vulkan 环境交互”。典型的有VK_KHR_surface抽象窗口表面、VK_KHR_win32_surface或VK_KHR_xcb_surface平台特定表面、VK_EXT_debug_utils调试回调。它们在创建VkInstance时通过VkInstanceCreateInfo传入。设备扩展作用于物理设备/逻辑设备层面影响的是“这块显卡到底能额外提供什么能力”。最典型的是VK_KHR_swapchain交换链几乎每个图形应用都必开其他还包括VK_KHR_dynamic_rendering1.3 核心化前是扩展、VK_EXT_descriptor_indexing等。设备级扩展在创建VkDevice时通过VkDeviceCreateInfo传入。这里有一个所有新手都会看晕的点一个扩展是不是“核心”了Vulkan 1.1 把一批扩展吸收进了核心规范比如VK_KHR_maintenance1、VK_KHR_get_physical_device_properties2、VK_KHR_bind_memory2等。Vulkan 1.2 又吸收了VK_KHR_imageless_framebuffer、VK_KHR_uniform_buffer_standard_layout等一大批。Vulkan 1.3 则把VK_KHR_dynamic_rendering、VK_KHR_synchronization2等并入核心。核心化之后你不需要再枚举和启用这些扩展直接用对应的核心函数比如vkCmdBeginRendering即可。但VK_KHR_swapchain是个例外——一直到现在它都没有被并入任何核心版本每次都要手动启用。这是我踩过最实在的一个坑换了 Vulkan 1.3 的设备以为所有东西都“核心化”了结果vkCreateDevice没带VK_KHR_SWAPCHAIN_EXTENSION_NAME创建交换链时直接VK_ERROR_EXTENSION_NOT_PRESENT。3.2 枚举设备扩展的标准代码枚举设备扩展的函数签名和实例版几乎一样只是第一个参数变成了物理设备uint32_t extCount 0; vkEnumerateDeviceExtensionProperties(physicalDevice, nullptr, extCount, nullptr); std::vectorVkExtensionProperties deviceExtensions(extCount); vkEnumerateDeviceExtensionProperties(physicalDevice, nullptr, extCount, deviceExtensions.data()); for (const auto ext : deviceExtensions) { printf(Device Extension: %s (spec %u)\n, ext.extensionName, ext.specVersion); }注意这里仍然可以传图层名做第二参数但设备层在 Vulkan 1.0 之后就已经从规范里移除了所以不用管。光枚举还不行我还得判断“我要用的扩展到底在不在列表里”。写一个辅助函数后面创建实例和设备时都用得上bool hasExtension(const std::vectorVkExtensionProperties available, const char* name) { for (const auto ext : available) { if (strcmp(ext.extensionName, name) 0) { return true; } } return false; }判断以后把需要的扩展名拼成std::vectorconst char*传给创建函数。这里有个隐藏的“坑”必须保证扩展名字符串的生命周期覆盖vkCreateInstance/vkCreateDevice调用期间。用字符串字面量或全局static const char*[]最稳妥别图省事用局部std::string然后.c_str()传出去调用结束后临时对象析构指针悬空驱动行为直接未定义。3.3 启用扩展从 VkInstanceCreateInfo 到 VkDeviceCreateInfo启用扩展本质就是把扩展名字符串数组塞进创建信息结构体。先看实例std::vectorconst char* instanceExtensions { VK_KHR_SURFACE_EXTENSION_NAME, #ifdef _WIN32 VK_KHR_WIN32_SURFACE_EXTENSION_NAME #else VK_KHR_XCB_SURFACE_EXTENSION_NAME #endif }; // 调试扩展按需加入 if (hasExtension(instanceExtList, VK_EXT_DEBUG_UTILS_EXTENSION_NAME)) { instanceExtensions.push_back(VK_EXT_DEBUG_UTILS_EXTENSION_NAME); } VkInstanceCreateInfo instanceCI{}; instanceCI.sType VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO; instanceCI.enabledExtensionCount static_castuint32_t(instanceExtensions.size()); instanceCI.ppEnabledExtensionNames instanceExtensions.data();创建设备时同理但还要带上队列信息。设备扩展的启用逻辑和实例扩展完全一致只是pEnabledFeatures这个字段很关键——它就是下一节要讲的“特性”的落地点std::vectorconst char* deviceExtensions { VK_KHR_SWAPCHAIN_EXTENSION_NAME }; VkDeviceQueueCreateInfo queueCI{}; queueCI.sType VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO; queueCI.queueFamilyIndex graphicsQueueFamilyIndex; queueCI.queueCount 1; VkDeviceCreateInfo deviceCI{}; deviceCI.sType VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO; deviceCI.queueCreateInfoCount 1; deviceCI.pQueueCreateInfos queueCI; deviceCI.enabledExtensionCount static_castuint32_t(deviceExtensions.size()); deviceCI.ppEnabledExtensionNames deviceExtensions.data(); VkPhysicalDeviceFeatures features{}; features.samplerAnisotropy VK_TRUE; // 经过查询确认后才这样写 deviceCI.pEnabledFeatures features; VkDevice device VK_NULL_HANDLE; if (vkCreateDevice(physicalDevice, deviceCI, nullptr, device) ! VK_SUCCESS) { // 创建逻辑设备失败 }这里有个细节要命pEnabledFeatures指向的VkPhysicalDeviceFeatures结构体必须在vkCreateDevice返回之后继续保持有效吗不需要。驱动会在创建逻辑设备时把信息拷贝走。所以你完全可以用栈上临时变量。但反过来如果你想启用的特性硬件根本不支持驱动会报错或行为未定义——所以创建逻辑设备之前必须先查询特性Features确认支持以后再启用。3.4 扩展名中的“强转结构体”pNext 链与扩展结构体前面讲的扩展启用都是“按名字启用”。但随着 Vulkan 版本迭代出现了一种更隐蔽的扩展用法通过在结构体的pNext链上挂扩展结构体来启用或查询能力。比如VkPhysicalDeviceFeatures2这类带2后缀的结构它们遵守“核心结构 pNext 扩展结构”的约定。你创建一个VkPhysicalDeviceVulkan12Features把它挂到VkDeviceCreateInfo::pNext上就等于告诉驱动“我要用 Vulkan 1.2 的某些特性”并且“请按这个配置创建设备”VkPhysicalDeviceVulkan12Features vulkan12Features{}; vulkan12Features.sType VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_2_FEATURES; vulkan12Features.drawIndirectCount VK_TRUE; vulkan12Features.shaderInt8 VK_TRUE; deviceCI.pNext vulkan12Features;这种写法在较新的设备上比逐字段填VkPhysicalDeviceFeatures更精细因为像drawIndirectCount这种能力根本没有对应的“老字段”。启用之前你应该用vkGetPhysicalDeviceFeatures2查询这些值到底是否为VK_TRUE确认后再写死。查询和启用永远是一对。4. 特性与限制不要想当然要查表4.1 vkGetPhysicalDeviceFeatures粗粒度特性开关VkPhysicalDeviceFeatures是一个超级大的布尔结构体里面几十个字段从robustBufferAccess、fullScreenExclusive直到vulkanMemoryModel等。查询方法很简单VkPhysicalDeviceFeatures deviceFeatures; vkGetPhysicalDeviceFeatures(physicalDevice, deviceFeatures); printf(Sampler Anisotropy: %s\n, deviceFeatures.samplerAnisotropy ? supported : NOT supported); printf(Geometry Shader: %s\n, deviceFeatures.geometryShader ? supported : NOT supported);每个字段都是VkBool32本质上就是uint32_t取值为VK_TRUE1或VK_FALSE0。最经典的教训来自各向异性过滤。很多入门的 Vulkan 教程上来就写features.samplerAnisotropy VK_TRUE根本不查。遇到不支持的老显卡validation layer 直接给你刷一排VUID-VkDeviceCreateInfo-pEnabledFeatures-04896之类的报错。虽然很多驱动会选择“静默忽略”但这属于未定义行为不能赌。正确流程先vkGetPhysicalDeviceFeatures查询支持才在pEnabledFeatures里开不支持就退而求其次用VK_FALSE或换算法。4.2 vkGetPhysicalDeviceFeatures2扩展特性的正确入口Vulkan 1.1 引入了vkGetPhysicalDeviceFeatures2它比老接口多了一个pNext链可以一次查询“基础特性 扩展特性”。在 Vulkan 1.0 设备上需要VK_KHR_get_physical_device_properties2扩展支持函数名叫vkGetPhysicalDeviceFeatures2KHR在 1.1 上直接用核心函数即可。我实际项目里一般这么写VkPhysicalDeviceFeatures2 features2{}; features2.sType VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2; VkPhysicalDeviceVulkan11Features vulkan11Features{}; vulkan11Features.sType VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_1_FEATURES; features2.pNext vulkan11Features; VkPhysicalDeviceVulkan12Features vulkan12Features{}; vulkan12Features.sType VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_2_FEATURES; vulkan11Features.pNext vulkan12Features; vkGetPhysicalDeviceFeatures2(physicalDevice, features2); printf(shaderFloat16: %s\n, vulkan12Features.shaderFloat16 ? Y : N);这个链式结构的好处是一次调用把所有功能块的“支持情况”全拿回来。注意pNext链的顺序没有严格要求但每个结构体的sType必须正确否则驱动直接拒绝。这条规矩贯穿所有 Vulkan 结构体——尤其是我下面会讲的查询属性时。创建逻辑设备时你可以把同一组扩展特性结构体挂到VkDeviceCreateInfo::pNext上相当于“查询时看过的创建时启用”。这也是 Vulkan 1.1 推荐的新路径pEnabledFeatures里的VkPhysicalDeviceFeatures只能表达老特性扩展特性必须靠 pNext 链。4.3 VkPhysicalDeviceLimits一堆数字的实用意义VkPhysicalDeviceLimits是VkPhysicalDeviceProperties里一个巨大的内嵌结构体里面几十个uint32_t、VkDeviceSize、VkExtent3D字段定义了各种“上限”。我常用的几个maxImageDimension2D2D 纹理最大边长很多驱动是 16384 或 32768创建超大纹理前查一下。maxBoundDescriptorSets能绑定的描述符集数量上限通常 8 或 12/32。maxSamplerAnisotropy各向异性过滤最大倍数不查这个你就不知道设 16 是否越界。maxPushConstantsSize推常量最大字节数多数是 128。maxDrawIndexedIndexValue索引缓冲最大索引值。minUniformBufferOffsetAlignmentUBO 偏移对齐要求动态 UBO 绕不开它。获取方式VkPhysicalDeviceProperties props; vkGetPhysicalDeviceProperties(physicalDevice, props); printf(Device: %s (vendor 0x%04x, device 0x%04x)\n, props.deviceName, props.vendorID, props.deviceID); printf(Max 2D image dimension: %u\n, props.limits.maxImageDimension2D); printf(Max sampler anisotropy: %.2f\n, props.limits.maxSamplerAnisotropy);我个人强烈建议在项目启动阶段把整份 limits 打印到日志里开发时随时回看。你永远不该在代码里写死“纹理最大 8192”这类魔数用硬件上报的值才是对的。5. 格式查询判断表面格式与线性/最优tiling5.1 vkGetPhysicalDeviceFormatProperties最基础的格式支持判定显卡不是“所有格式都支持”的。比如VK_FORMAT_R8G8B8A8_UNORM和VK_FORMAT_R8G8B8A8_SRGB几乎人人都有但VK_FORMAT_R16G16B16A16_SFLOAT做渲染目标在某些移动 GPU 上就不行。查询函数VkFormatProperties fmtProps; vkGetPhysicalDeviceFormatProperties(physicalDevice, VK_FORMAT_R16G16B16A16_SFLOAT, fmtProps); bool asRenderTarget fmtProps.optimalTilingFeatures VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT; bool asStorageImage fmtProps.optimalTilingFeatures VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT;VkFormatProperties有三个字段linearTilingFeatures、optimalTilingFeatures、bufferFeatures。新手最常踩的坑就是不看 tiling 直接判断格式支持。同一张显卡、同一个格式linear线性内存布局和optimal优化瓦片布局支持的能力可能完全不同。比如某些老 Intel 驱动R8G8B8A8_UNORM的linearTilingFeatures只有VK_FORMAT_FEATURE_TRANSFER_SRC_BIT但optimalTilingFeatures什么都支持。你要拿它当渲染目标必须看optimalTilingFeatures那一位。另外别忘了VK_FORMAT_UNDEFINED这种“格式没有意义”的枚举查询它返回的属性全为零别拿来做逻辑判断。5.2 查询表面格式swapchain 色彩空间选择创建交换链之前必须查询窗口表面Surface支持的格式和色彩空间uint32_t formatCount 0; vkGetPhysicalDeviceSurfaceFormatsKHR(physicalDevice, surface, formatCount, nullptr); std::vectorVkSurfaceFormatKHR formats(formatCount); vkGetPhysicalDeviceSurfaceFormatsKHR(physicalDevice, surface, formatCount, formats.data()); for (const auto f : formats) { printf(Surface format: %d, colorSpace: %d\n, f.format, f.colorSpace); }VkSurfaceFormatKHR就是format colorSpace二元组。选择逻辑通常如下VkSurfaceFormatKHR pickSurfaceFormat(const std::vectorVkSurfaceFormatKHR formats) { for (const auto f : formats) { if (f.format VK_FORMAT_B8G8R8A8_SRGB f.colorSpace VK_COLOR_SPACE_SRGB_NONLINEAR_KHR) { return f; } } // 兜底第一个总是能用 return formats[0]; }为什么很多代码“无脑选 SRGB 非线性色彩空间”因为显示器几乎都按 sRGB 非线性输出线性渲染管线里做一次 sRGB 编码转换才能避免画面发灰。当然如果你做 HDR看到VK_COLOR_SPACE_HDR10_ST2084_EXT之类的枚举就得单说。这里有个很容易忽略的边界情况如果formats为空或者 physical device 根本不支持 surface这个查询会失败。所以创建 surface 之后先确认一下返回值别直接formats[0]。5.3 vkGetPhysicalDeviceImageFormatProperties精确到“图像配置”FormatProperties只回答“格式在某种 tiling 下能不能做某些事”但如果你要创建 VkImage还得确认更细节的参数maxExtent、maxMipLevels、maxArrayLayers、sampleCounts、maxResourceSize。这就要用vkGetPhysicalDeviceImageFormatPropertiesVkImageCreateInfo imageCI{}; imageCI.sType VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO; imageCI.imageType VK_IMAGE_TYPE_2D; imageCI.format VK_FORMAT_R8G8B8A8_UNORM; imageCI.extent { 1920, 1080, 1 }; imageCI.mipLevels 1; imageCI.arrayLayers 1; imageCI.samples VK_SAMPLE_COUNT_1_BIT; imageCI.tiling VK_IMAGE_TILING_OPTIMAL; imageCI.usage VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT | VK_IMAGE_USAGE_SAMPLED_BIT; VkImageFormatProperties imgFmtProps; VkResult res vkGetPhysicalDeviceImageFormatProperties( physicalDevice, imageCI, imgFmtProps); if (res VK_SUCCESS) { printf(Max extent: %ux%u, max mip: %u, max array: %u\n, imgFmtProps.maxExtent.width, imgFmtProps.maxExtent.height, imgFmtProps.maxMipLevels, imgFmtProps.maxArrayLayers); } else { // 这个设备不支持这种格式usagetiling 的组合 }这段代码最有价值的地方在于“MSAA 采样数”的确认。你想开 4x MSAA先查imgFmtProps.sampleCounts是否包含VK_SAMPLE_COUNT_4_BIT再创建多采样图像。很多人直接VK_SAMPLE_COUNT_4_BIT写死在高端 N 卡没问题但在某些移动 GPU 或老核显上附加上VK_SAMPLE_COUNT_2_BIT都没有创建图像直接失败。6. 实操一个完整的“查询启用”代码骨架6.1 整体流程把前面所有内容串起来一个完整的初始化前“查询启用”流程应该是这个顺序加载 Vulkan 函数指针建议直接用 volk省去手动vkGetInstanceProcAddr的样板代码。查询实例版本、图层、实例扩展。创建 VkInstance启用 surface、debug 等实例扩展。枚举物理设备选一个按deviceType偏好离散显卡再按特性丰富度兜底。查询物理设备属性、队列族、特性、扩展、格式信息。选择队列族决定设备扩展列表。创建 VkDevice启用设备扩展 设置特性。正常创建 swapchain 等资源。这个顺序不是我拍脑袋定的它遵循一个硬逻辑实例扩展要挂在实例创建之前查设备扩展要挂在设备创建之前查而设备扩展的可用清单取决于物理设备。顺序反了就必然报错。6.2 关键代码片段下面是一个我精简过的查询函数它输出了一台物理设备的“摘要报告”。实际项目中我会把每个查询拆成独立函数方便按需调用。void printDeviceInfo(VkPhysicalDevice device) { VkPhysicalDeviceProperties props; vkGetPhysicalDeviceProperties(device, props); printf( %s \n, props.deviceName); printf(apiVersion: %d.%d.%d, driverVersion: %u\n, VK_VERSION_MAJOR(props.apiVersion), VK_VERSION_MINOR(props.apiVersion), VK_VERSION_PATCH(props.apiVersion), props.driverVersion); printf(vendorID: 0x%04x, deviceID: 0x%04x, type: %d\n, props.vendorID, props.deviceID, props.deviceType); VkPhysicalDeviceFeatures features; vkGetPhysicalDeviceFeatures(device, features); printf(samplerAnisotropy: %s\n, features.samplerAnisotropy ? Y : N); printf(geometryShader: %s\n, features.geometryShader ? Y : N); // 扩展 uint32_t extCount 0; vkEnumerateDeviceExtensionProperties(device, nullptr, extCount, nullptr); std::vectorVkExtensionProperties exts(extCount); vkEnumerateDeviceExtensionProperties(device, nullptr, extCount, exts.data()); printf(device extensions: %u\n, extCount); for (const auto e : exts) { printf( %s\n, e.extensionName); } // 格式 VkFormatProperties fmtProps; vkGetPhysicalDeviceFormatProperties( device, VK_FORMAT_R8G8B8A8_UNORM, fmtProps); printf(R8G8B8A8_UNORM as color attachment (optimal): %s\n, (fmtProps.optimalTilingFeatures VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT) ? Y : N); // 队列族 uint32_t qCount 0; vkGetPhysicalDeviceQueueFamilyProperties(device, qCount, nullptr); std::vectorVkQueueFamilyProperties queues(qCount); vkGetPhysicalDeviceQueueFamilyProperties(device, qCount, queues.data()); printf(queue families: %u\n, qCount); }所谓“骨架”就是你把它拷进工程填上错误处理、设备选择逻辑就能跑。6.3 验证结果输出示例在一台 NVIDIA GeForce RTX 3080 的机器上输出大致是 NVIDIA GeForce RTX 3080 apiVersion: 1.3.239, driverVersion: ... vendorID: 0x10de, deviceID: 0x2206, type: 2 samplerAnisotropy: Y geometryShader: Y device extensions: 120 VK_KHR_swapchain VK_KHR_maintenance1 ... R8G8B8A8_UNORM as color attachment (optimal): Y queue families: 4注意apiVersion是 1.3但VK_KHR_swapchain依然在扩展列表里。这再次验证我前面说的这个扩展一直被保留在“扩展”层面。如果启用了 extension 但驱动不认vkCreateDevice会返回VK_ERROR_EXTENSION_NOT_PRESENT。排查办法很直接把你启用的扩展名和vkEnumerateDeviceExtensionProperties的结果比对一遍看名字拼写、后缀、是否带了版本号。一个经典错误是启用VK_KHR_SWAPCHAIN_EXTENSION_NAME时拼错成VK_KHR_SWAPCHAIN宏展开出来的字符串少一截。7. 避坑实录我踩过的那些查询坑7.1 常见问题速查表症状根因解决vkCreateDevice返回VK_ERROR_EXTENSION_NOT_PRESENT启用了设备不支持的扩展先枚举再比对检查拼写和版本后缀Validation layer 报 “VUID-VkDeviceCreateInfo-pEnabledFeatures-xxxxx”启用了设备不支持的特性先vkGetPhysicalDeviceFeatures查询再决定开不开创建交换链时返回VK_ERROR_NATIVE_WINDOW_IN_USE_KHR或 surface 相关错误实例扩展里漏了VK_KHR_surface/平台 surface 扩展实例创建前就把平台 surface 扩展加上纹理创建失败报 format 不支持直接用了VK_FORMAT_*_SRGB当存储图像查VkFormatProperties确认STORAGE_IMAGE_BITMSAA 图像创建失败直接用VK_SAMPLE_COUNT_4_BIT没查sampleCounts用vkGetPhysicalDeviceImageFormatProperties确认程序在不同显卡上表现不一致魔数硬编码了 limit用VkPhysicalDeviceLimits查询值替代vkEnumerateInstanceVersion崩溃在 Vulkan 1.0 loader 上直接调用了这个函数先vkGetInstanceProcAddr探测再调用验证层加载不上只启用了VK_EXT_debug_utils但没启用验证图层vkEnumerateInstanceLayerProperties确认后在实例创建时加入VK_LAYER_KHRONOS_validation7.2 实用排查技巧第一个技巧写一个查询一切的小工具函数把整个系统体检报告打印出来。我在自己的引擎里留了一个vk_dump.cpp把上面的printDeviceInfo、扩展列表、特性、limits、格式关键项全部输出到控制台和日志文件。遇到“为什么这台机器上效果不对”的问题第一件事就是跑这个函数看设备能力差异。这个习惯帮我解决过至少五次“看起来是 bug 其实是设备能力不足”的疑难杂症。第二个技巧把 validation layer 当作开发期默认选项。Vulkan 的 validation layer 不只是查越界访问它还会查我刚才说的所有“创建信息不匹配”问题你在pEnabledFeatures里开了硬件不支持的特性它直接给你VUID编号 说明。开着它开发等于让 Khronos 帮你在初始化阶段把关。第三个技巧用 volk 管理函数指针。手动加载vkGetDeviceProcAddr、vkGetInstanceProcAddr再挨个查函数指针的代码又臭又长而且版本一升级就要加新函数。volk 是社区标准方案初始化两行代码后面所有vk*函数全自动搞定。我一开始手写过一遍加载器后来果断换掉。第四个技巧不要把“查询”当作一次性操作。很多人查完设备属性就再也不会调用了但 Vulkan 规范没假设物理设备能力在程序运行期间不变化虽然实际很少变。稳妥的做法是在重新创建设备、切换显卡、热插拔事件处理时重新走一遍查询流程。大多数项目用不到但写多适配器代码时把查询封装成模块而不是散落在 main 函数里会让你后期少掉头发。最后一个经验Vulkan 的“查询-启用”模式看起来繁琐但它的价值恰恰在于所有能力边界都是显式的。你不会像 OpenGL 那样调一个扩展函数还需要在驱动层暗中猜测支持情况也不会因为某个特性在某台机器上不可用而崩溃——前提是你老老实实走了查询流程。我当时第一次在四台不同显卡上跑通同一套查询代码时就有种“一切尽在掌握”的踏实感。这也是这个 API 值得被认真对待的地方把硬件的底牌摊在桌面上然后由你自己决定怎么出牌。