vulkan

问题 In Vulkan, A semaphore( A ) and a fence( X ) can be passed to vkAcquireNextImageKHR . That semaphore( A ) is subsequently passed to vkQueueSubmit , to wait until the image is released by the Presentation Engine (PE). A fence( Y ) can also be passed to vkQueueSubmit . Client code can check when the submission has completed by checking fence( Y ). When fence( Y ) signals, this means the PE can display the image. My question: How do I know when the PE has finished using the image after a call to

问题 From what I understand there are several methods for storing and transferring vertex data to the GPU. Using a temporary staging buffer and copying it to discrete GPU memory every frame Using shared buffer (which is slow?) and just update the shared buffer every frame Storing the staging buffer for each mesh permanently instead of recreating it every frame and copying it to the GPU Which method is best for storing animating mesh data which changes rapidly? 回答1: It depends on the hardware and

问题 As shown at https://vulkan-tutorial.com/code/23_texture_image.cpp: Calling createGraphicsPipeline() to recreate the Pipeline when changing the window size, the dimensions are set in the code below. VkViewport viewport = {}; viewport.x = 0.0f; viewport.y = 0.0f; viewport.width = (float) swapChainExtent.width; viewport.height = (float) swapChainExtent.height; viewport.minDepth = 0.0f; viewport.maxDepth = 1.0f; VkRect2D scissor = {}; scissor.offset = {0, 0}; scissor.extent = swapChainExtent;

问题 I am writing a game for Android using the NDK. My game uses vulkan if it is available and otherwise uses OpenGL. I have a problem where if you put the game in split screen mode with the device held in portrait orientation, then resize the game to full screen mode, an after image of the game on the old view is still visible. Note: doing this with the game triggers SurfaceHolder.Callback.surfaceDestroyed (in Java) to be called, which in turn shuts down my render thread in C++. My callback for

问题 I have an application with a single VkInstance . Also I have the same physical device index, but different VkPhysicalDevice objects and hence different VkDevice objects. What would be the easiest and the most correct way to share VkBuffer or VkImage with multiple logical devices? 回答1: I didn't do it, but maybe try using the VK_KHR_external_memory extension. It allows You to export non-Vulkan handles from Vulkan memory objects and provide such external memory during buffer or image creation.

问题 I'm currently moving my game to Vulkan. In my game, I have multiple worker threads to generate drawcalls. Each worker thread has its own command buffer. As render pass begin/end pair need to be within command buffer begin/end pair, so I would think render passes need to be thread local. Is that correct? If that's the case, my second question is that how can I share pipeline objects among worker threads? I currently maintain a global pipeline object map, for each drawcall, worker threads

问题 Some of the vkCmd* functions specify when some parameters are consumed or not. For example, in the documentation of vkCmdBindDescriptorSets : The contents of pDynamicOffsets are consumed immediately during execution of vkCmdBindDescriptorSets. However most of them do not clarify. Are all parameters consumed during the the vkCmd* call? For example, in the following code: void copyHelper() { VkBufferCopy copy_region = {...}; vkCmdCopyBuffer(cmd_buffer, from_buffer, to_buffer, 1, &copy_region);

问题 Is it possible to render to OpenGL from Vulkan? It seems nVidia has something: https://lunarg.com/faqs/mix-opengl-vulkan-rendering/ Can it be done for other GPU's? 回答1: NVIDIA has created an OpenGL extension, NV_draw_vulkan_image, which can render a VkImage in OpenGL. It even has some mechanisms for interacting with Vulkan semaphores and the like. However, according to the documentation, you must bypass all Vulkan layers, since layers can modify non-dispatchable handles and the OpenGL

问题 Looking into the vulkan.h i see this: #if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || ..... #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T *object; #else #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object; #endif Does anyone has an idea why the 64bits? For me it appears more reasonable to always use the first case of the ifdef 回答1: In the spec it explicitly says that the non-dispatchable handles must be 64 bits: Non

问题 Quoting Vulkan 1.0 specification document, chapter.5(Command Buffers) 4th paragraph, "Unless otherwise specified, and without explicit synchronization, the various commands submitted to a queue via command buffers may execute in arbitrary order relative to each other, and/or concurrently" In 1st paragraph of chapter 2.1.1(Queue Operation), it also states "... Command buffers submitted to a single queue are played back in the order they were submitted, and commands within each buffer are