vulkan

问题 In OpenGL you can linearize a depth value like so: float linearize_depth(float d,float zNear,float zFar) { float z_n = 2.0 * d - 1.0; return 2.0 * zNear * zFar / (zFar + zNear - z_n * (zFar - zNear)); } (Source: https://stackoverflow.com/a/6657284/10011415) However, Vulkan handles depth values somewhat differently (https://matthewwellings.com/blog/the-new-vulkan-coordinate-system/). I don't quite understand the math behind it, what changes would I have to make to the function to linearize a

问题 I'm reading Vulkan Memory Allocation - Memory Host and seems that VkAllocationCallbacks can be implemented using naive malloc/realloc/free functions. typedef struct VkAllocationCallbacks { void* pUserData; PFN_vkAllocationFunction pfnAllocation; PFN_vkReallocationFunction pfnReallocation; PFN_vkFreeFunction pfnFree; PFN_vkInternalAllocationNotification pfnInternalAllocation; PFN_vkInternalFreeNotification pfnInternalFree; } VkAllocationCallbacks; But I see only two possible reasons to

问题 There are several ways to handle synchronization in Vulkan. This is how I understand it: Fences are GPU to CPU syncs. Semaphores are GPU to GPU syncs, they are used to sync queue submissions (on the same or different queues). Events are more general, reset and checked on both CPU and GPU. Barriers are used for synchronization inside a command buffer. In my case I have two command buffers. And I want the second command buffer to execute after the first one. submitInfo.pCommandBuffers =

问题 I'm trying to figure it out, but I'm getting a little stuck. The way the types and heaps are related is simple, if a bit strange. (why not just give VkMemoryHeap a VkMemoryType member?) I think I understand what all the VkMemoryPropertyFlags mean, they seem fairly straightforward. But what's with the VkMemoryHeap.flags member? It apparently only has one non-zero valid value, VkMemoryHeapFlagBits.VK_MEMORY_HEAP_DEVICE_LOCAL_BIT , and though that wouldn't be too odd on it's own, but there's

问题 On my machine I have two queue families, one that supports everything and one that only supports transfer. The queue family that supports everything has a queueCount of 16 . Now the spec states Command buffers submitted to different queues may execute in parallel or even out of order with respect to one another Does that mean I should try to use all available queues for maximal performance? 回答1: Yes, if you have workload that is highly independent use separate queues. If the queues need a lot

问题 I had some experience with DirectX12 in the past and I don't remember something similar to render passes in Vulkan so I can't make an analogy. If I'm understanding correctly command buffers inside the same subpass doesn't need to be synchronized. So why to complicate and make multiple of them? Why can't I just take one command buffer and put all my frame related info there? 回答1: Imagine that the GPU cannot render to images directly. Imagine that it can only render to special framebuffer

问题 In all of the create info structs ( vk*CreateInfo ) in the new Vulkan API, there is ALWAYS a .sType member. Why is this there if the value can only be one thing? Also the Vulkan specification is very explicit that you can only use vk*CreateInfo structs as parameters for their corresponding vkCreate* function. It seems a little redundant. I can see that if the driver was passing this struct straight to the GPU, you might need to have it (I did notice it is always the first member). But this

问题 The vulkan docs mention that moving image layouts in render passes (see VkAttachmentDescription structure) is preferred compared to moving them using barriers (i.e. vkCmdPipelineBarrier ). I can understand that since the latter introduce sync points which constrain parallel execution. Now consider a typical example: A transition from VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL to VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL . In this case the resource is going to be read in the shader, but in order

问题 I'm currently adapting my personal engine to Vulkan and I want to reimplement transparent windows, which I already had with OpenGL. I thought that all I need to do is to select the correct color format ( with alpha channel ) and to set the compositeAlpha property of VkSwapchainCreateInfoKHR to VK_COMPOSITE_ALPHA_POST_MULTIPLIED_BIT_KHR . However clearing the window with a full transparent color doesn't provide the expected results. It's fully opaque. Of course my window system, which didn't

问题 I am trying to setup a bare bones program to use Vulkan. I installed the LunarG SDK. I have a tiny program that basically just calls vkCreateInstance . I compiled with this line: g++ -std=c++11 -I/c/VulkanSDK/1.0.3.1/Include -L/c/VulkanSDK/1.0.3.1/Bin main.cpp -lvulkan-1 I get this compiler error using 64-bit mingw (MSYS2): relocation truncated to fit||R_X86_64_32 against symbol `__imp_vkCreateInstance' defined in .idata$5 section in C:\VulkanSDK\1.0.3.1\Bin/vulkan-1.lib(vulkan-1.dll.b)| What