liblava/liblava

Modern and easy-to-use library for Vulkan

A modern and easy-to-use library for the Vulkan® API

 

lava provides essentials for low-level graphics - suited for prototyping, tooling, profiling and education.

This lean framework is written in neat C++23 and it strives for a modular rolling release as far as possible. We don't want to promise too much... but lava runs really smoothly on Windows and Linux.

➜   Download   •   Documentation (Tutorial + Guide)   •   Projects   •   Modules   •   Collaborate

In a nutshell

• liblava is written in modern C++ with latest Vulkan support
• Provides run loop abstraction for window and input handling
• Plain renderer and command buffer model
• Batteries included ➜ runtime shader compilation
• Texture and mesh loading from virtual file system
• Camera, imgui, logger and much more...

   

Take a look

#include "liblava/lava.hpp"
#include "imgui.h"

int main(int argc, char* argv[]) {

    lava::engine app("imgui demo", { argc, argv });
    if (!app.setup())
        return lava::error::not_ready;

    app.imgui.layers.add("demo window", []() {
        ImGui::ShowDemoWindow();
    });

    return app.run();
}

Demos

	free download on ➜ itch.io The collection includes all stages to play around. - You can easily switch between them.

Stages

	deferred shading + offscreen rendering Small demo that showcases how to render to an offscreen framebuffer and sample from it. - It is a challenge in itself and also a compact solution.
	uniform buffer + camera This loads a very large mesh from file and simply textures it. - Use your gamepad to control the camera if there is one around.
	push constants to shader Classic lamp to relax and where colors can be easily switched. - Unfortunately it also consumes power - so be aware!
	generating primitives Switch between basic shapes and use the camera to fly around. - A great start for your next interactive application.
	float, double & int meshes This demo shows how to check GPU features and render mesh data with custom vertex layout. - There is a chapter about it in the Guide.
	unique classic mesh Where graphics programming always begins. - An example that illustrates how little it actually takes to render a triangle.

Projects

	raytraced reflecting cubes Vulkan raytracing with liblava Support for the Vulkan KHR ray tracing extensions with idiomatic wrappers. ➜ pezcode
	Do you have a project? Submit it with a pull request

Modules

lava engine

  ➜   depends on app

lava app

  ➜   depends on frame + block + asset

lava frame

  ➜   depends on resource

lava block

  ➜   depends on base

lava asset

  ➜   depends on resource + file

lava resource

  ➜   depends on base

lava base

  ➜   depends on util

lava file

  ➜   depends on core

lava util

  ➜   depends on core

lava core

Collaborate

Use the issue tracker to report any bug or compatibility issue.

❤️   Thanks to all contributors making liblava flow...

If you want to contribute - we suggest the following:

1. Fork the official repository
2. Apply your changes to your fork
3. Submit a pull request describing the changes you have made

Support

Need help?   Please feel free to ask us on ➜ Discord

Help maintenance and development	Every star and follow motivates

License

liblava is licensed under MIT License which allows you to use the software for any purpose you might like - including commercial and for-profit use. However - this library includes several Third-Party libraries which are licensed under their own respective Open Source licenses ➜ They all allow static linking with closed source software.

All copies of liblava must include a copy of the MIT License terms and the copyright notice.

Vulkan and the Vulkan logo are trademarks of the Khronos Group Inc.

Copyright (c) 2018-present - Lava Block OÜ and contributors

liblava's Issues

Independent Project Build Fails - freetype not found

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

FBX Loading

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?

Please support MSYS2 MINGW64

Currently the project failed to build even though cmake configuration is fine.

Request for compute example

Thank you to all that contribute to this awesome project! If someone would implement a simple compute example, it would be much appreciated.

Failing to compile sample project

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

PresentMon-like frametime logging

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.

Resize causes crash on Linux (tested with AMD gpu)

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.

Optional Dependencies

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.

render_thread

Trying to code with liblava. Cool lib for fast prototyping. Can you show a little example how to use render_thread? Thank a lot.

HLSL Examples

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.

Does cmake ver need to be that high? Raspberry OS on 3.18

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!

Documentation

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.

Offscreen rendering

Hey,
Is there a quick way to render a scene without an actual window? Let's say on servers without an physical display attached?

how to change rendering topology

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?

Public Headers

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

sRGB support

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:

• Swapchain surface format doesn't request _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.
• Imgui :< theme colors are defined as sRGB, then interpolated in the shader (which is incorrect), and finally output as mangled sRGB. As a result, storing to an sRGB swapchain image will effectively apply the transform twice. There's an ongoing PR (ocornut/imgui#2943) that partly fixes this. This is the real blocking thing here.

Would appreciate some input 😃 Maybe there's a reason you went without sRGB, or you think it's a non-issue.

Why can't I see Shader edits reflected in the program?

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.

[error] create instance

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?

How to insert render passes before gui?

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 😄

conan package

Any chances this can be packaged to Conan?
It's a handy-dandy tool to manage c++ libraries https://conan.io/.

Queue creation improvements

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:

1. expose the list of queues exactly in the order of create_param::queue_info_list, something like get_queues()
2. (if no special queues are requested? always?) let lava try to find dedicated queues for compute and transfer (some GPUs have those, and they could potentionally be faster for async operations). this could reuse the existing functions like get_compute_queue() but then return the dedicated ones, not any queue with compute support

There'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

if (!physical_device->get_queue_family(index, param.queue_info_list[i].flags)) {

which then only checks if any flag is set, not all of them:

liblava/liblava/base/physical_device.cpp

Line 42 in 6a36737

if (queue_family_properties[i].queueFlags & flags) {

Build error about json extension

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

Install Instructions are Incorrect

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.

Unable to take screenshots (how to best extend create methods)

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.

VmaMemoryUsage

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:

• allocation info for images
• 3d textures
• creation of meshes accessible in compute shades

I see no clear way to fix this problem, but some options are:

• (make members required for creation public (bad hack))
• (add way more parameters to creation methods (bloats methods)
• add additional create method accepting a function, with accepts references to all required members for creation. (complicated for the user, but simple to implement)
• add create_info struct as parameter
• add methods to change default creation parameters

The last two would be the best options in my opinion.

Maybe this should be discussed in a separate issue.

Can't load texture with mipmaps

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.

IMGUI assert raised in liblava not present in "clean" IMGUI clone

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.

1. 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

2. 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.

Single validation error, not critical Linux Nvidia

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

Outputting fps to a text file?

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.

First physical device is selected by default and there is no way to select another device

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

lava on Raspberry Pi

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)

• Performance in lamp has much room for improvement
• When you move the cam in spawn you get tiled artefacts

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

How do I set up a cmake project?

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!

Request for imgui docking

I need imgui docking feature, however the embed imgui is not the docking branch, how can I get the feature without changing the liblava

Ability to select Vulkan version and extensions

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.

No window showing up on the template

Hello,
I installed VULCAN, then built the app without any issues.
Upon running the executable, it only prints, no imgui window is showing up,

Thanks,

Latest release can not be built from Release downloads

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

RAII Abstractions

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?

Add support to supply semaphores to renderer

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.

CMake build on Win32 platform

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...