krooze / hello_triangle Goto Github PK
View Code? Open in Web Editor NEWHello World like demo for Vulkan API
Home Page: http://vulkan.hys.cz/
License: The Unlicense
Hello World like demo for Vulkan API
Home Page: http://vulkan.hys.cz/
License: The Unlicense
Hi @krOoze. I'm referring to your code for my vulkan engine.
Always Thank you for your good resource.
I assume that Your tutorial code is using triple buffering.
I have questions for these lines
Hello_Triangle/src/HelloTriangle.cpp
Lines 365 to 370 in 3a579d1
I want to know why more than 2 does not make sense. Because, When you have 3 swapchain images, I think you can submit 3 images, which is achieved by vkQueueSubmit()
limited by 3 fences respectively.
So, I think we should always create the same number of sync objects as the number of the swapchain images.
In addition, when you create sync object,
Hello_Triangle/src/HelloTriangle.cpp
Lines 453 to 457 in 3a579d1
You just created only one renderDoneSemaphore
for sync object.
And this makes me confused with the triple buffering system with Vulkan.
Because when you try to submit one image, You will construct one set of sync objects, command buffers. So, I think you have to use another semaphore when you try to submit the next image.
Specifically, I mean that when you do vkQueueSubmit
, you are submitting a combination of command buffers and sync objects to the GPU queue. So, I think the driver and the GPU will use the set of command buffers and sync objects to process rendering process and synchronization.
That's the reason why I think We should have the same number of renderingDone
semaphore as the swapchain image count.
I pushed my version on my fork. You can view the changes.
ChanLee1123@a60f966
Thanks in advance!
I think a return
statement should go here. The compiler throws a warning about unused expression (src/VulkanIntrospection.h:40:49: warning: statement has no effect [-Wunused-value])
Hello_Triangle/src/VulkanIntrospection.h
Line 40 in a8844e9
Would you mind creating a c branch? When looking at the cpp file I am not sure if its trivial to translate the c++ code into c ?
Would love to try running this on linux. My goal is to translate the example into ocaml, using https://github.com/Octachron/olivine.
Hello.
When I ran this example on my ryzen 2200g video chip with validation layers enabled, I have the following warning, raised from initMemory
function:
VALIDATION+ERROR: [Device(0x1E7AB642BC0)]: VUID-vkAllocateMemory-deviceCoherentMemory-02790(-2010063723), "Validation Error: [ VUID-vkAllocateMemory-deviceCoherentMemory-02790 ] Object
0: handle = 0x1e7ab642bc0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x8830dc95 | vkAllocateMemory: attempting to allocate memory type 6, which includes the VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD memory property, but the deviceCoherentMemory feature is not enabled. The Vulkan spec states: If the deviceCoherentMemory feature is not enabled, pAllocateInfo->memoryTypeIndex must not identify a memory type supporting VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD. (https://vulkan.lunarg.com/doc/view/1.2.176.1/windows/1.2-extensions/vkspec.html#VUID-vkAllocateMemory-deviceCoherentMemory-02790)"
idk why this happens with VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT
instead of VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD
, but probably the VK_AMD_device_coherent_memory device extension must be enabled on AMD devices.
Seems this documentation is related: https://gpuopen-librariesandsdks.github.io/VulkanMemoryAllocator/html/vk_amd_device_coherent_memory.html
What environment variables do I set to build on Ubuntu?
$ cmake .
WSI: USE_PLATFORM_GLFW
Vulkan SDK path: /home/pem/vulkan/1.3.216.0
-- Using X11 for window creation
Vulkan include dir: VULKAN_INCLUDE-NOTFOUND
Vulkan libs: VULKAN_LIBRARY-NOTFOUND
-- Configuring done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
VULKAN_INCLUDE
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
used as include directory in directory /home/pem/pemcode/Hello_Triangle
VULKAN_LIBRARY
linked by target "HelloTriangle" in directory /home/pem/pemcode/Hello_Triangle
CMake Error in CMakeLists.txt:
Found relative path while evaluating include directories of
"HelloTriangle":
"VULKAN_INCLUDE-NOTFOUND"
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
This is a follow-up question to KhronosGroup/Vulkan-Docs#366 (comment)
I decided to start from scratch. My new effort will be to UWP/DX12 on the Windows based platforms and Vulkan for non-Mac platforms, eventually Metal on Mac. I'll forgo SDL2 or any other libraries and do everything natively. In that context I want to forgo doing a Win32 application. Is DXGI feasible enough to share the DX12 code with a Vulkan renderer even if it is just for development purposes to save time on redoing the same stuff with a different API? DXGI should be enough to enumerate monitors, screens, setup windows etc. I guess.
Windows/MSVC is my primary development platform and the targets are UWP/Xbox, Android, Apple.
I faced the problem of fpsCounter
which relates directly to VK_LAYER_LUNARG_monitor
didn't show FPS counter on window's title on Ubuntu 19.10.
It happened to me in another glfw-based application as well. But vkcube
as bundled from SDK works fine and able to show FPS counter.
Any ideas of what problem might be?
I compiled HelloTriangle succesfully, but when trying to run it I get
ERROR: Terminated due to an uncaught exception: VULKAN_VALIDATION is enabled but VK_LAYER_KHRONOS_validation layers are not supported!
Does this mean my version of Vulkan is wrong? I use SDK 1.2.148.1.
In your frame synchronization model you wait for the submission fence, i.e. for the rendering to be complete, but not for the presentation to be complete. I mean you could wait for the acquire fence (the fence which is signaled by vkAcquireNextImageKHR) of the next oldest frame to know that the oldest frame which you reuse is completed the presentation.
Is there any explicit reason of your choice? I'm trying to evaluate the pros/cons of the two approaches.
Also, rather a mention than a critique, since this model is a perfect fit for a simple app like hello HelloTriangle, it scales to real-world applications in a way that if you issue multiple vkQueueSubmit
per frame, then you have to wait the fences of all vkQueueSubmit
issued on that frame - one would think that waiting the fence of the last vkQueueSubmit
results in proper synchronization, but if there are no dependencies between the last and previous submissions, then the last submission can complete out of order, before the previous submissions, which would lead to insufficient synchronization.
In the meantime I realized that according to the spec:
When a fence is submitted to a queue as part of a queue submission command, it defines a memory dependency on the batches that were submitted as part of that command, and defines a fence signal operation which sets the fence to the signaled state.
The first synchronization scope includes every batch submitted in the same queue submission command. Fence signal operations that are defined by vkQueueSubmit additionally include in the first synchronization scope all commands that occur earlier in submission order. Fence signal operations that are defined by vkQueueSubmit or vkQueueBindSparse additionally include in the first synchronization scope any semaphore and fence signal operations that occur earlier in signal operation order.
The second synchronization scope only includes the fence signal operation.
Which, as I read, means that it is sufficient to wait the fence of the last vkQueueSubmit
per frame, since even if the submitted commands complete out of order, the fence signal operations of the submissions complete in order.
I also realized that your choice of sync model wait-on-submit is superior to wait-on-acquire-next, since it never waits for the presentation engine to release an image (B) to start building a new frame, instead it waits only the GPU to complete a frame (A), which spares the time between A and B, leading to better CPU/GPU utilization.
So I think I just answered my own questions ๐ฝ
I have no way to test MacOS support. But theoretically GLFW should be able to handle it. I would be grateful if someone tests it.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.