Git Product home page Git Product logo

daxa's Introduction

Daxa logo

Daxa

Daxa is my opinionated GPU API abstraction over Vulkan.

Why would you want to use Daxa? These are some of the aspects of Daxa that set it apart from most other Vulkan abstractions:

  • Specifically designed for GPGPU programming and GPU-driven rendering. Daxa makes writing modern renderers simple and easy. It does not compromise for old hardware or old API concepts. Modern GPUs are the target (for Nvidia this is >=Turing, for AMD this is >= RDNA1).

  • Fully bindless. Buffers, images, samplers, and acceleration structures are all exclusively accessed via a bindless API. The bindless API abstracts descriptors completely. There are no bindings, no descriptor sets, no set layouts, no descriptor pools, and no binding or set indices within shaders.

  • Very high convenience with near zero boilerplate. Daxa makes the simple things as easy as possible. It abstracts over unnecessarily explicit parts of Vulkan. Tons of default values and common abstractions for renderers such as a render-graph and shader build system are provided by Daxa.

  • Shader utilities and shader feature integration. Daxa provides custom GLSL and HLSL headers, host/shader code sharing utilities, and even a shader build system featuring hot reloading and includes management. Especially the shader integration for many features is very convenient.

  • Efficient safety checks. An often neglected part of RHIs and rendering libraries is safety and debugging validation. Daxa performs many validation checks at very low overhead. Especially the render graph has very detailed error messages detailing misuse.

  • Effective abstractions with predictable performance. In contrast to many other abstractions, core Daxa never caches or lazily creates pipelines, layouts, or other objects. It should have performance as predictable as Vulkan. This makes profiling intuitive.

Getting started

If you want to get started with Daxa, check out learndaxa.com, a website hosting an up-to-date Daxa tutorial as well as a Wiki that provides more information on the Daxa API.

Additionally, the Daxa repository has a set of example projects in the tests folder.

If you prefer to interact in Discord over GitHub issues, Daxa has a Discord server.

List of biggest features

  • defaulted, named parameters for most functions via c++20 designated struct initialization
  • ergonomic, simplified object creation
  • easy device selection and properties query
  • integrated debug utilities such as debug names and range labels
  • feature-rich render-graph, handling automatic synchronization and more
  • shader integration for render-graph
  • shader/host code shading utilities
  • fully abstracted descriptor sets
  • automated, deeply integrated bindless system
  • shader bindless integration
  • a shader build system featuring hot reloading and #include handling
  • designed for threading, each object has its thread-safety described
  • no concept of render-pass or frame-buffer
  • typesafe simplified command recording and submission
  • automated memory allocation for buffers and images using VMA (manual allocation also possible)
  • swapchain that handles frames in flight pacing and WSI problems like resizing
  • always enabled dynamic state for any option that is cost-free on target hardware
  • simpler pipelines, no pipeline layout, and no descriptor set layouts
  • a full C API may be used to create API wrappers for other languages
  • extensive low-overhead validation checks
  • integrates most commonly used Vulkan extensions
  • support for buffer device addresses
  • always mapped buffers
  • mesh shaders, in core as well as pipeline manager
  • raytracing, in core, pipeline manager AND rendergraph
  • async compute/ async transfer/ multi-queue support
  • ergonomic explicit synchronization (optional, you can also use the render-graph instead)
  • stores queriable metadata for all objects, similar to dx11
  • simplified, semi-managed resource lifetimes
  • resource destruction is deferred until all currently submitted commands finish execution
  • unified IDs in host and shader code for buffers, images, etc.
  • automatic default image view integrated into all images
  • controllable parent-child lifetime semantics
  • fully abstracts Vulkan, allows Daxa to have more control and be more convenient
  • dearImGui backend
  • transient memory pool utility object

daxa's People

Contributors

asti0s avatar brynnbrancamp avatar down-s avatar fabulouscodingfox avatar gaberundlett avatar gaberundlett-tuxedo avatar ipotrick avatar jaisiero avatar kidrigger avatar lukasino1214 avatar matejsakmary avatar nellfs avatar solmidnight avatar triedangle avatar trojanfoe avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

jipboesenkool a-day-old-bagel triedangle lucasleandro1204 sovjetspy lukasino1214 maksym-pasichnyk study-game-engines ralphschuler fabulouscodingfox xiaohunqupo codesotakuyt yknishidate asdlei99 kidrigger jaisiero lamarrr rodrigobmg exdal learndaxa solmidnight loopunit omnisudo linecode rednicstone janingohaas gaberundlett-tuxedo

daxa's Issues

daxa 3.0

As daxa 2.0 is nearly done, we can start to plan and build daxa 2.X.

Main Features:

* [ ] rust bindings
* [ ] gpu based validation of resource id access
* [ ] better device creation (make physical device list visible and all attributes, create device based on selected physical
* [ ] use defer makro for function unwinding on error
* [ ] flags work in c++
* [ ] replace size_t's for u64 if they represent a VkDeviceSize
* [ ] swapchain format selection should respect the format restrictions based on the image use flags
* [ ] swapchain format selection rework

  • task head concept cleanup + arrays in task heads + wiki for tasks
  • c apidevice)~~
  • raytracing api
  • raytracing pipeline
  • type safe command recording
  • improved VkCommandPool reuse. VkCommandEncoder idea.
  • improved ids, full rust safeties

