From 40f49d0ce4889cf47c83fdfe41be4a10cba57e85 Mon Sep 17 00:00:00 2001 From: Fabian F <78906517+FabulousCodingFox@users.noreply.github.com> Date: Thu, 22 Feb 2024 21:14:06 +0100 Subject: [PATCH] Fixed more spacing issues --- docs/Bindless.md | 2 +- docs/Device.md | 2 +- docs/PipelineManager.md | 7 +++++-- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/Bindless.md b/docs/Bindless.md index 34e3315..44ab9c3 100644 --- a/docs/Bindless.md +++ b/docs/Bindless.md @@ -11,4 +11,4 @@ Daxa's bindless approach eliminates these limitations by allowing shaders to acc 1. Improved performance: With bindless resources, shaders can access resources more efficiently, reducing the overhead associated with frequent binding and unbinding operations. 2. Simpler code: No management of descriptor pools, set-layouts, set-allocation, set-writes, set-binding points, or sync on set-allocations. 3. Flexibility: Bindless resources make working with dynamic and large datasets easier, as shaders can access any resource resources by handle. -4. Less error-prone: Compared to typical Vulkan and Dx12 descriptor management systems, Daxa's bindless has such a small API surface that misuse and errors are less likely. +4. Less error-prone: Compared to typical Vulkan and Dx12 descriptor management systems, Daxa's bindless has such a small API surface that misuse and errors are less likely. diff --git a/docs/Device.md b/docs/Device.md index e560894..ee99bd3 100644 --- a/docs/Device.md +++ b/docs/Device.md @@ -42,7 +42,7 @@ device.submit_commands({ .wait_binary_semaphores = std::array{sema}, .signal_timeline_semaphores = std::array{std::pair{tsema, tsema_value}}, }); -``` +``` This generally reduces boilerplate and conveniently merges the VkDevice and VkQeueue concepts. diff --git a/docs/PipelineManager.md b/docs/PipelineManager.md index a06f6be..ec023fa 100644 --- a/docs/PipelineManager.md +++ b/docs/PipelineManager.md @@ -71,11 +71,12 @@ PipelineManager is the container of all these pipelines, so we only give the use > Note: This design decision is mainly due to pipeline manager being a utility designed around developing your application, not for shipping it! #### Hot Reloading + The most significant feature of PipelineManager is the hot-reloading. When the shader code is changed and saved, it will recompile the pipeline. You can even `#include` headers in your shaders, and when the code in those files is updated, the PipelineManager will automatically recompile the affected pipelines for you. To use hot-reloading, we could demonstrate this by adding a `#include` to our `ShaderCode` string. Instead, to show them more directly, we will use real or virtual files. We'll review both in this document, but let's start with the actual files. We'll create a simple Daxa project structured like so: -``` +```text my_daxa_project/ |- src/ | |- main.cpp @@ -83,6 +84,7 @@ my_daxa_project/ |- CMakeLists.txt | ... ``` + > Note: We'll also be using the `my_daxa_project/` directory as the CWD when launching the application. This is important since all relative paths will be relative to the CWD. To be extra clear, with this CWD, we can address the CMakeLists.txt file by saying `./CMakeLists.txt`. Now, to use `main.glsl` as our shader source file, we need to give its path to the `ShaderCompileInfo` when adding a new pipeline, so we'll do that instead. Since we want to use a relative path, we'll say `.source = daxa::ShaderFile{"src/main.glsl"}`. If we didn't specify the full relative path, then our error check from earlier would print the following: @@ -146,6 +148,7 @@ Now is a good time to mention the Daxa shader files, which you can and should #i ``` Once we have this root path, we can change our `main.glsl` file like this! + ```cpp #include @@ -205,4 +208,4 @@ auto compilation_result = pipeline_manager.add_compute_pipeline({ .shader_info = {.source = daxa::ShaderFile{"my_file"}}, .name = APPNAME_PREFIX("compute_pipeline"), }); -``` \ No newline at end of file +```