liblava / liblava Goto Github PK
View Code? Open in Web Editor NEWModern and easy-to-use library for Vulkan
Home Page: https://liblava.dev
License: MIT License
Modern and easy-to-use library for Vulkan
Home Page: https://liblava.dev
License: MIT License
I'm using load_texture
to load a .dds file with mipmaps but I'm getting the following validation error:
vkCreateImage(): Image mip levels=11 exceed image format maxMipLevels=1 for format VK_FORMAT_R8G8B8A8_UNORM. The Vulkan spec states: mipLevels must be less than or equal to imageCreateMaxMipLevels (as defined in Image Creation Limits). (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageCreateInfo-mipLevels-02255)
It seems like VK_IMAGE_TILING_LINEAR
doesn't support mipmaps on all hardware (at least not on my Nvidia GTX 1070). texture::stage
seems to correctly transfer mipmaps from the scratch buffer, so I'm not sure why linear tiling is even necessary.
Commenting out the code that sets linear tiling removes the validation error, but I just wanted some feedback if that's valid, or why it's enabled by default.
From what I understand, FBX is currently the favored format for storing 3D data in video games. Compared to OBJ, it contains much more information about materials and animations. Liblava providing the data structures needed for reasoning about this data could make it very productive for building games / simulations. I'm currently using Liblava for building an FBX loader as a school assignment, and when it's finished I may be able to apply that knowledge for implementing into Liblava a more robust FBX loader like OpenFBX (or some alternative) similar to how TinyOBJ is implemented currently.
Do you think this feature is desirable?
What is the best way to do this? My plan is to render everything to an offscreen framebuffer (deferred shading + possibly tonemapping) and then just perform a final blit to the render target before the gui pipeline.
I could call block.add_cmd()
before app.setup()
but that creates a new command buffer. Would that be a problem, performance wise? And can I still insert barriers properly even if they cross command buffers? Bit of a Vulkan newbie so I could use some input π
Hi,
I was thinking to use your project for a 32bit binary which will make use of Vulkan technology. Although trying to build your binary for 32bit platforms on Windows give some errors.
Looking at compile errors that do not look like huge issues to be fixed. Would you be so kind in investing some time in fixing those? Below you can find my build output as comparison.
As a side note, on the same workstation, building for X64 target works fine. So the issue happens only on Win32 platforms.
Thank you in advance,
Julian
$ cmake -G "Visual Studio 16 2019" -A Win32 -DCMAKE_MSVC_RUNTIME_LIBRARY="MultiThreadedDebug" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_PREFIX_PATH="install" -DCMAKE_INSTALL_PREFIX="install" --config Debug ..
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.24.28314.0
-- The CXX compiler identification is MSVC 19.24.28314.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x86/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x86/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x86/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
========================================================================
Copyright (c) 2018-present, Lava Block OΓ MIT licensed
========================================================================
_| _| _| _|
_| _|_|_| _| _|_|_| _| _| _|_|_|
_| _| _| _| _| _| _| _| _| _| _|
_| _| _| _| _| _| _| _| _| _| _|
_| _| _|_|_| _| _|_|_| _| _|_|_|
========================================================================
2020 preview v0.4.5
========================================================================
https://git.io/liblava lava-block.com
========================================================================
> module
>> lava::core
>> lava::util
>>> physfs
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Doxygen not found. You won't be able to build documentation.
-- PhysicsFS will build with the following options:
-- ZIP support: enabled
-- 7zip support: disabled
-- GRP support: disabled
-- WAD support: disabled
-- HOG support: disabled
-- MVL support: disabled
-- QPAK support: disabled
-- SLB support: disabled
-- VDF support: disabled
-- ISO9660 support: disabled
-- Build static library: enabled
-- Build shared library: disabled
-- Build stdio test program: disabled
<<< physfs
>> lava::base
>> lava::resource
>>> selene
-- Building WITHOUT libjpeg support (*** NOT FOUND ***).
-- Building WITHOUT libpng support (*** NOT FOUND ***).
-- Building WITHOUT libtiff support (*** NOT FOUND ***).
-- Building WITHOUT OpenCV support (*** NOT FOUND ***).
-- Not building unit tests; enable with SELENE_BUILD_TESTS=ON if desired.
-- Not building examples; enable with SELENE_BUILD_EXAMPLES=ON if desired.
-- Not building benchmarks; enable with SELENE_BUILD_BENCHMARKS=ON if desired.
<<< selene
>> lava::frame
>>> glfw
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Using Win32 for window creation
<<< glfw
>> lava::block
>> lava::app
> tests
========================================================================
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Julian/source/repos/liblava/liblava/.build
$ cmake --build . --config Debug --target install
Checking Build System
Building Custom Rule C:/Users/Julian/source/repos/liblava/liblava/ext/glfw/src/CMakeLists.txt
context.c
init.c
input.c
monitor.c
vulkan.c
window.c
win32_init.c
win32_joystick.c
win32_monitor.c
win32_time.c
win32_thread.c
win32_window.c
wgl_context.c
egl_context.c
osmesa_context.c
Generazione del codice in corso...
glfw.vcxproj -> C:\Users\Julian\source\repos\liblava\liblava\.build\glfw\src\Debug\glfw3.lib
Building Custom Rule C:/Users/Julian/source/repos/liblava/liblava/ext/physfs/CMakeLists.txt
physfs.c
physfs_byteorder.c
physfs_unicode.c
physfs_platform_posix.c
physfs_platform_unix.c
physfs_platform_windows.c
physfs_platform_os2.c
physfs_platform_qnx.c
physfs_archiver_dir.c
physfs_archiver_unpacked.c
physfs_archiver_grp.c
physfs_archiver_hog.c
physfs_archiver_7z.c
physfs_archiver_mvl.c
physfs_archiver_qpak.c
physfs_archiver_wad.c
physfs_archiver_zip.c
physfs_archiver_slb.c
physfs_archiver_iso9660.c
physfs_archiver_vdf.c
Generazione del codice in corso...
physfs-static.vcxproj -> C:\Users\Julian\source\repos\liblava\liblava\.build\physfs\Debug\physfs-static.lib
Building Custom Rule C:/Users/Julian/source/repos/liblava/liblava/CMakeLists.txt
file.cpp
lava.util.vcxproj -> C:\Users\Julian\source\repos\liblava\liblava\.build\Debug\lava.util.lib
Building Custom Rule C:/Users/Julian/source/repos/liblava/liblava/CMakeLists.txt
base.cpp
device.cpp
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,47): error C2440: 'inizializzazione': impossibile convertire da 'nullptr' a 'VkDescriptorPool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxpr
oj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,40): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\li
blava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,47): error C2439: 'lava::device::descriptor_pool': impossibile inizializzare il membro [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110): message : vedere la dichiarazione di 'lava::device::descriptor_pool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67,55): error C2440: 'inizializzazione': impossibile convertire da 'nullptr' a 'VkDebugUtilsMessengerEXT' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.b
ase.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67,48): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\l
iblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67,55): error C2439: 'lava::instance::debug_messanger': impossibile inizializzare il membro [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67): message : vedere la dichiarazione di 'lava::instance::debug_messanger' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\device.cpp(96,30): error C2440: '=': impossibile convertire da 'nullptr' a 'VkDescriptorPool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\device.cpp(96,23): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\lib
lava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\device.cpp(209,23): error C2440: 'return': impossibile convertire da 'nullptr' a 'VkShaderModule' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\device.cpp(209,16): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\li
blava\.build\lava.base.vcxproj]
instance.cpp
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,47): error C2440: 'inizializzazione': impossibile convertire da 'nullptr' a 'VkDescriptorPool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxpr
oj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,40): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\li
blava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,47): error C2439: 'lava::device::descriptor_pool': impossibile inizializzare il membro [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110): message : vedere la dichiarazione di 'lava::device::descriptor_pool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67,55): error C2440: 'inizializzazione': impossibile convertire da 'nullptr' a 'VkDebugUtilsMessengerEXT' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.b
ase.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67,48): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\l
iblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67,55): error C2439: 'lava::instance::debug_messanger': impossibile inizializzare il membro [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/instance.hpp(67): message : vedere la dichiarazione di 'lava::instance::debug_messanger' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\instance.cpp(179,30): error C2440: '=': impossibile convertire da 'nullptr' a 'VkDebugUtilsMessengerEXT' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\instance.cpp(179,23): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\
liblava\.build\lava.base.vcxproj]
memory.cpp
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\memory.cpp(58,56): error C2440: '=': impossibile convertire da 'void *(__cdecl *)(void *,lava::size_t,lava::size_t,VkSystemAllocationScope)' a 'PFN_vkAllocationFunction' [C:\User
s\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\memory.cpp(58,34): message : La conversione richiede reinterpret_cast, un cast di tipo C o un cast di tipo funzione [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base
.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\memory.cpp(59,60): error C2440: '=': impossibile convertire da 'void *(__cdecl *)(void *,void *,lava::size_t,lava::size_t,VkSystemAllocationScope)' a 'PFN_vkReallocationFunction'
[C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\memory.cpp(59,36): message : La conversione richiede reinterpret_cast, un cast di tipo C o un cast di tipo funzione [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base
.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\memory.cpp(60,44): error C2440: '=': impossibile convertire da 'void (__cdecl *)(void *,void *)' a 'PFN_vkFreeFunction' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.
base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava\base\memory.cpp(60,28): message : La conversione richiede reinterpret_cast, un cast di tipo C o un cast di tipo funzione [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base
.vcxproj]
physical_device.cpp
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,47): error C2440: 'inizializzazione': impossibile convertire da 'nullptr' a 'VkDescriptorPool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxpr
oj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,40): message : Un nullptr nativo puΓ² solo essere convertito in bool oppure, tramite reinterpret_cast, in un tipo integrale [C:\Users\Julian\source\repos\liblava\li
blava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110,47): error C2439: 'lava::device::descriptor_pool': impossibile inizializzare il membro [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
C:\Users\Julian\source\repos\liblava\liblava\liblava/base/device.hpp(110): message : vedere la dichiarazione di 'lava::device::descriptor_pool' [C:\Users\Julian\source\repos\liblava\liblava\.build\lava.base.vcxproj]
Generazione del codice in corso...
Hey,
Is there a quick way to render a scene without an actual window? Let's say on servers without an physical display attached?
There's no internal or API / usage documentation whatsoever. This hinders people using the library or contributing.
Ideally I'd use doxygen / Javadoc style comments for auto-generating documentation:
/// @brief Describe your class or function here.
/*
* \brief This works the same.
*/
I prefer the first version as it clutters up files less.
I also would enforce formatting using clang-format. It integrates nicely with VS-Code. Put a .clang-format file into the root of the project and enable format on save in VS Code. You can then adjust the .clang-format file to your needs and format code as you edit or let the CI check or format code for you as you commit.
Support for sRGB textures and swapchain would be nice to have. sRGB texture formats will perform the conversion to and from linear RGB in hardware. This is important for loading color images (this excludes normal maps, etc.) which are almost always stored as sRGB, as well as applying the correct gamma transformation for display output. You can do it manually, but that's slow, error prone and enforces bad habits.
Currently, three things are blocking this:
_SRGB
formats, but _UNORM
load_texture
doesn't support _SRGB
formats, even though all 4 formats (RGBA, BC, ASTC, ETC2) have SRGB versions. not sure why they're not supported, maybe there's a good reason I'm not aware of.Would appreciate some input π Maybe there's a reason you went without sRGB, or you think it's a non-issue.
Greetings all,
I am encountering an assert present within liblava that is not evident in a 'clean' clone from the ocornut github repo.
The assert: imgui_draw.cpp:2111: bool ImFontAtlasBuildWithStbTruetype(ImFontAtlas*): Assertion `font_offset >= 0 && "FontData is incorrect, or FontNo cannot be found."' failed.
I've tried two approaches here.
within the liblava local clone I have run the git submodule command for IMGUI to ensure that I am on branch "master" and on a tag greater than v1.72b
within the ext/ directory I removed the imgui/ directory and did a full clone into the location.
On both counts the assert is raised. I have tested a separate imgui/ clone and attempt to force the assert to show up consistent with how liblava uses imgui/ but it does not.
Please advise if there is anything else you all might recommend at this stage.
just for info
Linux x11 has this validation error, even resize implementation in Khronos Vulkan-Samples has it.
(I have no idea how to fix it)
liblava does not crash, everything works just this error
VUID-VkSwapchainCreateInfoKHR-imageExtent-01274(ERROR / SPEC): msgNum: 2094043421 - Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x24a1ba8, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (828,612), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (827,611), minImageExtent = (827,611), maxImageExtent = (827,611). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.170.0/linux/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
Objects: 1
[0] 0x24a1ba8, type: 3, name: NULL
I was trying to make shader edits for the 'spawn' demo but even if I changed the frag shader in both locations I found it, it didn't seem to change how the program ran. Does it get cached out somewhere or what do I need to do? I tried re-building but I don't think that worked either.
@TheLavaBlock replied in a different thread:
Unfortunately, the producer does not currently recognize that a shader has changed. At the first start a cache is created and then always loaded. In the future it would definitely be better to automatically check and regenerate the cache when the program starts if there are changes. You can clean the cache on app start by using Command-Line Arguments: --clean_cache or -cc for short.
It was suggested to start a fresh 'Issue' for this.
For my own needs the above suggestion is perfectly workable.
When trying to take a screenshot I receive the following validation error:
[2023-02-15 20:12:12.381] [lava] [error] validation: VUID-vkMapMemory-memory-00682 (-330527817)
[2023-02-15 20:12:12.382] [lava] [error] Validation Error: [ VUID-vkMapMemory-memory-00682 ] Object 0: handle = 0x535b66
0000000043, type = VK_OBJECT_TYPE_DEVICE_MEMORY; | MessageID = 0xec4c8bb7 | Mapping Memory without VK_MEMORY_PROPERTY_HO
ST_VISIBLE_BIT set: VkDeviceMemory 0x535b660000000043[]. The Vulkan spec states: memory must have been created with a me
mory type that reports VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT (https://vulkan.lunarg.com/doc/view/1.3.231.1/windows/1.3-ext
ensions/vkspec.html#VUID-vkMapMemory-memory-00682)
Assertion failed: !"check validation error", file C:\Users\daniel\CLionProjects\fluid_bending\ext\liblava_fork\liblava\b
ase\instance.cpp, line 36
The issue seams to be that VMA_MEMORY_USAGE_AUTO_PREFER_HOST
doesn't guarantee that the memory is host visible,
so mapping it fails.
Changing it to VMA_MEMORY_USAGE_CPU_TO_GPU
would fix it, but it is deprecated.
To properly solve this issue : VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT would be required in the allocation flags.
To implement this the create method of image would require a new parameter to set the allocation flag.
Here I see a general problem with liblava's create methods. They are a nice abstraction to create complex objects like buffers, meshes and images, but they severely limit how they can be created.
Examples:
I see no clear way to fix this problem, but some options are:
The last two would be the best options in my opinion.
Maybe this should be discussed in a separate issue.
Any chances this can be packaged to Conan?
It's a handy-dandy tool to manage c++ libraries https://conan.io/.
I have an Nvidia eGPU but Intel integrated GPU is listed as the first physical device. Since X is running on the eGPU, when I try to start a demo application I get the following warning:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 149 ()
Minor opcode of failed request: 4
Resource id in failed request: 0x360000b
Serial number of failed request: 168
Current serial number in output stream: 178
If I go inside liblava/base/instance.hpp
line #64 and change physical_devices.front()
to physical_devices.back()
everything works as expected. But of course this is not a valid solution :)
I am trying to render a list of vertices as points. So I have changed input_assembly_state.topology = VK_PRIMITIVE_TOPOLOGY_POINT_LIST
To do so, I just made everything in the pipeline public. What would be the desired way to acomplish this?
I tried liblava on rpi4 (4GB / Raspberry Pi OS) with latest Vulkan driver from Mesa (v3dv) upstream
This is the blog post that explains how to build, install and test it with Sascha Willems demos
First I fixed some GCC problems in 5c6ba88
Then I checked out liblava demo projects... (driver + liblava in release)
Has anybody else already tried it or any idea what to do about it?
If you need latest CMake on your Raspberry Pi, check out: https://snapcraft.io/install/cmake/raspbian
You will also have to install:
sudo apt-get install libxi-dev
sudo apt-get install libatomic-ops-dev
And if you are connecting with SSH, just call this to execute lava on the connected display:
export DISPLAY=:0
Thank you to all that contribute to this awesome project! If someone would implement a simple compute example, it would be much appreciated.
This has been previously requested however, i would like to suggest implementing PresentMon frametime logging to a csv log so that it can be used universally & analysed in popular tools such as CapframeX.
Hi,
I've successfully managed to build the library under 32bit platform thanks to #2.
Now although I'm facing another problem. As I'd like to use this library as a pre-built library, I'm missing the include headers. Is there a possibility to have public headers installed via CMake when running the install target?
Would be fine to have them generated as well, one per target.
Thank you in advance,
Julian
While building Building CXX object liblava/CMakeFiles/lava.app.dir/liblava/app/gui.cpp.o
json extension throws an error due to a failed static assertion:
In file included from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/util/file.hpp:13,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/util.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/base/base.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/base/memory.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/base/device_table.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/base/device.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/base/physical_device.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/base/instance.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/frame/frame.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/frame.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/app/app.hpp:7,
from /home/kureta/Documents/repos/liblava-demo/liblava/liblava/app/app.cpp:5:
/home/kureta/Documents/repos/liblava-demo/liblava/ext/json/single_include/nlohmann/json.hpp: In instantiation of βValueType nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>::get() const [with ValueTypeCV = lava::window::state; ValueType = lava::window::state; typename std::enable_if<(((! nlohmann::detail::is_basic_json<U>::value) && nlohmann::detail::has_from_json<nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>, ValueType>::value) && (! nlohmann::detail::has_non_default_from_json<nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>, ValueType>::value)), int>::type <anonymous> = 0; ObjectType = std::map; ArrayType = std::vector; StringType = std::__cxx11::basic_string<char>; BooleanType = bool; NumberIntegerType = long int; NumberUnsignedType = long unsigned int; NumberFloatType = double; AllocatorType = std::allocator; JSONSerializer = nlohmann::adl_serializer]β:
/home/kureta/Documents/repos/liblava-demo/liblava/ext/json/single_include/nlohmann/json.hpp:17479:31: required from βnlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>::operator ValueType() const [with ValueType = lava::window::state; typename std::enable_if<(((((((! std::is_pointer<_Ptr>::value) && (! std::is_same<ValueType, nlohmann::detail::json_ref<nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer> > >::value)) && (! std::is_same<ValueType, typename StringType::value_type>::value)) && (! nlohmann::detail::is_basic_json<BasicJsonType>::value)) && (! std::is_same<ValueType, std::initializer_list<typename StringType::value_type> >::value)) && (! std::is_same<ValueType, std::basic_string_view<char> >::value)) && typename nlohmann::detail::detector<nlohmann::detail::nonesuch, void, nlohmann::detail::get_template_function, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer>&, ValueType>::value_t::value), int>::type <anonymous> = 0; ObjectType = std::map; ArrayType = std::vector; StringType = std::__cxx11::basic_string<char>; BooleanType = bool; NumberIntegerType = long int; NumberUnsignedType = long unsigned int; NumberFloatType = double; AllocatorType = std::allocator; JSONSerializer = nlohmann::adl_serializer]β
/home/kureta/Documents/repos/liblava-demo/liblava/liblava/app/app.cpp:65:24: required from here
/home/kureta/Documents/repos/liblava-demo/liblava/ext/json/single_include/nlohmann/json.hpp:17182:65: error: static assertion failed: types must be DefaultConstructible when used with get()
17182 | static_assert(std::is_default_constructible<ValueType>::value,
| ^~~~~
If I just comment out that assertion everything works as expected, but again, this is far from being a valid solution :)
It would be nice if we could somehow pass a required Vulkan version (both instance and physical device) as well as required extensions (instance and device) to app
.
The best place would probably be in frame_config
since both frame and app have access to it.
Hello!
Am going to try your Vulkan framework here hoping that it will offer a more sane programming experience than having to do it all from scratch.
Im working on a Raspberry Pi 4b with latest OS and stumble on the very first hurdle,
CMake Error at CMakeLists.txt:5 (cmake_minimum_required):
CMake 3.22 or higher is required. You are running version 3.18.4
I'll have to figure out how to get a higher version but just wanted to ask if 3.22 is really essential?
Cheers!
Hello!
Iv'e managed to build liblava on my Raspberry Pi4b, Raspberry OS Bullseye! :)
Some examples worked others didn't but that's good enough for me!
So now I'm trying to set up a external (to liblava) project to start making some simple programs following your tutorial code.
But I'm getting a bunch of errors for not finding various include files. How should I set this up with cmake so that I don't need to add all those paths one by one and by hand?
I saw in an older 'Issue' there were some suggestions but the links were broken,
https://github.com/liblava/liblava/blob/master/DOCS.md/#install
https://github.com/liblava/liblava-template
Cheers!
Linux (Arch)
When trying to run any example or the template I get the following terminal output:
[2020-03-21 18:35:03.200] [lava] [info] >>> 2020 preview / 0.5.0 - lava triangle / 0.5.0 - Mar 21 2020 18:06:29
[2020-03-21 18:35:03.201] [lava] [info] cmd ./lava-triangle
[2020-03-21 18:35:03.201] [lava] [debug] glfw 3.4.0 X11 GLX EGL OSMesa clock_gettime evdev
[2020-03-21 18:35:03.282] [lava] [info] vulkan 1.2.133
[2020-03-21 18:35:03.283] [lava] [error] create instance param
[2020-03-21 18:35:03.283] [lava] [error] create instance
Am I missing dependencies or how do I get a more verbos output?
Can reproduce by following the instructions labelled Install:
mkdir test
cd test
git init
git submodule add https://github.com/liblava/liblava.git
git submodule update --init --recursive
Make a basic main.cpp
$ cat main.cpp
#include <liblava/lava.hpp>
using namespace lava;
int main(int argc, char *argv[]) {
lava::frame frame({argc, argv});
return frame.ready() ? 0 : error::not_ready;
}
Make a basic CMakeLists.txt
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.20)
project(
Project
VERSION 0.1
LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED True)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/liblava
${CMAKE_CURRENT_BINARY_DIR}/liblava)
find_package(lava 0.6.2 REQUIRED)
add_executable(test main.cpp)
target_link_libraries(test lava::app)
The instructions then say to run a command that is impossible
$ # cmake -D lava_DIR=path/to/lava-install/lib/cmake/lava ..
$ exa -T -L=1 liblava/
liblava
βββ Catch2
βββ cmake
βββ CMakeFiles
βββ CMakeLists.txt
βββ doc
βββ empty.cpp
βββ ext
βββ glfw
βββ liblava
βββ liblava-demo
βββ LICENSE
βββ physfs
βββ README.md
βββ res
βββ spdlog
βββ src
βββ tests
$ ls liblava/cmake/
LavaConfig.cmake.in
$ ls liblava/liblava/
app asset.hpp block core.hpp frame lava.hpp util
app.hpp base block.hpp file frame.hpp resource util.hpp
asset base.hpp core file.hpp fwd.hpp resource.hpp
No such liblava/lib/
subdirectory exists, and neither the liblava/cmake/
nor liblava/liblava/
subdirectories have anything useful in them either.
Hey, is there any method to outputting the fps that I get in say lava-lamp.exe into a text file? preferably through the command line / no user input needed.
Like the Sascha Willems Vulkan samples, perhaps Liblava could provide shaders written in HLSL in addition to GLSL. I understand that in this repo's examples so far, the shaders are not the interesting part, but most students and teachers at my school can't even read GLSL, so I think providing examples in both may be beneficial. I personally wouldn't mind practicing porting between the two, so I could make a pull request for this if you think it's a good idea.
I need imgui docking feature, however the embed imgui is not the docking branch, how can I get the feature without changing the liblava
When creating an independent project with the installed lava-install following the instructions from https://github.com/liblava/liblava/blob/master/DOCS.md/#build I do get this error:
CMake Error at CMakeLists.txt:2 (find_package):
Found package configuration file:
/data/projects/pyramid/lavatut/lib/cmake/lava/lava-config.cmake
but it set lava_FOUND to FALSE so package "lava" is considered to be NOT
FOUND. Reason given by package:
The following imported targets are referenced, but are missing: freetype
Going off my comment on Discord, a few random ideas:
It would be nice to have easier access to specific queues, or the queues that were requested in create_param::queue_info
:
create_param::queue_info_list
, something like get_queues()
get_compute_queue()
but then return the dedicated ones, not any queue with compute supportThere's also a bug with device::create_param::queue_info::flags
where it can end up creating a queue with just one of the flag bits set:
liblava/liblava/base/device.cpp
Line 22 in 6a36737
liblava/liblava/base/physical_device.cpp
Line 42 in 6a36737
Using Win10, VS2019.
First, I followed the instructions and compiled Lava + external dependencies w/ Cmake and VS2019 in Debug x64 mode. Everything compiled successfully. Then, I created a new separate project, and added all the includes and libraries in the exact order specified in the lava tests project.
lava.app.lib
lava.frame.lib
lava.resource.lib
glfw3.lib
lava.block.lib
lava.base.lib
lava.util.lib
lava.core.lib
physfs-static.lib
spdlogd.lib
Tutorial Code
#include <liblava/lava.hpp>
using namespace lava;
int main(int argc, char* argv[]) {
lava::frame frame({ argc, argv });
if (!frame.ready())
return error::not_ready;
auto count = 0;
frame.add_run([&]() {
sleep(seconds(1));
count++;
log()->debug("{} - running {} sec", count, to_sec(frame.get_running_time()));
if (count == 3)
frame.shut_down();
return true;
});
return frame.run();
}
Then, I got a bunch of errors when building. Some issue w/ linking spdlogd.
1>spdlogd.lib(fmt.obj) : error LNK2005: "void __cdecl fmt::v7::detail::assert_fail(char const *,int,char const *)" (?assert_fail@detail@v7@fmt@@YAXPEBDH0@Z) already defined in tutorial.obj
1>spdlogd.lib(fmt.obj) : error LNK2005: "public: void __cdecl fmt::v7::detail::error_handler::on_error(char const *)" (?on_error@error_handler@detail@v7@fmt@@QEAAXPEBD@Z) already defined in tutorial.obj
1>spdlogd.lib(fmt.obj) : error LNK2005: "public: virtual __cdecl fmt::v7::format_error::~format_error(void)" (??1format_error@v7@fmt@@UEAA@XZ) already defined in tutorial.obj
1>spdlogd.lib(fmt.obj) : error LNK2005: "void __cdecl fmt::v7::detail::format_error_code(class fmt::v7::detail::buffer<char> &,int,class fmt::v7::basic_string_view<char>)" (?format_error_code@detail@v7@fmt@@YAXAEAV?$buffer@D@123@HV?$basic_string_view@D@23@@Z) already defined in tutorial.obj
1>spdlogd.lib(fmt.obj) : error LNK2005: "void __cdecl fmt::v7::format_system_error(class fmt::v7::detail::buffer<char> &,int,class fmt::v7::basic_string_view<char>)" (?format_system_error@v7@fmt@@YAXAEAV?$buffer@D@detail@12@HV?$basic_string_view@D@12@@Z) already defined in tutorial.obj
1>spdlogd.lib(fmt.obj) : error LNK2005: "int __cdecl fmt::v7::detail::safe_strerror(int,char * &,unsigned __int64)" (?safe_strerror@detail@v7@fmt@@YAHHAEAPEAD_K@Z) already defined in tutorial.obj
1>spdlogd.lib(spdlog.obj) : error LNK2005: "class fmt::v7::basic_string_view<char> & __cdecl spdlog::level::to_string_view(enum spdlog::level::level_enum)" (?to_string_view@level@spdlog@@YAAEAV?$basic_string_view@D@v7@fmt@@W4level_enum@12@@Z) already defined in tutorial.obj
1>spdlogd.lib(spdlog.obj) : error LNK2005: "char const * __cdecl spdlog::level::to_short_c_str(enum spdlog::level::level_enum)" (?to_short_c_str@level@spdlog@@YAPEBDW4level_enum@12@@Z) already defined in tutorial.obj
1>spdlogd.lib(spdlog.obj) : error LNK2005: "public: __cdecl spdlog::spdlog_ex::spdlog_ex(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)" (??0spdlog_ex@spdlog@@QEAA@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) already defined in tutorial.obj
1>spdlogd.lib(spdlog.obj) : error LNK2005: "public: __cdecl spdlog::spdlog_ex::spdlog_ex(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (??0spdlog_ex@spdlog@@QEAA@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@H@Z) already defined in tutorial.obj
1>spdlogd.lib(spdlog.obj) : error LNK2005: "public: virtual char const * __cdecl spdlog::spdlog_ex::what(void)const " (?what@spdlog_ex@spdlog@@UEBAPEBDXZ) already defined in tutorial.obj
Resizing a window causes the application to crash sometimes.
[lava] [critical] VkResult VK_SUBOPTIMAL_KHR
[lava] [error] validation: VUID-vkAcquireNextImageKHR-semaphore-01286 (-370888023)
[lava] [error] Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01286 ]
It seams like the semaphore can't be acquired after vkAcquireNextImageKHR
or vkQueuePresentKHR
returned VK_SUBOPTIMAL_KHR
.
Awesome project.
Currently there is no way (I found) to add synchronization between own command buffers and the main one used by the renderer.
This becomes a big issue when working with multiple command queues.
It would be great to be able to inject additional wait and signal semaphores to allow for synchronization.
https://github.com/liblava/liblava/releases/tag/0.6.2 download there Source code.
liblava-0.6.2/ext
all folders are empty
git submodule update --init --recursive
does not work because there no .git
folder
building from git clone
works
Currently the project failed to build even though cmake configuration is fine.
I'm lazy, and don't like freeing memory on my own when a low-cost abstraction exists to do it for me. vulkan.hpp provides an RAII abstraction around its Vulkan objects to handle freeing them. I think this makes a lot of sense for many Vulkan objects that exist within a clearly known lifetime. For instance, lava::app
can be assumed to exist only inside the scope of main()
, and live throughout all of it. Most (or all?) of the current examples also only have Vulkan object with known lifetimes, as well.
There doesn't seem to be anything special about how the destroy()
methods in the lava objects are called by a user (only where in the program matters, and only sometimes), so maybe they could be automated, and a lot of Vulkan programmers seem to think that RAII makes a lot of sense for graphics programming. I know that some Ziguanas disagree, but their preferred pattern isn't possible in C++.
I imagine most objects can fall out of scope and have their destroy()
method called automatically, and this wouldn't cause any issues so long as it is easy to factor between RAII objects and non-RAII objects. To achieve that, Nvidia decided that all their Vulkan objects are in a vk::
namespace, and the RAII abstractions inside a vk::raii::
namespace. So for instance, there is both a vk::Instance
and a vk::raii::Instance
object. Changing one into the other is as simple as changing the scope resolution. I imagine something similar with lava::instance
and lava::raii:instance
, lava::mesh
and lava::raii::mesh
, etc.
I'm not sure how best this could be implemented. Maybe the methods and all fields except for ptr
can be in a private struct, and the front facing lava::mesh
and lava::raii::mesh
inherit from this struct while also defining std::shared_ptr<mesh>
and std::unique_ptr<mesh>
respectively? The ::raii
objects would also need a destructor to replace destroy()
, if I understand correctly.
vulkan.hpp provides its samples with both explicit and raii deallocation, so programmers who have a preference can learn the tool either way.
What do you think about the idea? Would it be worthwhile for me to make a prototype?
Trying to code with liblava. Cool lib for fast prototyping. Can you show a little example how to use render_thread? Thank a lot.
Every time I freshly clone Liblava, it takes a very long time, and that's not to mention waiting on clean-build times. A lot of the dependencies seem niche enough that I think they could / should be made optional. I don't think all users need a debug GUI every time, nor JSON. And I suspect most users might not want Argh most of the time. I believe this friction could hamper broader adoption of Liblava.
Making these dependencies optional could also open the door to multiple backends. For example, using DirectXMath instead of GLM. Or SIMDJSON instead of JSON For Modern C++. This could be useful for larger projects that may want to integrate with other libraries that have redundant dependencies (especially if they want SDL2 instead of GLFW).
I'm thinking this might be achieved with a shell / batch script to handle project setup, and preprocessor #defines to handle conditional compilation. The CMake systems would probably also need to change somewhat.
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.