Compilation error

Somehow, I get an error during compilation on Linux:
image

The error is caused by a macro called "None" already existing. I could not find what defined this macro in my system, so I avoided the issue by adding "ifdef None", "undef None", "endif" line 100 in types.hpp.

gcc version and build logs below.
image
install-x64-linux-dbg-out.log

Compiled under msvc 2019?

Under win8, msvc2019, no clang, got error with template:
impl_device.cpp 186
return CommandList{ManagedPtr{impl->command_list_recyclable_list.recycle_or_create_new(this->make_weak(), info).release()}};
in these function : impl->command_list_recyclable_list.recycle_or_create_new(this->make_weak(), info).release()

Daxa crashes when creating an image with format R8G8B8_UNORM

It looks like my Nvidia driver crashes when daxa calls vkCreateImage using that image format:

Unhandled exception at 0x00007FFDABC81A1B (nvoglv64.dll) in daxa-lod.exe: 0xC0000094: Integer division by zero.

image

Which it doesn't occur when I use other format like R8G8B8A8_UNORM

And this is the call stack:
image

This is my code before the crash:

ImageTexture red_brick_wall = ImageTexture(RED_BRICK_WALL_IMAGE);
daxa_u32 SIZE_X = red_brick_wall.get_width();
daxa_u32 SIZE_Y = red_brick_wall.get_height();
daxa_u32 SIZE_Z = 1;

daxa_u32 image_stage_buffer_size = red_brick_wall.get_size();

images.push_back(device.create_image({
    .dimensions = 2,
    .format = daxa::Format::R8G8B8_UNORM, // change format for R8G8B8A8_UNORM and it doesn't crash
    .size = {SIZE_X, SIZE_Y, SIZE_Z},
    .usage = daxa::ImageUsageFlagBits::SHADER_STORAGE | daxa::ImageUsageFlagBits::TRANSFER_DST | daxa::ImageUsageFlagBits::SHADER_SAMPLED,
    .name = "image_2",
}));

Let me know if you need more info.
Cheers.

Unchecked usage of optional extension VK_EXT_debug_utils

Context

VK_EXT_debug_utils is a Vulkan extension that allows the developer to gather more feedback about his usage of the API. For more details see the Vulkan registry entry.
This extension has not yet been promoted to core, so its availability is optional to the driver.

Issue:

Daxa requests the extension in daxa::ImplInstace::ImplInstance(daxa::InstanceInfo) at Daxa/src/impl_instance.cpp:61:
extension_names.push_back(VK_EXT_DEBUG_UTILS_EXTENSION_NAME);

It the tries to acquire a pointer to the vkSetDebugUtilsObjectNameEXT in daxa::ImplDevice::ImplDevice(daxa::DeviceInfo, daxa::ManagedWeakPtr, VkPhysicalDevice) at Daxa/src/impl_device.cpp:714:
this->vkSetDebugUtilsObjectNameEXT = reinterpret_cast<PFN_vkSetDebugUtilsObjectNameEXT>(vkGetDeviceProcAddr(this->vk_device, "vkSetDebugUtilsObjectNameEXT"));

This is done without checking the extensions availability using vkEnumerateInstanceExtensionProperties. The same also applies for vkCmdBeginDebugUtilsLabelEXT and vkCmdEndDebugUtilsLabelEXT.

Effect:

Data exits with SIGSEGV (Segmentation fault) when calling daxa::Instance::create_device on platforms that do not support VK_EXT_debug_utils.

Proposed solution:

The existence of VK_EXT_debug_utils should be checked before tying to acquire a function pointer to one of its methods.

Additionally I propose the following changes:

  • VK_EXT_debug_utils should only be enabled when compiled under a certain condition, for example only in DEBUG mode. Otherwise this may needlessly consume resources.
  • The usage of vkGetDeviceProcAddr in this case is also wrong. Since VK_EXT_debug_utils is an instance level extension the pointer may only be acquired using an instance handle using vkGetInstanceProcAddr. Other use may led to undefined behaviour as stated in the Vulkan registry. The pointer should be acquired using and instance handle in daxa::InstanceImpl::InstanceImpl(daxa::InstanceInfo).

Test 2 2 failed

daxa_test_2_daxa_api_2_device.exe :
[FAILURE]: terminator_CreateDevice: Failed in ICD C:\Windows\system32\.\nvoglv64.dll vkCreateDevicecall
[[DAXA ASSERT FAILURE]]: validation error

msvc2019 (no clang), win8, VulkanSDK\1.3.224.1, Geforce 1060 6gb
I tried to fix it like here, there are errors along the chain, zeux/niagara#18

Vulkan info : https://pastebin.com/wMUDUbmk

daxa 2.0 milestone

List of todos to get daxa 2.0 out.
Daxa 2.0 is only meant to be a cleanup of the current state of daxa for a new stable release.

General:

  • simplify shader integration (image handles, type sharing and makro naming)
  • rename Context to Instance
  • add all missing max enum count values
  • remove image aspect
  • add image compatibility flags (currently, we say all 3D images are 2D array compat.)
  • improve glsl shader image and buffer access (add defines to create own accessors that take qualifiers into account)

