Giter Club home page Giter Club logo

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

daxa's Issues

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.

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;
}

debug shaders

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

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

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

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.

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
}

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

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

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

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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

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.

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

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

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.

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.

Remove C api

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

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

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.

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.

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.

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.

Internal naming change

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

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

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.