krooze / hello_triangle Goto Github PK

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 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])

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.

Would love to try running this on linux. My goal is to translate the example into ocaml, using https://github.com/Octachron/olivine.

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

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,

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!

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 👽

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

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 ?

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.

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 have no way to test MacOS support. But theoretically GLFW should be able to handle it. I would be grateful if someone tests it.