Documentation:

  • improve readme
  • fix up tutorial
  • add function documentation for complex functions
  • task graph wiki page
  • pipeline manager wiki page
  • clean up samples and tests

TaskGraph:

  • rename it to TaskGraph
  • task list interface should give layout of used images via a function.
  • fix naming of TaskImageHandle and TaskBufferHandle.
  • make staging memory pool optional (with corresponding debug messages)

PipelineManager:

  • return a variant of all possible results and remove the optional<Result> on hot reloading
  • make thread safe

Pipeline Creation too complex

The creation of graphics and compute pipelines has too many nested structs and options.
For example separate source files for each shader is unnessecary and should be removed.
The structs to init pipelines should be reduced by a lot.

aspect mask in used images in tasks should be inferred by the TaskImageUse.

currently when using for example a depth image in a task, the user must specify daxa::TaskImageAccess::DEPTH_ATTACHMENT, {.image_aspect = daxa::ImageAspectFlagBits::DEPTH} for the used image wich is redundant.

Add new struct TaskImageMipArraySlice to specify the mip array slicewithout aspekt.
This should be downcastable from a ImageMipArraySlice.

Bad error messages

When forgetting to call wait for idle and collect garbage, the error message is complaining about ref counting. This is very unintuitive and problematic.

Add TaskRessourceGroups for Images and Buffers.

Add the ability to have one TaskImage or one TaskBuffer represent multiple images/buffers.
Make the represented images in each frame variable. This way variable workloads can be represented more easily and efficiently.

No example on sampling an image?

I wanted to explore your library in RenderDoc, specifically how you handle images, for some inspiration on my own rust-based rendering engine. But it seems like you don't have any examples sampling from images, right? I also haven't found any tests regarding that, though even if I did, it would be kind of difficult to get a capture of it with RenderDoc.

Anyways, so far I've only come across 2 minor issues in the examples:

  • the bois example's shaders have the shared.inl declared in the wrong directory
  • In most examples I have to set the cwd to the shader dir for them to work, apart from 2_daxa_api/7_pipeline_manager there I have to specifically not do that otherwise it asserts.

Thanks for the awesome library :D

debug shaders

Add compile option to the pipeline compiler to generate debug information into shader modules.

Device Creation

Device creation has problems:

  • there is no way to read physical device properties and choose without the callback to create a device
  • there are no/ poor errors for device creation failure

My idea would be to remove the device selector in device creation.
Instead make it a free function that takes a physical device list from the daxa instance.

It might also be nice if device creation wouldnt fail when a feature is not present and instead make it the user responsibility to check if a created device can actually do what is asked of it. This might be misleading but also more convenient to program.

Make Handle semantics more consistent

CommandList and TimelineSemaphore arent wrapped by a handle.

This prevents reuse and other automatic lifetime management.

Also Queue::submit needs to use vectors and move semantics for CommandLists wich is very ugly and easy to missuse.

Shader Insanity with task list

Integrate shader compilatiuon with task list.
Shader declares use of a task list resource.
Task list will inferr that use and add the corresponding task.
No more need to pass task resources around, they simply become a global in the shader after usage declaration.

Syntax proposal:

DAXA_DECLARE_TASK_IMAGE_USE(task_image_debug_name, access, slice);

void main()
{
  daxa_Image2Df32 image = task_image_debug_name;
}

Improve Shader integration samples

Additional Samples:

  • bindless handle upload methods (push constant, constant buffer, buffer)
  • binldess handle access in shaders (pass to functions, store in local variable, store in buffer, store in struct)
  • bindless handle transport (write handles into buffer, following shader reads handles and uses them)
  • showcasing handle operations (id_to_index and others)
  • showing constant buffer use

Improve Error handling

Vulkan error handling:

  • return the vulkan error in daxa error messages if they appear
  • test against vulkan errors everywhere

Error callback:

  • daxa should have a debug print callback that is called. Daxa SHOULD NOT print to std::cout per default.
  • daxas default error callback should simply retain current behaviour (printing to std::cout).

Daxa Image creation

The dimension values passed into device.create_image() are not checked which allows invalid parameters (0 for example). The result of vma create image is also not checked so the error is reported only when trying to create image view in the create_image() function.

Remove C api

  • remove c api
  • convert back all abi types to std:: types

implement small vector optimization

There are many std::vectors in the backend wich are very small. These cause a lot of small memory allocations.
Implement a small vector, wich can store N elements on the stack to reduce allocations.

c api

Daxa should have a c api.

Reasoning

A c api would allow for binding daxa to many other languages like rust, zig and java.

Requirements

  • C api should generally allow for theoretically safe rust use. A potential rust wrapper should follow all rust rules of safety to the outside.
  • Very minimal, as small as possible
  • Cpp api should also use it under the hood.

Other goals

  • expose functions returning and checking required device limits, features properties and extensions

Building on linux with gcc and clang fails 

cmake --build --preset=gcc-x86_64-linux-gnu-debug
[1/20] Building CXX object tests/CMake...list.dir/Debug/Unity/unity_0_cxx.cxx.o
FAILED: tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Debug/Unity/unity_0_cxx.cxx.o 
/usr/bin/c++ -DDAXA_BUILT_WITH_DXC=true -DDAXA_BUILT_WITH_GLSLANG=true -DDAXA_BUILT_WITH_UTILS=true -DDAXA_BUILT_WITH_WAYLAND=true -DDAXA_BUILT_WITH_X11=true -DDAXA_SAMPLE_PATH=\"/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list\" -DDAXA_SHADERLANG_GLSL=1 -DDAXA_SHADERLANG_HLSL=2 -DFFX_GCC -DUNICODE -D_UNICODE -DCMAKE_INTDIR=\"Debug\" -I/home/chase/dev/Daxa/tests -I/home/chase/dev/Daxa/include -isystem /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/vcpkg_installed/x64-linux/include -isystem /home/chase/dev/utils/vulkan-sdk/1.3.231.2/x86_64/include -g -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Wimplicit-fallthrough -Wno-language-extension-token -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wuseless-cast -Wno-strict-aliasing -std=gnu++20 -MD -MT tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Debug/Unity/unity_0_cxx.cxx.o -MF tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Debug/Unity/unity_0_cxx.cxx.o.d -o tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Debug/Unity/unity_0_cxx.cxx.o -c /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Unity/unity_0_cxx.cxx
In file included from /home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/main.cpp:2,
                 from /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Unity/unity_0_cxx.cxx:3:
/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/mipmapping.hpp: In function ‘void tests::mipmapping()’:
/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/mipmapping.hpp:81:13: warning: missing initializer for member ‘MipmappingGpuInput::paint_col’ [-Wmissing-field-initializers]
   81 |             };
      |             ^
/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/mipmapping.hpp:81:13: error: designator order for field ‘MipmappingGpuInput::paint_col’ does not match declaration order in ‘MipmappingGpuInput’
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-language-extension-token’ may have been intended to silence earlier diagnostics
[4/20] Building CXX object CMakeFiles/daxa.dir/Debug/Unity/unity_0_cxx.cxx.o
FAILED: CMakeFiles/daxa.dir/Debug/Unity/unity_0_cxx.cxx.o 
/usr/bin/c++ -DDAXA_BUILT_WITH_DXC=true -DDAXA_BUILT_WITH_GLSLANG=true -DDAXA_BUILT_WITH_UTILS=true -DDAXA_BUILT_WITH_WAYLAND=true -DDAXA_BUILT_WITH_X11=true -DDAXA_SHADERLANG_GLSL=1 -DDAXA_SHADERLANG_HLSL=2 -DFFX_GCC -DUNICODE -D_UNICODE -DCMAKE_INTDIR=\"Debug\" -I/home/chase/dev/Daxa/include -isystem /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/vcpkg_installed/x64-linux/include -isystem /home/chase/dev/utils/vulkan-sdk/1.3.231.2/x86_64/include -g -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Wimplicit-fallthrough -Wno-language-extension-token -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wuseless-cast -Wno-strict-aliasing -std=gnu++20 -MD -MT CMakeFiles/daxa.dir/Debug/Unity/unity_0_cxx.cxx.o -MF CMakeFiles/daxa.dir/Debug/Unity/unity_0_cxx.cxx.o.d -o CMakeFiles/daxa.dir/Debug/Unity/unity_0_cxx.cxx.o -c /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx
In file included from /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx:9:
/home/chase/dev/Daxa/src/impl_pipeline.cpp:257:12: warning: base class ‘struct IDxcIncludeHandler’ has accessible non-virtual destructor [-Wnon-virtual-dtor]
  257 |     struct DxcCustomIncluder : public IDxcIncludeHandler
      |            ^~~~~~~~~~~~~~~~~
/home/chase/dev/Daxa/src/impl_pipeline.cpp: In member function ‘daxa::Result<std::vector<unsigned int> > daxa::ImplPipelineCompiler::gen_spirv_from_glslang(const daxa::ShaderInfo&, VkShaderStageFlagBits, const daxa::ShaderCode&)’:
/home/chase/dev/Daxa/src/impl_pipeline.cpp:1149:75: warning: conversion to ‘std::streamsize’ {aka ‘long int’} from ‘std::__cxx11::basic_string<char>::size_type’ {aka ‘long unsigned int’} may change the sign of the result [-Wsign-conversion]
 1149 |             ofs.write(preprocessed_result.data(), preprocessed_result.size());
      |                                                   ~~~~~~~~~~~~~~~~~~~~~~~~^~
In file included from /home/chase/dev/Daxa/build/gcc-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx:11:
/home/chase/dev/Daxa/src/impl_swapchain.cpp: In member function ‘void daxa::ImplSwapchain::recreate_surface()’:
/home/chase/dev/Daxa/src/impl_swapchain.cpp:126:28: error: ‘wl_display_connect’ was not declared in this scope
  126 |                 .display = wl_display_connect(nullptr),
      |                            ^~~~~~~~~~~~~~~~~~
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-language-extension-token’ may have been intended to silence earlier diagnostics
ninja: build stopped: subcommand failed.

Same issue for clang

cmake --build --preset=clang-x86_64-linux-gnu-release
[9/35] Building CXX object tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Release/Unity/unity_0_cxx.cxx.o
FAILED: tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Release/Unity/unity_0_cxx.cxx.o 
/usr/bin/c++ -DDAXA_BUILT_WITH_DXC=true -DDAXA_BUILT_WITH_GLSLANG=true -DDAXA_BUILT_WITH_UTILS=true -DDAXA_BUILT_WITH_WAYLAND=true -DDAXA_BUILT_WITH_X11=true -DDAXA_SAMPLE_PATH=\"/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list\" -DDAXA_SHADERLANG_GLSL=1 -DDAXA_SHADERLANG_HLSL=2 -DFFX_GCC -DUNICODE -D_UNICODE -DCMAKE_INTDIR=\"Release\" -I/home/chase/dev/Daxa/tests -I/home/chase/dev/Daxa/include -isystem /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/vcpkg_installed/x64-linux/include -isystem /home/chase/dev/utils/vulkan-sdk/1.3.231.2/x86_64/include -O3 -DNDEBUG -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Wimplicit-fallthrough -Wno-language-extension-token -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wuseless-cast -Wno-strict-aliasing -std=gnu++20 -MD -MT tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Release/Unity/unity_0_cxx.cxx.o -MF tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Release/Unity/unity_0_cxx.cxx.o.d -o tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Release/Unity/unity_0_cxx.cxx.o -c /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Unity/unity_0_cxx.cxx
In file included from /home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/main.cpp:2,
                 from /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/tests/CMakeFiles/daxa_test_2_daxa_api_6_task_list.dir/Unity/unity_0_cxx.cxx:3:
/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/mipmapping.hpp: In function ‘void tests::mipmapping()’:
/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/mipmapping.hpp:81:13: warning: missing initializer for member ‘MipmappingGpuInput::paint_col’ [-Wmissing-field-initializers]
   81 |             };
      |             ^
/home/chase/dev/Daxa/tests/2_daxa_api/6_task_list/mipmapping.hpp:81:13: error: designator order for field ‘MipmappingGpuInput::paint_col’ does not match declaration order in ‘MipmappingGpuInput’
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-language-extension-token’ may have been intended to silence earlier diagnostics
[15/35] Building CXX object CMakeFiles/daxa.dir/Release/Unity/unity_0_cxx.cxx.o
FAILED: CMakeFiles/daxa.dir/Release/Unity/unity_0_cxx.cxx.o 
/usr/bin/c++ -DDAXA_BUILT_WITH_DXC=true -DDAXA_BUILT_WITH_GLSLANG=true -DDAXA_BUILT_WITH_UTILS=true -DDAXA_BUILT_WITH_WAYLAND=true -DDAXA_BUILT_WITH_X11=true -DDAXA_SHADERLANG_GLSL=1 -DDAXA_SHADERLANG_HLSL=2 -DFFX_GCC -DUNICODE -D_UNICODE -DCMAKE_INTDIR=\"Release\" -I/home/chase/dev/Daxa/include -isystem /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/vcpkg_installed/x64-linux/include -isystem /home/chase/dev/utils/vulkan-sdk/1.3.231.2/x86_64/include -O3 -DNDEBUG -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Wimplicit-fallthrough -Wno-language-extension-token -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wuseless-cast -Wno-strict-aliasing -std=gnu++20 -MD -MT CMakeFiles/daxa.dir/Release/Unity/unity_0_cxx.cxx.o -MF CMakeFiles/daxa.dir/Release/Unity/unity_0_cxx.cxx.o.d -o CMakeFiles/daxa.dir/Release/Unity/unity_0_cxx.cxx.o -c /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx
In file included from /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx:3:
/home/chase/dev/Daxa/src/impl_device.cpp: In constructor ‘daxa::ImplDevice::ImplDevice(daxa::DeviceInfo, const daxa::DeviceProperties&, daxa::ManagedWeakPtr, VkPhysicalDevice)’:
/home/chase/dev/Daxa/src/impl_device.cpp:646:22: warning: unused variable ‘result’ [-Wunused-variable]
  646 |             VkResult result = vmaCreateBuffer(this->vma_allocator, &vk_buffer_create_info, &vma_allocation_create_info, &buffer_device_address_buffer, &buffer_device_address_buffer_allocation, nullptr);
      |                      ^~~~~~
/home/chase/dev/Daxa/src/impl_device.cpp: In member function ‘daxa::types::ImageId daxa::ImplDevice::new_image(const daxa::ImageInfo&)’:
/home/chase/dev/Daxa/src/impl_device.cpp:1041:18: warning: unused variable ‘vk_create_image_result’ [-Wunused-variable]
 1041 |         VkResult vk_create_image_result = vmaCreateImage(this->vma_allocator, &vk_image_create_info, &vma_allocation_create_info, &ret.vk_image, &ret.vma_allocation, nullptr);
      |                  ^~~~~~~~~~~~~~~~~~~~~~
/home/chase/dev/Daxa/src/impl_device.cpp:1077:18: warning: unused variable ‘vk_create_image_view_result’ [-Wunused-variable]
 1077 |         VkResult vk_create_image_view_result = vkCreateImageView(vk_device, &vk_image_view_create_info, nullptr, &ret.view_slot.vk_image_view);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/chase/dev/Daxa/src/impl_device.cpp: In member function ‘daxa::types::ImageViewId daxa::ImplDevice::new_image_view(const daxa::ImageViewInfo&)’:
/home/chase/dev/Daxa/src/impl_device.cpp:1140:18: warning: unused variable ‘result’ [-Wunused-variable]
 1140 |         VkResult result = vkCreateImageView(vk_device, &vk_image_view_create_info, nullptr, &ret.vk_image_view);
      |                  ^~~~~~
/home/chase/dev/Daxa/src/impl_device.cpp: In member function ‘daxa::types::SamplerId daxa::ImplDevice::new_sampler(const daxa::SamplerInfo&)’:
/home/chase/dev/Daxa/src/impl_device.cpp:1198:18: warning: unused variable ‘result’ [-Wunused-variable]
 1198 |         VkResult result = vkCreateSampler(this->vk_device, &vk_sampler_create_info, nullptr, &ret.vk_sampler);
      |                  ^~~~~~
In file included from /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx:9:
/home/chase/dev/Daxa/src/impl_pipeline.cpp: At global scope:
/home/chase/dev/Daxa/src/impl_pipeline.cpp:257:12: warning: base class ‘struct IDxcIncludeHandler’ has accessible non-virtual destructor [-Wnon-virtual-dtor]
  257 |     struct DxcCustomIncluder : public IDxcIncludeHandler
      |            ^~~~~~~~~~~~~~~~~
/home/chase/dev/Daxa/src/impl_pipeline.cpp: In member function ‘daxa::Result<std::vector<unsigned int> > daxa::ImplPipelineCompiler::gen_spirv_from_glslang(const daxa::ShaderInfo&, VkShaderStageFlagBits, const daxa::ShaderCode&)’:
/home/chase/dev/Daxa/src/impl_pipeline.cpp:1149:75: warning: conversion to ‘std::streamsize’ {aka ‘long int’} from ‘std::__cxx11::basic_string<char>::size_type’ {aka ‘long unsigned int’} may change the sign of the result [-Wsign-conversion]
 1149 |             ofs.write(preprocessed_result.data(), preprocessed_result.size());
      |                                                   ~~~~~~~~~~~~~~~~~~~~~~~~^~
In file included from /home/chase/dev/Daxa/build/clang-x86_64-linux-gnu/CMakeFiles/daxa.dir/Unity/unity_0_cxx.cxx:11:
/home/chase/dev/Daxa/src/impl_swapchain.cpp: In member function ‘void daxa::ImplSwapchain::recreate_surface()’:
/home/chase/dev/Daxa/src/impl_swapchain.cpp:126:28: error: ‘wl_display_connect’ was not declared in this scope
  126 |                 .display = wl_display_connect(nullptr),
      |                            ^~~~~~~~~~~~~~~~~~
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-language-extension-token’ may have been intended to silence earlier diagnostics
[18/35] Building CXX object CMakeFiles/daxa.dir/Release/Unity/unity_1_cxx.cxx.o
ninja: build stopped: subcommand failed.

rust api

We need...

Rust side types:

  • FixedlList
  • SmallString
  • Optional
  • Variant
    These types are our c api compatibility types. These c types should have a mirror type in rust just like in c++ (look at types.hpp).
    These types should be apbi compatible, meaning a simple transmute should always be enough to cast between them.

Refcounting Handles:

  • the c api already provides refcounting functions.
  • implement rust generic implementing the refcounting using the c functions
  • implement wrapper functions for all the refcounted handles

Functions:

  • not all functions info struct need to be abi compatible, use new types when convenient
  • the Info structs should ALWAYS be abi compatible, never translate these types, a reinterpret cast of the reference should be enough
  • orient yourself on the c and c++ api
  • all c functions that may return errors should return a rust error enum

Can't compile project.

Hello, I compiled daxa from the latest repo version in both debug & release on windows with the presets being: cl-x86_64-windows-msvc-debug, and cl-x86_64-windows-msvc-release. I finally think I got daxa implemented, however I get this error when compiling from my project:
image

I'm not super familiar with cmake, I only use it to compile libraries to use in my projects so I don't know if there's some command line argument I need to add that was stated in the wiki.

Unresolved external symbols.

Hello, it's me again, I'm still trying to implement daxa into my project, however I came across some external symbol errors. It's referencing imgui, fsr2, and something relating to the pipeline.
image

Some things to note: I don't want to use imgui, so I was hoping there was some define statement I could use to exclude it, but found no luck, so I even tried to remove the imgui from the src in the cloned repo, and remove the references to imgui and that file in the cmake lists file, however when recompiling I get an error referencing pthreads.lib and pthead.lib (the error refers to not being able to link to it). This error only occurs when removing imgui files from the cloned repo.

Internal naming change

Rename dummy sampler to sampler fallback in device.
Rename GPUResources to GPUShaderResources.

Swapchain recreation - happens multiple times on resize

In the current implementation Daxa checks if the swapchain is out of date two times. FIrst in impl_swapchain.cpp when acquiring new immage, second in impl_device.cpp when presenting the image to the screen. I find this innitself a bit weird as I believe the check should be done only once per frame ( when acquiring the immage ).

In the provided examples a third check is done by the user via the use of glfw window resized callback. This in turn calls the recreation of the swapchain again (with wrong values - but they get ignored by the daxa implementation anyways so it has no effect).

having trouble building

I am having trouble building Daxa, I dont know what I'm doing wrong

here is the message that I am getting

-- Running vcpkg install - done
-- The C compiler identification is MSVC 19.34.31935.0
-- The CXX compiler identification is MSVC 19.34.31935.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.25/Modules/CMakeTestCCompiler.cmake:70 (message):
The C compiler

"C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: C:/VulkanTools/Daxa/build/cl-x86_64-windows-msvc/CMakeFiles/CMakeScratch/TryCompile-xs9yil

Run Build Command(s):C:/Users/kamer/AppData/Roaming/Python/Python39/Scripts/ninja.exe cmTC_2cd02 && [1/2] Building C object CMakeFiles\cmTC_2cd02.dir\Debug\testCCompiler.c.obj
[2/2] Linking C executable Debug\cmTC_2cd02.exe
FAILED: Debug/cmTC_2cd02.exe
cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_2cd02.dir\Debug --rc=rc --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100220~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1434~1.319\bin\Hostx64\x64\link.exe /nologo CMakeFiles\cmTC_2cd02.dir\Debug\testCCompiler.c.obj  /out:Debug\cmTC_2cd02.exe /implib:Debug\cmTC_2cd02.lib /pdb:Debug\cmTC_2cd02.pdb /version:0.0 /machine:x64  /debug /INCREMENTAL /subsystem:console -LIBPATH:C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1434~1.319\lib\x64   -LIBPATH:C:\PROGRA~2\WI3CF2~1\NETFXSDK\4.8\lib\um\x64   -LIBPATH:C:\PROGRA~2\WI3CF2~1\10\lib\100220~1.0\ucrt\x64   -LIBPATH:C:\PROGRA~2\WI3CF2~1\10\lib\100220~1.0\um\x64   -LIBPATH:C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1434~1.319\lib\x86\store\REFERE~1   -LIBPATH:C:\PROGRA~2\WI3CF2~1\10\UNIONM~1\100220~1.0   -LIBPATH:C:\PROGRA~2\WI3CF2~1\10\REFERE~1\100220~1.0   -LIBPATH:C:\Windows\Microsoft.NET\Framework64\v4.0.30319 kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cmd.exe /C "cd /D C:\VulkanTools\Daxa\build\cl-x86_64-windows-msvc\CMakeFiles\CMakeScratch\TryCompile-xs9yil && C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy Bypass -file C:/dev/utils/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary C:/VulkanTools/Daxa/build/cl-x86_64-windows-msvc/CMakeFiles/CMakeScratch/TryCompile-xs9yil/Debug/cmTC_2cd02.exe -installedDir C:/dev/utils/vcpkg/installed/x64-windows/debug/bin -OutVariable out""
'cmd.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.

Improve Multisampling

Currently the only multisampling options are the sample count, no dynamic state or anything else. Multisampling is also largely untested.

  • add optinal dynamic multisampling
  • add test
  • investigate other ms options
  • investigate resolve

API Consistency

Daxa has inconsistencies within itself.
But it is also inconsistent witth vulkan and glsl naming.
This causes confusion for new and even old users.
To improve this I propose changes to align daxas naming more to vulkan and glsl/hlsl.

Task Graph issue thread

  • Task graph should be able to create reinterpret views for an image (create a R32_UINT view for R32_SFLOAT for example)
  • Task graph should have an option to keep images in general layout
  • Adding Tasks should return a token. The user should be able to manually create dependencies between tasks using tokens.
  • Make it harder to missuse persistent task resources. User should not have option to change underlying resource while task graph using that resource is running.

Make cleaner buffer pointer type

A BufferPtr(StructType) would be much simpler and clearer to use.
Differences of BufferPtr to current Buffer:
all buffer reference blocks contain a sinlge struct, the thing they point to internally.
This only member is called value.
There is a makro called deref(ptr) to access the pointee. Alternatively .value can be used to access the pointee.

Not that there is always a struct backing up the buffer ptr, things likt assigning or loading the whole pointee type is always possible.
Dereferencing is also much more explicit wich aids readability.

struct MyStruct
{
  uint i;
};
DAXA_ENABLE_BUFFER_STRUCT_PTR(MyStruct);

void fn()
{
  daxa_BufferPtr(MyStruct) ptr = ...;
  ptr = other_ptr;
  deref(ptr).i++;
  deref(ptr).i += 2;
  uint i = deref(ptr);
  MyStruct thing;
  deref(ptr) = thing;
  MyThing another_thing = deref(ptr); 
}

advantages over old:

  • no weird buffer block types anymore that can confuse the user
  • cleaner struct definitions
  • clearer, less confusing to read
    old:
DAXA_DECL_BUFFER_STRUCT(
  MyThing,
  {
    uint i;
  }
)

void fn()
{
  daxa_RWBuffer(MyStruct) buf = ...;
  buf = other_ptr;
  buf.i++;
  buf.i += 2;
  uint i = buf.i;
  MyStruct thing;
  // buf = thing; ?                 NOT POSSIBLE
  // MyThing another_thing = buf; ? NOT POSSIBLE
}

Daxa on MacOS

We would like to support Daxa on as many platforms as possible, but it is by no means our main priority. Daxa will not downgrade its API due to the lack of support for any features on lesser platforms. Some work has been done regarding MacOS support, though there are some big issues that prevent Daxa from working completely on MacOS.

Currently, the following lack of consideration for bindless through updating bound descriptor sets makes bindless unusable for now. This should be a pretty trivial fix within MoltenVK since Metal should support bindless fully.
(2023 m2 Mac mini)

Also, Daxa requires Vulkan 1.3 support - and MoltenVK isn't there yet. Sync2 is the most relevant one for Daxa.

Just as a note, 64 bit integer atomics look like they may never be supported in Metal/MoltenVK... this is really sad.

Device lost error after increasing primitive count building acceleration structures

So this is the code from .\Daxa\tests\2_daxa_api\10_raytracing where if triangle_count upto 14 its fine. But when I reach 15 Vulkan explodes whit device lost error:

std::vector<daxa_f32vec3> vertices;
const int triangle_count = 15;
for(int i = 0; i < triangle_count*3; ++i) {
    vertices.push_back({random_float(-1.0f, 1.0f), random_float(-1.0f, 1.0f), random_float(-1.0f, 1.0f)});
    vertices.push_back({random_float(-1.0f, 1.0f), random_float(-1.0f, 1.0f), random_float(-1.0f, 1.0f)});
    vertices.push_back({random_float(-1.0f, 1.0f), random_float(-1.0f, 1.0f), random_float(-1.0f, 1.0f)});
}
auto vertex_buffer = device.create_buffer({
    .size = sizeof(daxa_f32vec3) * vertices.size(),
    .allocate_info = daxa::MemoryFlagBits::HOST_ACCESS_RANDOM,
    .name = "vertex buffer",
});
defer { device.destroy_buffer(vertex_buffer); };
// *device.get_host_address_as<decltype(vertices)>(vertex_buffer).value() = vertices;
std::memcpy(device.get_host_address_as<daxa_f32vec3>(vertex_buffer).value(), vertices.data(), sizeof(daxa_f32vec3) * vertices.size());

/// Indices:
std::vector<daxa_u32> indices;
for(daxa_u32 i = 0; i < triangle_count*3; ++i) {
    indices.push_back(i);
}
auto index_buffer = device.create_buffer({
    .size = sizeof(daxa_u32) * indices.size(),
    .allocate_info = daxa::MemoryFlagBits::HOST_ACCESS_RANDOM,
    .name = "index buffer",
});
defer { device.destroy_buffer(index_buffer); };
// *device.get_host_address_as<decltype(indices)>(index_buffer).value() = indices;
std::memcpy(device.get_host_address_as<daxa_u32>(index_buffer).value(), indices.data(), sizeof(daxa_u32) * indices.size());
/// Transforms:
auto transform_buffer = device.create_buffer({
    .size = sizeof(daxa_f32mat3x4),
    .allocate_info = daxa::MemoryFlagBits::HOST_ACCESS_RANDOM,
    .name = "transform buffer",
});
defer { device.destroy_buffer(transform_buffer); };
*device.get_host_address_as<daxa_f32mat3x4>(transform_buffer).value() = daxa_f32mat3x4{
    {1, 0, 0, 0},
    {0, 1, 0, 0},
    {0, 0, 1, 0},
};
/// Triangle Geometry Info:
auto geometries = std::array{
    daxa::BlasTriangleGeometryInfo{
        .vertex_format = daxa::Format::R32G32B32_SFLOAT, // Is also default
        .vertex_data = {},                               // Ignored in get_acceleration_structure_build_sizes.    // Is also default
        .vertex_stride = sizeof(daxa_f32vec3),           // Is also default
        .max_vertex = static_cast<u32>(vertices.size() - 1),
        .index_type = daxa::IndexType::uint32, // Is also default
        .index_data = {},                      // Ignored in get_acceleration_structure_build_sizes. // Is also default
        .transform_data = {},                  // Ignored in get_acceleration_structure_build_sizes. // Is also default
        .count = triangle_count,
        .flags = daxa::GeometryFlagBits::OPAQUE, // Is also default
    }};

In case it could be some synchronization relationship I tried to add a sleep before the build command buffer:

using namespace std::chrono_literals;
std::this_thread::sleep_for(2000ms);

/// Record build commands:
auto exec_cmds = [&]()
{
    auto recorder = device.create_command_recorder({});
    recorder.build_acceleration_structures({
        .blas_build_infos = std::array{blas_build_info, proc_blas_build_info},
    });
    recorder.pipeline_barrier({
        .src_access = daxa::AccessConsts::ACCELERATION_STRUCTURE_BUILD_WRITE,
        .dst_access = daxa::AccessConsts::ACCELERATION_STRUCTURE_BUILD_READ_WRITE,
    });
    recorder.build_acceleration_structures({
        .tlas_build_infos = std::array{tlas_build_info},
    });
    recorder.pipeline_barrier({
        .src_access = daxa::AccessConsts::ACCELERATION_STRUCTURE_BUILD_WRITE,
        .dst_access = daxa::AccessConsts::READ_WRITE,
    });
    return recorder.complete_current_commands();
}();
device.submit_commands({.command_lists = std::array{exec_cmds}});

but it doesn't matter. What it seems to matter is the amount of triangles.

I am not sure if I am doing something wrong here or there's some bug inside.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.