griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
fe213f80a4b33bf208c403e13bb88078ca2286fa
test2/source/blender/gpu/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

931 lines
30 KiB
CMake
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-16 00:20:26 +10:00
# SPDX-FileCopyrightText: 2006 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
#
File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-11 09:07:11 +11:00
# SPDX-License-Identifier: GPL-2.0-or-later
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
warning fixes and minor cmake changes.
2010-09-18 03:55:56 +00:00
set(INC
Cleanup: CMake: Modernize bf_gpu dependencies Pretty straightforward - Remove any bf_gpu paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132286
2024-12-23 21:38:19 +01:00
PUBLIC .
GPU: Add Dummy Backend For Unsupported Platforms With the introduction of metal and vulkan we use a different GPU backend selection which broke the dialog box for unsupported platforms. Blender asserted and segfaulted before the dialog was being shown to the user. This patch solves this by introducing a dummy GPU backend in case no GPU backend was supported by OpenGL, Metal and Vulkan Backend. It also adds the showMessageBox to GHOST_SystemCocoa. Related to #110335 Pull Request: https://projects.blender.org/blender/blender/pulls/110919
2023-08-15 14:15:12 +02:00
dummy
Cleanup: sort cmake file lists
2023-08-24 11:38:41 +10:00
intern
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
metal
Cleanup: sort cmake file lists
2022-03-25 12:04:14 +11:00
opengl
Cleanup: sort cmake file lists
2022-12-17 16:00:40 +11:00
vulkan
Revert: 0dc484f9cce6f bf_rna modernisation This caused build errors on the docs builder, I can't seem to reproduce locally, so revert for now and have another look at some point in the future. Sadly as these changes usually go, this took 5c515e26bbc47 and 2f0fc7fc9f5df9 with it as well. Pull Request: https://projects.blender.org/blender/blender/pulls/132559
2025-01-02 19:56:24 +01:00
../makesrna
pep8 edits and avoid naming conflicts with python builtins
2011-11-24 19:36:12 +00:00
Cleanup: remove redundant GPU headers
2022-06-22 14:59:42 +10:00
# For theme color access.
gawain/immediate mode: new util functions for color uniforms
2016-10-12 23:01:59 +00:00
../editors/include
Cleanup: spelling in comments
2024-09-20 13:14:57 +10:00
# For `*_info.hh` includes.
Cleanup: move compositor files out of realtime_compositor folder By now it is just a "compositor", so move the files one folder up. Things that were under realtime_compositor/intern move into already existing intern folder. Pull Request: https://projects.blender.org/blender/blender/pulls/132004
2024-12-17 10:34:24 +01:00
../compositor/shaders/infos
EEVEE: Remove EEVEE Next mention inside the code This only changes file and function names. The EEVEE identifier is still `BLENDER_EEVEE_NEXT`. No functional changes.
2025-03-17 15:35:01 +01:00
../draw/engines/eevee
../draw/engines/eevee/shaders/infos
GPencil 3.0: Initial commit Adds the initial stage for the grease pencil 3.0 project. This patch includes: * New ID and new object type. * New DNA structures. * New drawing engine for grease pencil (gpencil-next). * Tests for the new grease pencil data-type. * A few operators for conversion, switching modes and (simple) drawing. Exposed to the user: * An experimental option to switch to the new grease pencil. * This will switch the grease pencil render engine to gpencil-next which can only render the new object type. Current grease pencil objects will no longer render. * Changing this option currently requires a restart of blender (for the keymap to update). * A conversion setting in the `Object` > `Convert To` operator. * A drawing operator in `Draw Mode`. Pull Request: https://projects.blender.org/blender/blender/pulls/106848
2023-05-30 11:14:16 +02:00
../draw/engines/gpencil
GPU: Make create info list not runtime generated This avoid cmake shenanigans to try to make proper dependency tracking. The previous code was not tracking changes inside the create info files. There is no real benefit for having these headers listed in the cmakefile itself. Pull Request: https://projects.blender.org/blender/blender/pulls/129027
2024-10-15 16:31:37 +02:00
../draw/engines/gpencil/shaders/infos
../draw/engines/image/shaders/infos
../draw/engines/overlay/shaders/infos
Overlay-Next: Initial implementation This contains the basis of the new overlay engine. Only a few overlays are ported for proof of concept of the new design. This new design unifies the selection drawing with the overlay-next engine. It now becomes responsible of selection in object mode. For this we create a dedicated shader module that patches the shaders for selection. Note that the gizmo selection still uses the occlusion queries and edit-mode the current selection engine (select_engine.c). Related task #102179 Related task #102177 Co-authored-by: Clément Foucault <foucault.clem@gmail.com> Pull Request: https://projects.blender.org/blender/blender/pulls/107734
2023-05-23 15:00:38 +02:00
../draw/engines/select
GPU: Make create info list not runtime generated This avoid cmake shenanigans to try to make proper dependency tracking. The previous code was not tracking changes inside the create info files. There is no real benefit for having these headers listed in the cmakefile itself. Pull Request: https://projects.blender.org/blender/blender/pulls/129027
2024-10-15 16:31:37 +02:00
../draw/engines/select/shaders/infos
Workbench Next Rewrite of the Workbench engine using C++ and the new Draw Manager API. The new engine can be enabled in Blender `Preferences > Experimental > Workbench Next`. After that, the engine can be selected in `Properties > Scene > Render Engine`. When `Workbench Next` is the active engine, it also handles the `Solid` viewport mode rendering. The rewrite aims to be functionally equivalent to the current Workbench engine, but it also includes some small fixes/tweaks: - `In Front` rendered objects now work correctly with DoF and Shadows. - The `Sampling > Viewport` setting is actually used when the viewport is in `Render Mode`. - In `Texture` mode, textured materials also use the material properties. (Previously, only non textured materials would) To do: - Sculpt PBVH. - Volume rendering. - Hair rendering. - Use the "no_geom" shader versions for shadow rendering. - Decide the final API for custom visibility culling (Needed for shadows). - Profile/optimize. Known Issues: - Matcaps are not loaded until they’re shown elsewhere. (e.g. when opening the `Viewort Shading` UI) - Outlines are drawn between different materials of the same object. (Each material submesh has its own object handle) Reviewed By: fclem Maniphest Tasks: T101619 Differential Revision: https://developer.blender.org/D16826
2023-01-23 17:59:07 +01:00
../draw/engines/workbench
GPU: Make create info list not runtime generated This avoid cmake shenanigans to try to make proper dependency tracking. The previous code was not tracking changes inside the create info files. There is no real benefit for having these headers listed in the cmakefile itself. Pull Request: https://projects.blender.org/blender/blender/pulls/129027
2024-10-15 16:31:37 +02:00
../draw/engines/workbench/shaders/infos
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
../draw/intern
GPU: Make create info list not runtime generated This avoid cmake shenanigans to try to make proper dependency tracking. The previous code was not tracking changes inside the create info files. There is no real benefit for having these headers listed in the cmakefile itself. Pull Request: https://projects.blender.org/blender/blender/pulls/129027
2024-10-15 16:31:37 +02:00
../draw/intern/shaders
metal/kernels
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
vulkan/shaders
GPU: Make create info list not runtime generated This avoid cmake shenanigans to try to make proper dependency tracking. The previous code was not tracking changes inside the create info files. There is no real benefit for having these headers listed in the cmakefile itself. Pull Request: https://projects.blender.org/blender/blender/pulls/129027
2024-10-15 16:31:37 +02:00
shaders/infos
EEVEE-Next: Add Film and RenderBuffers module This modules handles renderpasses allocation and filling. Also handles blitting to viewport framebuffer and render result reading. Changes against the old implementation: - the filling of the renderpasses happens all at once requiring only 1 geometry pass. - The filtering is optimized with weights precomputed on CPU and reuse of neighboor pixels. - Only one accumulation buffer for renderpasses (no ping-pong). - Accumulation happens in one pass for every passes using a single dispatch or fullscreen triangle pass. TAA and history reprojection is not yet implemented. AOVs support is present but with a 16 AOV limit for now. Cryptomatte is not yet implemented.
2022-06-28 18:33:25 +02:00
pep8 edits and avoid naming conflicts with python builtins
2011-11-24 19:36:12 +00:00
GPU: Change GLSL include directive This changes the include directive to use the standard C preprocessor `#include` directive. The regex to applied to all glsl sources is: `pragma BLENDER_REQUIRE\((\w+\.glsl)\)` `include "$1"` This allow C++ linter to parse the code and allow easier codebase traversal. However there is a small catch. While it does work like a standard include directive when the code is treated as C++, it doesn't when compiled by our shader backends. In this case, we still use our dependency concatenation approach instead of file injection. This means that included files will always be prepended when compiled to GLSL and a file cannot be appended more than once. This is why all GLSL lib file should have the `#pragma once` directive and always be included at the start of the file. These requirements are actually already enforced by our code-style in practice. On the implementation, the source needed to be mutated to comment the `#pragma once` and `#include`. This is needed to avoid GLSL compiler error out as this is an extension that not all vendor supports. Rel #127983 Pull Request: https://projects.blender.org/blender/blender/pulls/128076
2024-10-04 15:48:22 +02:00
# For shader includes
shaders/common
shaders
GPU: Move ghost default framebuffer getter to context creation
2020-08-06 04:30:38 +02:00
../../../intern/ghost
Mantaflow [Part 6]: Updates in /blender/source A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming. Reviewed By: sergey Maniphest Tasks: T59995 Differential Revision: https://developer.blender.org/D3855
2019-12-16 15:50:14 +01:00
../../../intern/mantaflow/extern
SubDiv: Use shader create info for patch evaluation shader This PR migrates the subdiv_patch_evaluation_comp.glsl to use shader create info. The part of OSD that is used is included as a typedef source (osd_patch_basis.glsl). Pull Request: https://projects.blender.org/blender/blender/pulls/134917
2025-02-27 15:42:08 +01:00
../../../intern/opensubdiv
cmake maintenance blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python). also only build wm_apple.c on apple+carbon configuration.
2011-05-31 01:15:44 +00:00
)
Vulkan: Disk cache for static pipelines This PR introduces disk cache for static pipelines. The pipelines are stored in `<cache folder>/vk-pipeline-caches/static-shaders.bin`. Due to limitations in some drivers we add a custom header to the cache file to identify if the cache file was created by the same driver for the same GPU for the same Blender. Reading/writing the cache is skipped when running blender with `--debug-gpu` as that would generate different shader modules. For now that isn't a problem, but the final implementation would check before compiling a shader if a certain key is in the pipeline cache if that is the case the compilation step is skipped and the cached shader module is used. Reference: #126229 Pull Request: https://projects.blender.org/blender/blender/pulls/127110
2024-09-05 13:02:40 +02:00
if(WITH_BUILDINFO)
add_definitions(-DWITH_BUILDINFO)
endif()
GPU: Renderdoc Frame Capturing This PR uses renderdoc for frame capturing when enabled. It enabled an easier workflow for frame capturing. - Capture GPU API calls from test cases - Capture GPU API calls from background threads - Capture GPU API calls from background rendering. Renderdoc is an important GPU debugger used by the Eevee/ Viewport module. Previously we needed to change code in order to record background rendering, that could on its own lead to other side-effects. The integration with renderdoc can be enabled using `WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin` and `GPU_debug_capture_end` can be added to the section of the code you want to debug. When running Blender inside renderdoc this part will automatically be captured. All GPU test cases are now guarded by these calls. In order to capture the test cases you need to start the test cases from renderdoc and the captured GPU API calls will appear where each capture is a single test case. Pull Request: https://projects.blender.org/blender/blender/pulls/105921
2023-03-23 16:37:52 +01:00
if(WITH_RENDERDOC)
list(APPEND INC
../../../extern/renderdoc/include
../../../intern/renderdoc_dynload/include
)
add_definitions(-DWITH_RENDERDOC)
endif()
GPU: Add support for shader assert This allows to use `assert()` directly inside shader source. The current implementation is just replacing it with a printf that gives some information about the location of the assert. It is not that much more helpful than a printf with a condition. What is useful is that they are disabled by default. So they can be sprinkle around and only turned on during debugging. Adding shader name inside the assert report is not trivial and could be added later (the shader name is only known at compile time which is too late for string parsing). Adding which drawcall produced the assert isn't trivial either. It would require flushing the printf buffer for each drawcall which might force synchronization and remove bugs. Pull Request: https://projects.blender.org/blender/blender/pulls/129728
2024-11-06 20:29:01 +01:00
if(WITH_GPU_SHADER_ASSERT)
add_definitions(-DWITH_GPU_SHADER_ASSERT)
endif()
cmake maintenance blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python). also only build wm_apple.c on apple+carbon configuration.
2011-05-31 01:15:44 +00:00
set(INC_SYS
warning fixes and minor cmake changes.
2010-09-18 03:55:56 +00:00
)
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
use explicit file paths for CMake rather then globing, This is recommended by cmake devs. globbing vs explicit is discussed here. http://www.cmake.org/pipermail/cmake/2008-December/025694.html Practical implications are: - developers need to keep CMakeLists.txt files up to date. - Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
2010-10-23 04:05:55 +00:00
set(SRC
GPU: Move gpu_batch.c to C++
2020-07-25 18:29:41 +02:00
intern/gpu_batch.cc
DRW/GPU: move .c files to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110509
2023-07-27 14:16:58 +02:00
intern/gpu_batch_presets.cc
intern/gpu_batch_utils.cc
GPU: Rename gpu_extensions to gpu_capabilities This makes more sense as this module has more to it than just GL extensions.
2020-09-07 19:35:56 +02:00
intern/gpu_capabilities.cc
GPU: Make nodetree GLSL Codegen render engine agnostic This commit removes all EEVEE specific code from the `gpu_shader_material*.glsl` files. It defines a clear interface to evaluate the closure nodes leaving more flexibility to the render engine. Some of the long standing workaround are fixed: - bump mapping support is no longer duplicating a lot of node and is instead compiled into a function call. - bump rewiring to Normal socket is no longer needed as we now use a global `g_data.N` for that. Closure sampling with upstread weight eval is now supported if the engine needs it. This also makes all the material GLSL sources use `GPUSource` for better debugging experience. The `GPUFunction` parsing now happens in `GPUSource` creation. The whole `GPUCodegen` now uses the `ShaderCreateInfo` and is object type agnostic. Is has also been rewritten in C++. This patch changes a view behavior for EEVEE: - Mix shader node factor imput is now clamped. - Tangent Vector displacement behavior is now matching cycles. - The chosen BSDF used for SSR might change. - Hair shading may have very small changes on very large hairs when using hair polygon stripes. - ShaderToRGB node will remove any SSR and SSS form a shader. - SSS radius input now is no longer a scaling factor but defines an average radius. The SSS kernel "shape" (radii) are still defined by the socket default values. Appart from the listed changes no other regressions are expected.
2022-04-14 18:47:58 +02:00
intern/gpu_codegen.cc
GPU: Compute Pipeline. With the compute pipeline calculation can be offloaded to the GPU. This patch only adds the framework for compute. So no changes for users at this moment. NOTE: As this is an OpenGL4.3 feature it must always have a fallback. Use `GPU_compute_shader_support` to check if compute pipeline can be used. Check `gpu_shader_compute*` test cases for usage. This patch also adds support for shader storage buffer objects and device only vertex/index buffers. An alternative that had been discussed was adding this to the `GPUBatch`, this was eventually not chosen as it would lead to more code when used as part of a shading group. The idea is that we add an `eDRWCommandType` in the near future. Reviewed By: fclem Differential Revision: https://developer.blender.org/D10913
2021-05-26 16:49:17 +02:00
intern/gpu_compute.cc
GPU: Rename gpu_context.cpp to .cc suffix
2020-07-25 18:30:13 +02:00
intern/gpu_context.cc
GPU: Add debug groups Debug groups makes it easier to view from where an error comes from. The backend can also implement its own callback to make it easier to follow the API call structure in frame debuggers.
2020-09-14 17:07:37 +02:00
intern/gpu_debug.cc
GPU: Move gpu_framebuffer.c to C++
2020-07-25 18:40:19 +02:00
intern/gpu_framebuffer.cc
GPU: Move gpu_immediate.c to C++
2020-07-25 18:40:54 +02:00
intern/gpu_immediate.cc
DRW/GPU: move .c files to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110509
2023-07-27 14:16:58 +02:00
intern/gpu_immediate_util.cc
Cleanup: GPU: Rename GPU_element to GPU_index_buffer Makes it follow the functions names.
2020-09-05 20:15:56 +02:00
intern/gpu_index_buffer.cc
DRW/GPU: move .c files to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110509
2023-07-27 14:16:58 +02:00
intern/gpu_init_exit.cc
intern/gpu_material.cc
GPU: Convert gpu_matrix.c to C++
2020-07-30 23:50:43 +02:00
intern/gpu_matrix.cc
Cleanup: move some files that use nodes to C++
2022-11-18 11:08:39 +01:00
intern/gpu_node_graph.cc
Refactor: GPU: GPUMaterial & GPUPass compilation Cleanup and simplification of GPUMaterial and GPUPass compilation. See #133674 for details/goals. - Remove the `draw_manage_shader` thread. Deferred compilation is now handled by the gpu::ShaderCompiler through the batch compilation API. Batch management is handled by the `GPUPassCache`. - Simplify `GPUMaterial` status tracking so it just queries the `GPUPass` status. - Split the `GPUPass` and the `GPUCodegen` code. - Replaced the (broken) `GPU_material_recalc_flag_get` with the new `GPU_pass_compilation_timestamp`. - Add the `GPU_pass_cache_wait_for_all` and `GPU_shader_batch_wait_for_all`, and remove the busy waits from EEVEE. - Remove many unused functions, properties, includes... Pull Request: https://projects.blender.org/blender/blender/pulls/135637
2025-05-22 17:53:22 +02:00
intern/gpu_pass.cc
GPU: Move gpu_platform.c to C++
2020-07-25 18:41:55 +02:00
intern/gpu_platform.cc
GPUQuery: GL Backend isolation This is part of the Vulkan task T68990. This introduce a new GLQueryPool for managing queries in an implementation agnostic manner. This modify the GPU selection query to use this new object. This also make use of blender::Vector for better code quality. No real functionnal change.
2020-09-07 23:52:55 +02:00
intern/gpu_query.cc
DRW/GPU: move .c files to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110509
2023-07-27 14:16:58 +02:00
intern/gpu_select.cc
Overlay-Next: Initial implementation This contains the basis of the new overlay engine. Only a few overlays are ported for proof of concept of the new design. This new design unifies the selection drawing with the overlay-next engine. It now becomes responsible of selection in object mode. For this we create a dedicated shader module that patches the shaders for selection. Note that the gizmo selection still uses the occlusion queries and edit-mode the current selection engine (select_engine.c). Related task #102179 Related task #102177 Co-authored-by: Clément Foucault <foucault.clem@gmail.com> Pull Request: https://projects.blender.org/blender/blender/pulls/107734
2023-05-23 15:00:38 +02:00
intern/gpu_select_next.cc
DRW/GPU: move .c files to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110509
2023-07-27 14:16:58 +02:00
intern/gpu_select_pick.cc
GPUQuery: GL Backend isolation This is part of the Vulkan task T68990. This introduce a new GLQueryPool for managing queries in an implementation agnostic manner. This modify the GPU selection query to use this new object. This also make use of blender::Vector for better code quality. No real functionnal change.
2020-09-07 23:52:55 +02:00
intern/gpu_select_sample_query.cc
GPU: Move gpu_shader.c to C++ We split builtin shader support to its own file to avoid converting code (lack of designated initializer in C++) and to reduce file size.
2020-07-28 20:04:15 +02:00
intern/gpu_shader.cc
GPU: Move gpu_shader_builtin.c to C++ This also removes all unused part of it now that we have converted all shaders to use create infos.
2023-02-12 16:09:23 +01:00
intern/gpu_shader_builtin.cc
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
intern/gpu_shader_create_info.cc
intern/gpu_shader_dependency.cc
GPU: Convert gpu_shader_interface.c to C++
2020-07-30 23:49:13 +02:00
intern/gpu_shader_interface.cc
CMake: add missing headers, sort file lists
2021-07-08 13:20:32 +10:00
intern/gpu_shader_log.cc
GPU: Move gpu_state.c to C++
2020-07-28 19:26:54 +02:00
intern/gpu_state.cc
GPU/GL: Add StorageBuf implementation Almost 1:1 identical to UniformBuf implementation.
2022-02-08 23:17:31 +01:00
intern/gpu_storage_buffer.cc
GPU: Move gpu_texture.c to C++ # Conflicts: # source/blender/gpu/GPU_texture.h
2020-07-29 14:50:20 +02:00
intern/gpu_texture.cc
Cleanup: strip trailing space, sort file lists
2025-02-16 20:42:16 +11:00
intern/gpu_texture_pool.cc
GPUUniformBuf: Rename struct and change API a bit This follows the GPU module naming of other buffers. We pass name to distinguish each GPUUniformBuf in debug mode. Also remove DRW_uniform_buffer interface.
2020-08-20 23:09:37 +02:00
intern/gpu_uniform_buffer.cc
GPU: Move gpu_vertex_buffer.c to C++
2020-07-28 02:15:22 +02:00
intern/gpu_vertex_buffer.cc
GPU: Move gpu_vertex_format.c to C++
2020-07-27 23:56:43 +02:00
intern/gpu_vertex_format.cc
Refactor: DRW: Centralize and clean up packed normals conversion Move the code dealing with converting float3 to GPU normals out of the vertex format header into a separate header. Use a proper C++ namespace and remove duplication by only using the more recently added C++ templated conversions. Most of the diff comes from the removal of the indirect includes from GPU_vertex_format.hh. A lot of files ended up mistakenly depending on that. Pull Request: https://projects.blender.org/blender/blender/pulls/134873
2025-02-24 16:08:30 +01:00
intern/gpu_vertex_format_normals.cc
DRW/GPU: move .c files to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110509
2023-07-27 14:16:58 +02:00
intern/gpu_viewport.cc
GPU: Support deferred compilation in ShaderCompilerGeneric Update the `ShaderCompilerGeneric` to support deferred compilation using the batch compilation API, so we can get rid of `drw_manager_shader`. This approach also allows supporting non-blocking compilation for static shaders. This shouldn't cause any behavior changes at the moment, since batch compilation is not yet used when parallel compilation is disabled. This adds a `GPUWorker` and a `GPUSecondaryContext` as an easy to use wrapper for managing secondary GPU contexts. (Part of #133674) Pull Request: https://projects.blender.org/blender/blender/pulls/136518
2025-04-07 15:26:25 +02:00
intern/gpu_worker.cc
Cleanup: trailing space
2025-04-24 12:44:27 +10:00
Refactor: DRW: Centralize and clean up packed normals conversion Move the code dealing with converting float3 to GPU normals out of the vertex format header into a separate header. Use a proper C++ namespace and remove duplication by only using the more recently added C++ templated conversions. Most of the diff comes from the removal of the indirect includes from GPU_vertex_format.hh. A lot of files ended up mistakenly depending on that. Pull Request: https://projects.blender.org/blender/blender/pulls/134873
2025-02-24 16:08:30 +01:00
GPU_attribute_convert.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_batch.hh
GPU_batch_presets.hh
GPU_batch_utils.hh
GPU_capabilities.hh
GPU_common.hh
GPU_common_types.hh
GPU: Add GPU_shader_batch_create_from_infos This is the first commit of the several required to support subprocess-based parallel compilation on OpenGL. This provides the base API and implementation, and exposes the max subprocesses setting on the UI, but it's not used by any code yet. More information and the rest of the code can be found in #121925. This one includes: - A new `GPU_shader_batch` API that allows requesting the compilation of multiple shaders at once, allowing GPU backed to compile them in parallel and asynchronously without blocking the Blender UI. - A virtual `ShaderCompiler` class that backends can use to add their own implementation. - A `ShaderCompilerGeneric` class that implements synchronous/blocking compilation of batches for backends that don't have their own implementation yet. - A `GLShaderCompiler` that supports parallel compilation using subprocesses. - A new `BLI_subprocess` API, including IPC (required for the `GLShaderCompiler` implementation). - The implementation of the subprocess program in `GPU_compilation_subprocess`. - A new `Max Shader Compilation Subprocesses` option in `Preferences > System > Memory & Limits` to enable parallel shader compilation and the max number of subprocesses to allocate (each subprocess has a relatively high memory footprint). Implementation Overview: There's a single `GLShaderCompiler` shared by all OpenGL contexts. This class stores a pool of up to `GCaps.max_parallel_compilations` subprocesses that can be used for compilation. Each subprocess has a shared memory pool used for sending the shader source code from the main Blender process and for receiving the already compiled shader binary from the subprocess. This is synchronized using a series of shared semaphores. The subprocesses maintain a shader cache on disk inside a `BLENDER_SHADER_CACHE` folder at the OS temporary folder. Shaders that fail to compile are tried to be compiled again locally for proper error reports. Hanged subprocesses are currently detected using a timeout of 30s. Pull Request: https://projects.blender.org/blender/blender/pulls/122232
2024-06-05 18:45:57 +02:00
GPU_compilation_subprocess.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_compute.hh
GPU_context.hh
GPU_debug.hh
Cleanup: add missing headers to source lists
2025-08-21 17:08:54 +10:00
GPU_format.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_framebuffer.hh
GPU_immediate.hh
GPU_immediate_util.hh
GPU_index_buffer.hh
GPU_init_exit.hh
Cleanup: Move GPU_material.h to C++
2024-02-01 10:40:24 -05:00
GPU_material.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_matrix.hh
Refactor: GPU: GPUMaterial & GPUPass compilation Cleanup and simplification of GPUMaterial and GPUPass compilation. See #133674 for details/goals. - Remove the `draw_manage_shader` thread. Deferred compilation is now handled by the gpu::ShaderCompiler through the batch compilation API. Batch management is handled by the `GPUPassCache`. - Simplify `GPUMaterial` status tracking so it just queries the `GPUPass` status. - Split the `GPUPass` and the `GPUCodegen` code. - Replaced the (broken) `GPU_material_recalc_flag_get` with the new `GPU_pass_compilation_timestamp`. - Add the `GPU_pass_cache_wait_for_all` and `GPU_shader_batch_wait_for_all`, and remove the busy waits from EEVEE. - Remove many unused functions, properties, includes... Pull Request: https://projects.blender.org/blender/blender/pulls/135637
2025-05-22 17:53:22 +02:00
GPU_pass.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_platform.hh
CMake: include headers in source lists
2024-07-25 11:24:11 +10:00
GPU_platform_backend_enum.h
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_primitive.hh
Cleanup: Rename GPU_select header to indicate its move to C++ From a prior PR[0] there was a desire to rename this header to more clearly indicate it's C++ now. [0] !112491 Pull Request: https://projects.blender.org/blender/blender/pulls/115631
2023-12-01 03:39:03 +01:00
GPU_select.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_shader.hh
GPU_shader_builtin.hh
GPU_shader_shared.hh
GPU_state.hh
GPU_storage_buffer.hh
GPU_texture.hh
Cleanup: strip trailing space, sort file lists
2025-02-16 20:42:16 +11:00
GPU_texture_pool.hh
Cleanup: Move GPU_uniform_buffer.h to C++
2024-02-11 16:10:00 -05:00
GPU_uniform_buffer.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_vertex_buffer.hh
GPU_vertex_format.hh
GPU_viewport.hh
GPU: Support deferred compilation in ShaderCompilerGeneric Update the `ShaderCompilerGeneric` to support deferred compilation using the batch compilation API, so we can get rid of `drw_manager_shader`. This approach also allows supporting non-blocking compilation for static shaders. This shouldn't cause any behavior changes at the moment, since batch compilation is not yet used when parallel compilation is disabled. This adds a `GPUWorker` and a `GPUSecondaryContext` as an easy to use wrapper for managing secondary GPU contexts. (Part of #133674) Pull Request: https://projects.blender.org/blender/blender/pulls/136518
2025-04-07 15:26:25 +02:00
GPU_worker.hh
Gawain: reorganize source code Put Gawain source code in a subfolder to make the boundary between the library and the rest of Blender clear. Changed Gawain’s license from Apache to Mozilla Public License. Has more essence of copyleft — closer to GPL but not as restrictive. Split immediate.c into several files so parts can be reused (adding more files soon…)
2016-09-13 02:18:33 -04:00
GPUBackend: Add new GPUBackend object to manage GL object allocations This just set a global object responsible for allocating new objects in a thread safe way without needing any GPUContext bound to this thread. This also introduce the GLContext which will contain all the GL related functions for the current context.
2020-08-07 17:00:28 +02:00
intern/gpu_backend.hh
GPU: Rename gpu_extensions to gpu_capabilities This makes more sense as this module has more to it than just GL extensions.
2020-09-07 19:35:56 +02:00
intern/gpu_capabilities_private.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
intern/gpu_codegen.hh
Cleanup: GPU: Change gpu_context_private.h to C++ only header
2020-08-08 03:01:45 +02:00
intern/gpu_context_private.hh
Cleanup: add missing headers to CMake, formatting
2020-09-15 22:50:11 +10:00
intern/gpu_debug_private.hh
GPUFramebuffer: Make GPUFrameBuffer an opaque type This is in preparation of the Framebuffer GL backend. This is a just changing types and moving some code. No logic is changed... almost... it just removes the context attach. i.e: `gpu_context_add/remove_framebuffer()` This is not needed for now and was even disabled in release. This is part of T68990.
2020-08-25 23:27:40 +02:00
intern/gpu_framebuffer_private.hh
GPUImmediate: GL backend isolation This is part of the Vulkan backend task T68990. This is mostly a cleanup, however, there is a small change: We don't use a special Vertex Array binding function for Immediate anymore and just reuse the one for batches. This might create a bit more state changes but this could be fixed easily if it causes perf regression. # Conflicts: # source/blender/gpu/intern/gpu_context.cc
2020-08-31 15:14:47 +02:00
intern/gpu_immediate_private.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
intern/gpu_material_library.hh
intern/gpu_matrix_private.hh
intern/gpu_node_graph.hh
GPUPlatform: GL backend isolation Part of the vulkan implementation T68990. Pretty straight forward. Just move the GL code inside the GLBackend and make the GPUPlatformGlobal a class object.
2020-09-07 15:39:47 +02:00
intern/gpu_platform_private.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
intern/gpu_private.hh
GPU: Add --profile-gpu Add a `--profile-gpu` launch argument. When set, it generates a profile in the Trace Event Format with CPU and GPU metrics based on GPU debug scopes. https://profilerpedia.markhansen.co.nz/formats/trace-event-format/ The profiles are best viewed at https://ui.perfetto.dev/ Notes: - The profiler captures everything form app start to exit. - Being JSON based the profiles can become relatively large, but they compress very well. - Only OpenGL profiling is supported for now, but the report formatting code can be shared across backends. Pull Request: https://projects.blender.org/blender/blender/pulls/133557
2025-02-18 15:36:50 +01:00
intern/gpu_profile_report.hh
GPUQuery: GL Backend isolation This is part of the Vulkan task T68990. This introduce a new GLQueryPool for managing queries in an implementation agnostic manner. This modify the GPU selection query to use this new object. This also make use of blender::Vector for better code quality. No real functionnal change.
2020-09-07 23:52:55 +02:00
intern/gpu_query.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
intern/gpu_select_private.hh
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
intern/gpu_shader_create_info.hh
intern/gpu_shader_create_info_private.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
intern/gpu_shader_dependency_private.hh
GPUShaderInterface: GL backend isolation
2020-08-20 13:05:22 +02:00
intern/gpu_shader_interface.hh
Cleanup: sort struct declarations
2020-09-30 11:51:13 +10:00
intern/gpu_shader_private.hh
GPUState: Add GL backend and state tracking but do not use it This is just the backend work. It is not plugged in yet because it needs more external cleanup/refactor.
2020-08-16 14:01:07 +02:00
intern/gpu_state_private.hh
CMake: add missing headers to source list
2022-03-23 11:58:59 +11:00
intern/gpu_storage_buffer_private.hh
GPUTexture: Add skeleton of the new GLTexture class
2020-09-02 01:25:32 +02:00
intern/gpu_texture_private.hh
GPUUniformBuf: GL backend isolation This is in preparation of vulkan backend. We move all opengl functionnalities behind an abstract class. This also cleansup the "dynamic" ubo create and rename it to `GPU_uniformbuf_from_list()` Contains, no functional change. Part of T68990 Vulkan support.
2020-08-21 12:30:55 +02:00
intern/gpu_uniform_buffer_private.hh
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
intern/gpu_vertex_format_private.hh
GPU: Add Dummy Backend For Unsupported Platforms With the introduction of metal and vulkan we use a different GPU backend selection which broke the dialog box for unsupported platforms. Blender asserted and segfaulted before the dialog was being shown to the user. This patch solves this by introducing a dummy GPU backend in case no GPU backend was supported by OpenGL, Metal and Vulkan Backend. It also adds the showMessageBox to GHOST_SystemCocoa. Related to #110335 Pull Request: https://projects.blender.org/blender/blender/pulls/110919
2023-08-15 14:15:12 +02:00
dummy/dummy_backend.hh
dummy/dummy_batch.hh
dummy/dummy_context.hh
dummy/dummy_framebuffer.hh
dummy/dummy_vertex_buffer.hh
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
)
set(OPENGL_SRC
opengl/gl_backend.cc
opengl/gl_batch.cc
GPU: Add GPU_shader_batch_create_from_infos This is the first commit of the several required to support subprocess-based parallel compilation on OpenGL. This provides the base API and implementation, and exposes the max subprocesses setting on the UI, but it's not used by any code yet. More information and the rest of the code can be found in #121925. This one includes: - A new `GPU_shader_batch` API that allows requesting the compilation of multiple shaders at once, allowing GPU backed to compile them in parallel and asynchronously without blocking the Blender UI. - A virtual `ShaderCompiler` class that backends can use to add their own implementation. - A `ShaderCompilerGeneric` class that implements synchronous/blocking compilation of batches for backends that don't have their own implementation yet. - A `GLShaderCompiler` that supports parallel compilation using subprocesses. - A new `BLI_subprocess` API, including IPC (required for the `GLShaderCompiler` implementation). - The implementation of the subprocess program in `GPU_compilation_subprocess`. - A new `Max Shader Compilation Subprocesses` option in `Preferences > System > Memory & Limits` to enable parallel shader compilation and the max number of subprocesses to allocate (each subprocess has a relatively high memory footprint). Implementation Overview: There's a single `GLShaderCompiler` shared by all OpenGL contexts. This class stores a pool of up to `GCaps.max_parallel_compilations` subprocesses that can be used for compilation. Each subprocess has a shared memory pool used for sending the shader source code from the main Blender process and for receiving the already compiled shader binary from the subprocess. This is synchronized using a series of shared semaphores. The subprocesses maintain a shader cache on disk inside a `BLENDER_SHADER_CACHE` folder at the OS temporary folder. Shaders that fail to compile are tried to be compiled again locally for proper error reports. Hanged subprocesses are currently detected using a timeout of 30s. Pull Request: https://projects.blender.org/blender/blender/pulls/122232
2024-06-05 18:45:57 +02:00
opengl/gl_compilation_subprocess.cc
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
opengl/gl_compute.cc
opengl/gl_context.cc
opengl/gl_debug.cc
opengl/gl_framebuffer.cc
opengl/gl_immediate.cc
opengl/gl_index_buffer.cc
opengl/gl_query.cc
opengl/gl_shader.cc
opengl/gl_shader_interface.cc
opengl/gl_shader_log.cc
opengl/gl_state.cc
opengl/gl_storage_buffer.cc
opengl/gl_texture.cc
opengl/gl_uniform_buffer.cc
opengl/gl_vertex_array.cc
opengl/gl_vertex_buffer.cc
GPUBackend: Add new GPUBackend object to manage GL object allocations This just set a global object responsible for allocating new objects in a thread safe way without needing any GPUContext bound to this thread. This also introduce the GLContext which will contain all the GL related functions for the current context.
2020-08-07 17:00:28 +02:00
opengl/gl_backend.hh
GPUBatch: Move allocator to backend
2020-08-10 11:41:22 +02:00
opengl/gl_batch.hh
GPU: Add GPU_shader_batch_create_from_infos This is the first commit of the several required to support subprocess-based parallel compilation on OpenGL. This provides the base API and implementation, and exposes the max subprocesses setting on the UI, but it's not used by any code yet. More information and the rest of the code can be found in #121925. This one includes: - A new `GPU_shader_batch` API that allows requesting the compilation of multiple shaders at once, allowing GPU backed to compile them in parallel and asynchronously without blocking the Blender UI. - A virtual `ShaderCompiler` class that backends can use to add their own implementation. - A `ShaderCompilerGeneric` class that implements synchronous/blocking compilation of batches for backends that don't have their own implementation yet. - A `GLShaderCompiler` that supports parallel compilation using subprocesses. - A new `BLI_subprocess` API, including IPC (required for the `GLShaderCompiler` implementation). - The implementation of the subprocess program in `GPU_compilation_subprocess`. - A new `Max Shader Compilation Subprocesses` option in `Preferences > System > Memory & Limits` to enable parallel shader compilation and the max number of subprocesses to allocate (each subprocess has a relatively high memory footprint). Implementation Overview: There's a single `GLShaderCompiler` shared by all OpenGL contexts. This class stores a pool of up to `GCaps.max_parallel_compilations` subprocesses that can be used for compilation. Each subprocess has a shared memory pool used for sending the shader source code from the main Blender process and for receiving the already compiled shader binary from the subprocess. This is synchronized using a series of shared semaphores. The subprocesses maintain a shader cache on disk inside a `BLENDER_SHADER_CACHE` folder at the OS temporary folder. Shaders that fail to compile are tried to be compiled again locally for proper error reports. Hanged subprocesses are currently detected using a timeout of 30s. Pull Request: https://projects.blender.org/blender/blender/pulls/122232
2024-06-05 18:45:57 +02:00
opengl/gl_compilation_subprocess.hh
GPU: Compute Pipeline. With the compute pipeline calculation can be offloaded to the GPU. This patch only adds the framework for compute. So no changes for users at this moment. NOTE: As this is an OpenGL4.3 feature it must always have a fallback. Use `GPU_compute_shader_support` to check if compute pipeline can be used. Check `gpu_shader_compute*` test cases for usage. This patch also adds support for shader storage buffer objects and device only vertex/index buffers. An alternative that had been discussed was adding this to the `GPUBatch`, this was eventually not chosen as it would lead to more code when used as part of a shading group. The idea is that we add an `eDRWCommandType` in the near future. Reviewed By: fclem Differential Revision: https://developer.blender.org/D10913
2021-05-26 16:49:17 +02:00
opengl/gl_compute.hh
GPUBackend: Add new GPUBackend object to manage GL object allocations This just set a global object responsible for allocating new objects in a thread safe way without needing any GPUContext bound to this thread. This also introduce the GLContext which will contain all the GL related functions for the current context.
2020-08-07 17:00:28 +02:00
opengl/gl_context.hh
GPUDebug: Reformat GL debug callbacks and move them to GL backend Now the callbacks are setup for each debug context. The formating has been reworked to be less verbose and make errors and warnings stand out from the notifications. Errors are most of the time sufficiently explicit in their message. This also remove the support for AMD_debug_output which is 10 years old. This is related to the Vulkan port T68990.
2020-08-31 22:41:04 +02:00
opengl/gl_debug.hh
GPUFrameBuffer: GL backend isolation This is related to the Vulkan port T68990. This is a full cleanup of the Framebuffer module and a separation of OpenGL related functions. There is some changes with how the default framebuffers are handled. Now the default framebuffers are individually wrapped inside special GLFrameBuffers. This make it easier to keep track of the currently bound framebuffer state and have some specificity for operations on these framebuffers. Another change is dropping the optimisation of only configuring the changed attachements during framebuffers update. This does not give any benefits and add some complexity to the code. This might be brought back if it has a performance impact on some systems. This also adds support for naming framebuffers but it is currently not used.
2020-08-29 01:13:54 +02:00
opengl/gl_framebuffer.hh
GPUImmediate: GL backend isolation This is part of the Vulkan backend task T68990. This is mostly a cleanup, however, there is a small change: We don't use a special Vertex Array binding function for Immediate anymore and just reuse the one for batches. This might create a bit more state changes but this could be fixed easily if it causes perf regression. # Conflicts: # source/blender/gpu/intern/gpu_context.cc
2020-08-31 15:14:47 +02:00
opengl/gl_immediate.hh
GPUIndexBuf: GL backend Isolation This is part of the Vulkan backend task T68990. There is no real change, only making some code re-organisation. This also make the IndexBuf completely abstract from outside the GPU module.
2020-09-06 02:46:51 +02:00
opengl/gl_index_buffer.hh
GPUImmediate: GL backend isolation This is part of the Vulkan backend task T68990. This is mostly a cleanup, however, there is a small change: We don't use a special Vertex Array binding function for Immediate anymore and just reuse the one for batches. This might create a bit more state changes but this could be fixed easily if it causes perf regression. # Conflicts: # source/blender/gpu/intern/gpu_context.cc
2020-08-31 15:14:47 +02:00
opengl/gl_primitive.hh
GPUQuery: GL Backend isolation This is part of the Vulkan task T68990. This introduce a new GLQueryPool for managing queries in an implementation agnostic manner. This modify the GPU selection query to use this new object. This also make use of blender::Vector for better code quality. No real functionnal change.
2020-09-07 23:52:55 +02:00
opengl/gl_query.hh
GPUShader: GL backend isolation
2020-08-14 15:20:35 +02:00
opengl/gl_shader.hh
GPUShaderInterface: GL backend isolation
2020-08-20 13:05:22 +02:00
opengl/gl_shader_interface.hh
GPUState: Add GL backend and state tracking but do not use it This is just the backend work. It is not plugged in yet because it needs more external cleanup/refactor.
2020-08-16 14:01:07 +02:00
opengl/gl_state.hh
CMake: add missing headers to source list
2022-03-23 11:58:59 +11:00
opengl/gl_storage_buffer.hh
GPUFrameBuffer: GL backend isolation This is related to the Vulkan port T68990. This is a full cleanup of the Framebuffer module and a separation of OpenGL related functions. There is some changes with how the default framebuffers are handled. Now the default framebuffers are individually wrapped inside special GLFrameBuffers. This make it easier to keep track of the currently bound framebuffer state and have some specificity for operations on these framebuffers. Another change is dropping the optimisation of only configuring the changed attachements during framebuffers update. This does not give any benefits and add some complexity to the code. This might be brought back if it has a performance impact on some systems. This also adds support for naming framebuffers but it is currently not used.
2020-08-29 01:13:54 +02:00
opengl/gl_texture.hh
GPUUniformBuf: GL backend isolation This is in preparation of vulkan backend. We move all opengl functionnalities behind an abstract class. This also cleansup the "dynamic" ubo create and rename it to `GPU_uniformbuf_from_list()` Contains, no functional change. Part of T68990 Vulkan support.
2020-08-21 12:30:55 +02:00
opengl/gl_uniform_buffer.hh
GPUBatch: GL backend isolation This changes the drawing paradigm a bit. The VAO configuration is done JIT-style and depends on context active shader. This is to allow more flexibility for implementations to do optimization at lower level. The vao cache is now its own class to isolate the concept. It is this class that is reference by the GLContext for ownership of the containing VAO ids.
2020-08-11 01:31:40 +02:00
opengl/gl_vertex_array.hh
GPUVertBuf: Rename GPUVertBuf to VertBuf and add some getters to avoid more typecasts.
2020-09-06 23:45:51 +02:00
opengl/gl_vertex_buffer.hh
use explicit file paths for CMake rather then globing, This is recommended by cmake devs. globbing vs explicit is discussed here. http://www.cmake.org/pipermail/cmake/2008-December/025694.html Practical implications are: - developers need to keep CMakeLists.txt files up to date. - Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
2010-10-23 04:05:55 +00:00
)
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
set(VULKAN_SRC
vulkan/vk_backend.cc
vulkan/vk_batch.cc
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_buffer.cc
vulkan/vk_common.cc
Cleanup: add missing CMake headers & sort file lists
2023-03-01 22:46:04 +11:00
vulkan/vk_context.cc
Vulkan: Texture Data Conversions This PR adds basic support for texture update, read back and clearing for Vulkan. In Vulkan we need to convert each data type ourselves as vulkan buffers are untyped. Therefore this change mostly is about data conversions. Considerations: - Use a compute shader to do the conversions: - Leads to performance regression as compute pipeline can stall graphics pipeline - Lead to additional memory usage as two staging buffers are needed one to hold the CPU data, and one to hold the converted data. - Do inline conversion when sending the data to Vulkan using `eGPUDataFormat` - Additional CPU cycles required and not easy to optimize as it the implementation requires many branches. - Do inline conversion when sending the data to Vulkan (optimized for CPU) For this solution it was chosen to implement the 3rd option as it is fast and doesn't require additional memory what the other options do. **Use Imath/half.h** This patch uses `Imath/half.h` (dependency of OpenEXR) similar to alembic. But this makes vulkan dependent of the availability of OpenEXR. For now this isn't checked, but when we are closer to a working Vulkan backend we have to make a decision how to cope with this dependency. **Missing Features** *Framebuffer textures* This doesn't include all possible data transformations. Some of those transformation can only be tested after the VKFramebuffer has been implemented. Some texture types are only available when created for a framebuffer. These include the depth and stencil variations. *Component format* Is more relevant when implementing VKVertexBuffer. *SRGB textures* SRGB encoded textures aren't natively supported on all platforms, in all usages and might require workarounds. This should be done in a separate PR in a later stage when we are required to use SRGB textures. **Test cases** The added test cases gives an overview of the missing bits and pieces of the patch. When the implementation/direction is accepted more test cases can be enabled/implemented. Some of these test cases will skip depending on the actual support of platform the tests are running on. For example OpenGL/NVidia will skip the next test as it doesn't support the texture format on OpenGL, although it does support it on Vulkan. ``` [ RUN ] GPUOpenGLTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ SKIPPED ] GPUOpenGLTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ RUN ] GPUVulkanTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ OK ] GPUVulkanTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI ``` Pull Request: https://projects.blender.org/blender/blender/pulls/105762
2023-03-24 08:09:19 +01:00
vulkan/vk_data_conversion.cc
GPU: Renderdoc Frame Capturing This PR uses renderdoc for frame capturing when enabled. It enabled an easier workflow for frame capturing. - Capture GPU API calls from test cases - Capture GPU API calls from background threads - Capture GPU API calls from background rendering. Renderdoc is an important GPU debugger used by the Eevee/ Viewport module. Previously we needed to change code in order to record background rendering, that could on its own lead to other side-effects. The integration with renderdoc can be enabled using `WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin` and `GPU_debug_capture_end` can be added to the section of the code you want to debug. When running Blender inside renderdoc this part will automatically be captured. All GPU test cases are now guarded by these calls. In order to capture the test cases you need to start the test cases from renderdoc and the captured GPU API calls will appear where each capture is a single test case. Pull Request: https://projects.blender.org/blender/blender/pulls/105921
2023-03-23 16:37:52 +01:00
vulkan/vk_debug.cc
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_descriptor_pools.cc
vulkan/vk_descriptor_set.cc
Vulkan: Share descriptor set layouts between shaders Previously all shaders had its own descriptor set layout handle. This makes it difficult to see if currently bound resources can be reused when switching shaders. To work around this limitation, the vulkan backend rebound the resources over and over again. This PR is part of the render graph where changing shaders can reuse previous bound resources. This PR only makes sure that the layout handles are the same so we can identify 'compatible' pipelines. The behavior to limit rebinding of resources will be added as part of the render graph in a later commit. Pull Request: https://projects.blender.org/blender/blender/pulls/120562
2024-04-16 14:00:49 +02:00
vulkan/vk_descriptor_set_layouts.cc
Vulkan: Share Device Between Contexts Previous GHOST_ContextVK would create a logical device for each context. Blender uses multiple contexts at the same time and wasn't able to share resources between them as the logical device where different. This patch will create a single logical device and share them between multiple contexts. This allows sharing memory/shaders between contexts and make sure that all memory allocations are freed from the device it was allocated from. Some allocations in Blender are freed when there isn't a context, this was failing in the previous implementation. We didn't noticed it before as we didn't test multiple contexts. This patch also moves device specific data structures from VKContext to VKDevice like the descriptor pools, debug layers etc. Pull Request: https://projects.blender.org/blender/blender/pulls/107606
2023-05-04 10:06:48 +02:00
vulkan/vk_device.cc
CMake: add missing headers, sort file lists
2025-03-21 00:19:55 +00:00
vulkan/vk_device_submission.cc
GPU: Add placeholders for PixelBuffer to vulkan backend. PixelBuffer was recently introduced. This change adds empty placeholders to the vulkan backend and other related API tweaks.
2022-12-02 08:35:17 +01:00
vulkan/vk_fence.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_framebuffer.cc
Vulkan: Image Views The ownership of image views depends on how they are used. When used as an framebuffer attachment the image view is owned by the framebuffer. When used as a image/texture in a shader the ownership of the image view is the texture itself. Pull Request: https://projects.blender.org/blender/blender/pulls/108765
2023-06-08 16:07:38 +02:00
vulkan/vk_image_view.cc
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
vulkan/vk_immediate.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_index_buffer.cc
Cleanup: sort cmake file lists
2023-04-13 13:14:11 +10:00
vulkan/vk_memory_layout.cc
Cleanup: sort file lists
2025-09-12 10:20:40 +10:00
vulkan/vk_memory_pool.cc
Vulkan: Pipeline pool In Vulkan, a Blender shader is organized in multiple objects. A VkPipeline is the highest level concept and represents somewhat we call a shader. A pipeline is an device/platform optimized version of the shader that is uploaded and executed in the GPU device. A key difference with shaders is that its usage is also compiled in. When using the same shader with a different blending, a new pipeline needs to be created. In the current implementation of the Vulkan backend the pipeline is re-created when any pipeline parameter changes. This triggers many pipeline compilations. Especially when common shaders are used in different parts of the drawing code. A requirement of our render graph implementation is that changes of the pipeline can be detected based on the VkPipeline handle. We only want to rebind the pipeline handle when the handle actually changes. This improves performance (especially on NVIDIA) devices where pipeline binds are known to be costly. The solution of this PR is to add a pipeline pool. This holds all pipelines and can find an already created pipeline based on pipeline infos. Only compute pipelines support has been added. # Future enhancements - Recent drivers replace `VkShaderModule` with pipeline libraries. It improves sharing pipeline stages and reduce pipeline creation times. - GPUMaterials should be removed from the pipeline pool when they are destroyed. Details on this will be more clear when EEVEE support is added. Pull Request: https://projects.blender.org/blender/blender/pulls/120899
2024-04-23 12:39:41 +02:00
vulkan/vk_pipeline_pool.cc
GPU: Add placeholders for PixelBuffer to vulkan backend. PixelBuffer was recently introduced. This change adds empty placeholders to the vulkan backend and other related API tweaks.
2022-12-02 08:35:17 +01:00
vulkan/vk_pixel_buffer.cc
Vulkan: Push constants **What are push constants?** Push constants is a way to quickly provide a small amount of uniform data to shaders. It should be much quicker than UBOs but a huge limitation is the size of data - spec requires 128 bytes to be available for a push constant range. **What are the challenges with push constants?** The challenge with push constants is that the limited available size. According to the Vulkan spec each platform should at least have 128 bytes reserved for push constants. Current Mesa/AMD drivers supports 256 bytes, but Mesa/Intel is only 128 bytes. **What is our solution?** Some shaders of Blender uses more than these boundaries. When more data is needed push constants will not be used, but the shader will be patched to use an uniform buffer instead. This mechanism will be part of the Vulkan backend and shader developers should not see any difference on API level. **Known limitations** Current state of the vulkan backend does not track resources that are in the command queue. This patch includes some test cases that identified this issue as well. See #104771. Pull Request #104880
2023-03-06 12:28:55 +01:00
vulkan/vk_push_constants.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_query.cc
Vulkan: Render graph dispatch indirect Add dispatch indirect node. Also refactored the dispatch (direct) node so more logic could be reused. The context only stores a `VKResourceAccessInfo` struct which is reused by both the dispatch and dispatch indirect node. Pull Request: https://projects.blender.org/blender/blender/pulls/120993
2024-04-24 21:28:45 +02:00
vulkan/render_graph/nodes/vk_pipeline_data.cc
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/vk_command_buffer_wrapper.cc
vulkan/render_graph/vk_command_builder.cc
Cleanup: sort cmake file lists
2024-05-06 09:20:57 +10:00
vulkan/render_graph/vk_render_graph.cc
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
vulkan/render_graph/vk_render_graph_links.cc
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/vk_resource_access_info.cc
vulkan/render_graph/vk_resource_state_tracker.cc
vulkan/render_graph/vk_scheduler.cc
Vulkan: Resource Pools This PR implements #126353; In short: keep discard list as part of swap chain images. This allows better determination when resources are actually not in use anymore. ## Resource pool Resource pools keep track of the resources for a swap chain image. In Blender this is a bit more complicated due to the way GPUContext work. A single thread can have multiple contexts. Some of them have a swap chain (GHOST Window) other don't (draw manager). The resource pool should be shared between the contexts running on the same thread. When opening multiple windows there are also multiple swap chains to consider. ### Discard pile Resource handles that are deleted and stored in the discard pile. When we are sure that these resources are not used on the GPU anymore these are destroyed. ### Reusable resources There are other resources as well like: - Descriptor sets - Descriptor pools ## Open issues There are some limitations that require future PRs to fix including: - Background rendering - Handling multiple windows - Improve CPU/GPU synchronization - Reuse staging buffers Pull Request: https://projects.blender.org/blender/blender/pulls/126353
2024-08-19 15:37:48 +02:00
vulkan/vk_resource_pool.cc
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
vulkan/vk_sampler.cc
Vulkan: Implement Samplers Until now the Vulkan backend supported a single pre-configured sampler. This PR realizes creation, caching and freeing of samplers based on what is required by the state manager. The implementation is similar to OpenGL or Metal. This fixes many issues including: - Textures in workbench and eevee use the correct extend and filtering - Custom icons render correctly - Depth sampling issues - Removes artifacts using EEVEE world shader, lighting and indirect lighting. Pull Request: https://projects.blender.org/blender/blender/pulls/114827
2023-11-14 11:12:19 +01:00
vulkan/vk_samplers.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_shader.cc
Vulkan: Parallel shader compilation This PR introduces parallel shader compilation for Vulkan shader modules. This will improve shader compilation when switching to material preview or EEVEE render preview. It also improves material compilation. However in order to measure the differences shaderc needs to be updated. PR has been created so we can already start with the code review. This PR doesn't include SPIR-V caching, what will land in a separate PR as it needs more validation. Parallel shader compilation has been tested on AMD/NVIDIA on Linux. Testing on other platforms is planned in the upcoming days. **Performance** ``` AMD Ryzen™ 9 7950X × 32, 64GB Ram Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02 ``` *Test*: Start blender, open barbershop_interior.blend and wait until the viewport has fully settled. | Backend | Test | Duration | | ------- | ------------------------- | -------- | | OpenGL | Coldstart/No subprocesses | 1:52 | | OpenGL | Coldstart/8 Subprocesses | 0:54 | | OpenGL | Warmstart/8 Subprocesses | 0:06 | | Vulkan | Coldstart Without PR | 0:59 | | Vulkan | Warmstart Without PR | 0:58 | | Vulkan | Coldstart With PR | 0:33 | | Vulkan | Warmstart With PR | 0:08 | The difference in time (why OpenGL is faster in a warm start is that all shaders are cached). Vulkan in this case doesn't cache anything and all shaders are recompiled each time. Caching the shaders will be part of a future PR. Main reason not to add it to this PR directly is that SPIR-V cannot easily be validated and would require a sidecar to keep SPIR-V compatible with external tools.. **NOTE**: - This PR was extracted from #127418 - This PR requires #127564 to land and libraries to update. Linux lib is available as attachment in this PR. It works without, but is as slow as single threaded compilation. Pull Request: https://projects.blender.org/blender/blender/pulls/127698
2024-09-20 08:30:09 +02:00
vulkan/vk_shader_compiler.cc
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_shader_interface.cc
GPU: Compile vulkan shaders to Spir-V binaries. Compile each static shader using shaderc to Spir-V binaries. The main goal is to make sure that the GLSL created using ShaderCreateInfo and able to compile to Spir-V. For the second stage a correct pipeline needs to be created and some shader would need more adjustments (push constants size). With this patch future changes to GLSL sources can already be checked against vulkan, without the backend finished. Mechanism has been tested using MacOS and MoltenVK. For other OS, we should finetune CMake files to find the right location to shaderc. ``` ************************************************************ *** Build Mon 12 Dec 2022 11:08:07 CET ************************************************************ Shader Test compilation result: 463 / 463 passed (skipped 118 for compatibility reasons) OpenGL backend shader compilation succeeded. Shader Test compilation result: 529 / 529 passed (skipped 52 for compatibility reasons) Vulkan backend shader compilation succeeded. ``` Reviewed By: fclem Maniphest Tasks: T102760 Differential Revision: https://developer.blender.org/D16610
2022-12-12 12:22:38 +01:00
vulkan/vk_shader_log.cc
Vulkan: Parallel shader compilation This PR introduces parallel shader compilation for Vulkan shader modules. This will improve shader compilation when switching to material preview or EEVEE render preview. It also improves material compilation. However in order to measure the differences shaderc needs to be updated. PR has been created so we can already start with the code review. This PR doesn't include SPIR-V caching, what will land in a separate PR as it needs more validation. Parallel shader compilation has been tested on AMD/NVIDIA on Linux. Testing on other platforms is planned in the upcoming days. **Performance** ``` AMD Ryzen™ 9 7950X × 32, 64GB Ram Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02 ``` *Test*: Start blender, open barbershop_interior.blend and wait until the viewport has fully settled. | Backend | Test | Duration | | ------- | ------------------------- | -------- | | OpenGL | Coldstart/No subprocesses | 1:52 | | OpenGL | Coldstart/8 Subprocesses | 0:54 | | OpenGL | Warmstart/8 Subprocesses | 0:06 | | Vulkan | Coldstart Without PR | 0:59 | | Vulkan | Warmstart Without PR | 0:58 | | Vulkan | Coldstart With PR | 0:33 | | Vulkan | Warmstart With PR | 0:08 | The difference in time (why OpenGL is faster in a warm start is that all shaders are cached). Vulkan in this case doesn't cache anything and all shaders are recompiled each time. Caching the shaders will be part of a future PR. Main reason not to add it to this PR directly is that SPIR-V cannot easily be validated and would require a sidecar to keep SPIR-V compatible with external tools.. **NOTE**: - This PR was extracted from #127418 - This PR requires #127564 to land and libraries to update. Linux lib is available as attachment in this PR. It works without, but is as slow as single threaded compilation. Pull Request: https://projects.blender.org/blender/blender/pulls/127698
2024-09-20 08:30:09 +02:00
vulkan/vk_shader_module.cc
Vulkan: Store Vertex, Index and Storage Buffers on Device Memory Currently all buffer types were stored in host memory, which is visible to the GPU as well. This is typically slow as the data would be transferred over the PCI bus when used. Most of the time Index and Vertex buffers are written once and read many times so it makes more sense to locate them on the GPU. Storage buffers typically require quick access as they are created for shading/compute purposes. This PR will try to store vertex buffers, index buffers and storage buffers on device memory to improve the performance. Uniform buffers are still located on host memory as they can be uploaded during binding process. This can (will) reset the graphics pipeline triggering draw calls using unattached resources. In future this could be optimized further as in: * using different pools for allocating specific buffers, with a fallback when buffers cannot be stored on the GPU anymore. * store uniform buffers in device memory Pull Request: https://projects.blender.org/blender/blender/pulls/115343
2023-11-24 13:52:48 +01:00
vulkan/vk_staging_buffer.cc
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_state_manager.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_storage_buffer.cc
vulkan/vk_texture.cc
Vulkan: to_string for used vulkan types Every vulkan installation has a vk.xml file containing the vulkan specification in a machine readable fasion. This PR uses the vk.xml to generate to_string functions for data types blender uses. When updating to a new specification or when changing features/extensions we should re-generate the to_string functions. The generator is implemented in `vk_to_string.py`. Pull Request: https://projects.blender.org/blender/blender/pulls/119880
2024-03-26 11:35:16 +01:00
vulkan/vk_to_string.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_uniform_buffer.cc
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
vulkan/vk_vertex_attribute_object.cc
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_vertex_buffer.cc
vulkan/vk_backend.hh
vulkan/vk_batch.hh
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_buffer.hh
vulkan/vk_common.hh
Cleanup: add missing CMake headers & sort file lists
2023-03-01 22:46:04 +11:00
vulkan/vk_context.hh
Vulkan: Texture Data Conversions This PR adds basic support for texture update, read back and clearing for Vulkan. In Vulkan we need to convert each data type ourselves as vulkan buffers are untyped. Therefore this change mostly is about data conversions. Considerations: - Use a compute shader to do the conversions: - Leads to performance regression as compute pipeline can stall graphics pipeline - Lead to additional memory usage as two staging buffers are needed one to hold the CPU data, and one to hold the converted data. - Do inline conversion when sending the data to Vulkan using `eGPUDataFormat` - Additional CPU cycles required and not easy to optimize as it the implementation requires many branches. - Do inline conversion when sending the data to Vulkan (optimized for CPU) For this solution it was chosen to implement the 3rd option as it is fast and doesn't require additional memory what the other options do. **Use Imath/half.h** This patch uses `Imath/half.h` (dependency of OpenEXR) similar to alembic. But this makes vulkan dependent of the availability of OpenEXR. For now this isn't checked, but when we are closer to a working Vulkan backend we have to make a decision how to cope with this dependency. **Missing Features** *Framebuffer textures* This doesn't include all possible data transformations. Some of those transformation can only be tested after the VKFramebuffer has been implemented. Some texture types are only available when created for a framebuffer. These include the depth and stencil variations. *Component format* Is more relevant when implementing VKVertexBuffer. *SRGB textures* SRGB encoded textures aren't natively supported on all platforms, in all usages and might require workarounds. This should be done in a separate PR in a later stage when we are required to use SRGB textures. **Test cases** The added test cases gives an overview of the missing bits and pieces of the patch. When the implementation/direction is accepted more test cases can be enabled/implemented. Some of these test cases will skip depending on the actual support of platform the tests are running on. For example OpenGL/NVidia will skip the next test as it doesn't support the texture format on OpenGL, although it does support it on Vulkan. ``` [ RUN ] GPUOpenGLTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ SKIPPED ] GPUOpenGLTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ RUN ] GPUVulkanTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ OK ] GPUVulkanTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI ``` Pull Request: https://projects.blender.org/blender/blender/pulls/105762
2023-03-24 08:09:19 +01:00
vulkan/vk_data_conversion.hh
Vulkan: Provide Debug Utilities This PR uses the VK_EXT_debug_utils extension, but it's only for labeling, so it doesn't rely on the VK_LAYER_KHRONOS_validation functionality. The functions that do these things are loaded into the runtime as vulkan extensions. Declare the function pointers in a struct and make them members of vk_context. Pull Request: https://projects.blender.org/blender/blender/pulls/106098
2023-04-21 12:32:40 +02:00
vulkan/vk_debug.hh
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_descriptor_pools.hh
vulkan/vk_descriptor_set.hh
Vulkan: Share descriptor set layouts between shaders Previously all shaders had its own descriptor set layout handle. This makes it difficult to see if currently bound resources can be reused when switching shaders. To work around this limitation, the vulkan backend rebound the resources over and over again. This PR is part of the render graph where changing shaders can reuse previous bound resources. This PR only makes sure that the layout handles are the same so we can identify 'compatible' pipelines. The behavior to limit rebinding of resources will be added as part of the render graph in a later commit. Pull Request: https://projects.blender.org/blender/blender/pulls/120562
2024-04-16 14:00:49 +02:00
vulkan/vk_descriptor_set_layouts.hh
Vulkan: Share Device Between Contexts Previous GHOST_ContextVK would create a logical device for each context. Blender uses multiple contexts at the same time and wasn't able to share resources between them as the logical device where different. This patch will create a single logical device and share them between multiple contexts. This allows sharing memory/shaders between contexts and make sure that all memory allocations are freed from the device it was allocated from. Some allocations in Blender are freed when there isn't a context, this was failing in the previous implementation. We didn't noticed it before as we didn't test multiple contexts. This patch also moves device specific data structures from VKContext to VKDevice like the descriptor pools, debug layers etc. Pull Request: https://projects.blender.org/blender/blender/pulls/107606
2023-05-04 10:06:48 +02:00
vulkan/vk_device.hh
GPU: Add placeholders for PixelBuffer to vulkan backend. PixelBuffer was recently introduced. This change adds empty placeholders to the vulkan backend and other related API tweaks.
2022-12-02 08:35:17 +01:00
vulkan/vk_fence.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_framebuffer.hh
Vulkan: Share driver check between GPU and GHOST GPU and GHOST require to have identical checks to remove faulty drivers. When not done GHOST can still select a device that isn't supported and lead to freezing interfaces. Pull Request: https://projects.blender.org/blender/blender/pulls/131241
2024-12-02 14:50:32 +01:00
vulkan/vk_ghost_api.hh
Vulkan: Image Views The ownership of image views depends on how they are used. When used as an framebuffer attachment the image view is owned by the framebuffer. When used as a image/texture in a shader the ownership of the image view is the texture itself. Pull Request: https://projects.blender.org/blender/blender/pulls/108765
2023-06-08 16:07:38 +02:00
vulkan/vk_image_view.hh
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
vulkan/vk_immediate.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_index_buffer.hh
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
vulkan/vk_memory.hh
Cleanup: sort cmake file lists
2025-04-08 14:09:15 +10:00
vulkan/vk_memory_layout.hh
Cleanup: sort file lists
2025-09-12 10:20:40 +10:00
vulkan/vk_memory_pool.hh
Vulkan: Pipeline pool In Vulkan, a Blender shader is organized in multiple objects. A VkPipeline is the highest level concept and represents somewhat we call a shader. A pipeline is an device/platform optimized version of the shader that is uploaded and executed in the GPU device. A key difference with shaders is that its usage is also compiled in. When using the same shader with a different blending, a new pipeline needs to be created. In the current implementation of the Vulkan backend the pipeline is re-created when any pipeline parameter changes. This triggers many pipeline compilations. Especially when common shaders are used in different parts of the drawing code. A requirement of our render graph implementation is that changes of the pipeline can be detected based on the VkPipeline handle. We only want to rebind the pipeline handle when the handle actually changes. This improves performance (especially on NVIDIA) devices where pipeline binds are known to be costly. The solution of this PR is to add a pipeline pool. This holds all pipelines and can find an already created pipeline based on pipeline infos. Only compute pipelines support has been added. # Future enhancements - Recent drivers replace `VkShaderModule` with pipeline libraries. It improves sharing pipeline stages and reduce pipeline creation times. - GPUMaterials should be removed from the pipeline pool when they are destroyed. Details on this will be more clear when EEVEE support is added. Pull Request: https://projects.blender.org/blender/blender/pulls/120899
2024-04-23 12:39:41 +02:00
vulkan/vk_pipeline_pool.hh
GPU: Add placeholders for PixelBuffer to vulkan backend. PixelBuffer was recently introduced. This change adds empty placeholders to the vulkan backend and other related API tweaks.
2022-12-02 08:35:17 +01:00
vulkan/vk_pixel_buffer.hh
Vulkan: Push constants **What are push constants?** Push constants is a way to quickly provide a small amount of uniform data to shaders. It should be much quicker than UBOs but a huge limitation is the size of data - spec requires 128 bytes to be available for a push constant range. **What are the challenges with push constants?** The challenge with push constants is that the limited available size. According to the Vulkan spec each platform should at least have 128 bytes reserved for push constants. Current Mesa/AMD drivers supports 256 bytes, but Mesa/Intel is only 128 bytes. **What is our solution?** Some shaders of Blender uses more than these boundaries. When more data is needed push constants will not be used, but the shader will be patched to use an uniform buffer instead. This mechanism will be part of the Vulkan backend and shader developers should not see any difference on API level. **Known limitations** Current state of the vulkan backend does not track resources that are in the command queue. This patch includes some test cases that identified this issue as well. See #104771. Pull Request #104880
2023-03-06 12:28:55 +01:00
vulkan/vk_push_constants.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_query.hh
Vulkan: Occlusion Queries Implements occlusion queries using VkQueryPools. Pull Request: https://projects.blender.org/blender/blender/pulls/123883
2024-08-20 11:27:33 +02:00
vulkan/render_graph/nodes/vk_begin_query_node.hh
Vulkan: Render graph clear attachments Adds support for clear attachments to the render graph. Clearing attachments require that the command buffer is being set for rendering (vkCmdBeginRendering). **What works** - Clear attachments are working with dynamic rendering and the render graph - `GPUVulkanTest.framebuffer_clear_color_single_attachment` - `GPUVulkanTest.framebuffer_clear_color_multiple_attachments` - `GPUVulkanTest.framebuffer_clear_multiple_color_multiple_attachments` - `GPUVulkanTest.framebuffer_scissor_test` - `GPUVulkanTest.framebuffer_clear_depth` **What still needs to be addressed** When a command buffer is rendering it cannot do any pipeline barriers. For clearing attachments this isn't needed, but when we address drawing we might need to register drawing resource dependencies to the dependency list of the begin rendering node. This will be solved when drawing will be implemented. [#121648] The begin rendering node is large as it has to store data for framebuffers with 8 color attachments as well. This might become an overhead and we could solve this by splicing the data of larger nodes into 2 lists. This will be addressed after we are able to draw a screen so we can collect data on this topic. [#121649] Pull Request: https://projects.blender.org/blender/blender/pulls/121073
2024-05-10 15:39:56 +02:00
vulkan/render_graph/nodes/vk_begin_rendering_node.hh
Cleanup: sort cmake file lists
2024-07-25 11:24:10 +10:00
vulkan/render_graph/nodes/vk_blit_image_node.hh
Vulkan: Render graph clear attachments Adds support for clear attachments to the render graph. Clearing attachments require that the command buffer is being set for rendering (vkCmdBeginRendering). **What works** - Clear attachments are working with dynamic rendering and the render graph - `GPUVulkanTest.framebuffer_clear_color_single_attachment` - `GPUVulkanTest.framebuffer_clear_color_multiple_attachments` - `GPUVulkanTest.framebuffer_clear_multiple_color_multiple_attachments` - `GPUVulkanTest.framebuffer_scissor_test` - `GPUVulkanTest.framebuffer_clear_depth` **What still needs to be addressed** When a command buffer is rendering it cannot do any pipeline barriers. For clearing attachments this isn't needed, but when we address drawing we might need to register drawing resource dependencies to the dependency list of the begin rendering node. This will be solved when drawing will be implemented. [#121648] The begin rendering node is large as it has to store data for framebuffers with 8 color attachments as well. This might become an overhead and we could solve this by splicing the data of larger nodes into 2 lists. This will be addressed after we are able to draw a screen so we can collect data on this topic. [#121649] Pull Request: https://projects.blender.org/blender/blender/pulls/121073
2024-05-10 15:39:56 +02:00
vulkan/render_graph/nodes/vk_clear_attachments_node.hh
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/nodes/vk_clear_color_image_node.hh
Vulkan: Render graph textures This PR implements render graph for VKTexture. During the implementation some tweaks to the render graph was done to support depth and stencil textures. The render graph will record the image aspect being used for each node. This will then be used to generate barriers for the correct aspect. Also fixes an issue that uploading of array textures didn't allocate a large enough staging buffer. Pull Request: https://projects.blender.org/blender/blender/pulls/120821
2024-04-19 14:55:39 +02:00
vulkan/render_graph/nodes/vk_clear_depth_stencil_image_node.hh
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/nodes/vk_copy_buffer_node.hh
vulkan/render_graph/nodes/vk_copy_buffer_to_image_node.hh
vulkan/render_graph/nodes/vk_copy_image_node.hh
vulkan/render_graph/nodes/vk_copy_image_to_buffer_node.hh
CMake: include headers in source lists
2024-07-25 11:24:11 +10:00
vulkan/render_graph/nodes/vk_dispatch_indirect_node.hh
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/nodes/vk_dispatch_node.hh
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
vulkan/render_graph/nodes/vk_draw_indexed_indirect_node.hh
Cleanup: sort cmake file lists
2024-07-25 11:24:10 +10:00
vulkan/render_graph/nodes/vk_draw_indexed_node.hh
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
vulkan/render_graph/nodes/vk_draw_indirect_node.hh
Cleanup: sort cmake file lists
2024-07-25 11:24:10 +10:00
vulkan/render_graph/nodes/vk_draw_node.hh
Vulkan: Occlusion Queries Implements occlusion queries using VkQueryPools. Pull Request: https://projects.blender.org/blender/blender/pulls/123883
2024-08-20 11:27:33 +02:00
vulkan/render_graph/nodes/vk_end_query_node.hh
Vulkan: Render graph clear attachments Adds support for clear attachments to the render graph. Clearing attachments require that the command buffer is being set for rendering (vkCmdBeginRendering). **What works** - Clear attachments are working with dynamic rendering and the render graph - `GPUVulkanTest.framebuffer_clear_color_single_attachment` - `GPUVulkanTest.framebuffer_clear_color_multiple_attachments` - `GPUVulkanTest.framebuffer_clear_multiple_color_multiple_attachments` - `GPUVulkanTest.framebuffer_scissor_test` - `GPUVulkanTest.framebuffer_clear_depth` **What still needs to be addressed** When a command buffer is rendering it cannot do any pipeline barriers. For clearing attachments this isn't needed, but when we address drawing we might need to register drawing resource dependencies to the dependency list of the begin rendering node. This will be solved when drawing will be implemented. [#121648] The begin rendering node is large as it has to store data for framebuffers with 8 color attachments as well. This might become an overhead and we could solve this by splicing the data of larger nodes into 2 lists. This will be addressed after we are able to draw a screen so we can collect data on this topic. [#121649] Pull Request: https://projects.blender.org/blender/blender/pulls/121073
2024-05-10 15:39:56 +02:00
vulkan/render_graph/nodes/vk_end_rendering_node.hh
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/nodes/vk_fill_buffer_node.hh
vulkan/render_graph/nodes/vk_node_info.hh
vulkan/render_graph/nodes/vk_pipeline_data.hh
Vulkan: Occlusion Queries Implements occlusion queries using VkQueryPools. Pull Request: https://projects.blender.org/blender/blender/pulls/123883
2024-08-20 11:27:33 +02:00
vulkan/render_graph/nodes/vk_reset_query_pool_node.hh
Cleanup: sort cmake file lists
2024-05-06 09:20:57 +10:00
vulkan/render_graph/nodes/vk_synchronization_node.hh
Vulkan: Add node to update buffers This change adds the option to update a buffer via the render graph via `vkCmdUpdateBuffer`. This is only enabled for uniform buffers as they are small and aligned/sized correctly. Pull Request: https://projects.blender.org/blender/blender/pulls/128416
2024-10-01 14:22:56 +02:00
vulkan/render_graph/nodes/vk_update_buffer_node.hh
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
vulkan/render_graph/nodes/vk_update_mipmaps_node.hh
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/vk_command_buffer_wrapper.hh
vulkan/render_graph/vk_command_builder.hh
Cleanup: sort cmake file lists
2024-05-06 09:20:57 +10:00
vulkan/render_graph/vk_render_graph.hh
vulkan/render_graph/vk_render_graph_links.hh
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/vk_render_graph_node.hh
vulkan/render_graph/vk_resource_access_info.hh
vulkan/render_graph/vk_resource_state_tracker.hh
vulkan/render_graph/vk_scheduler.hh
Vulkan: Resource Pools This PR implements #126353; In short: keep discard list as part of swap chain images. This allows better determination when resources are actually not in use anymore. ## Resource pool Resource pools keep track of the resources for a swap chain image. In Blender this is a bit more complicated due to the way GPUContext work. A single thread can have multiple contexts. Some of them have a swap chain (GHOST Window) other don't (draw manager). The resource pool should be shared between the contexts running on the same thread. When opening multiple windows there are also multiple swap chains to consider. ### Discard pile Resource handles that are deleted and stored in the discard pile. When we are sure that these resources are not used on the GPU anymore these are destroyed. ### Reusable resources There are other resources as well like: - Descriptor sets - Descriptor pools ## Open issues There are some limitations that require future PRs to fix including: - Background rendering - Handling multiple windows - Improve CPU/GPU synchronization - Reuse staging buffers Pull Request: https://projects.blender.org/blender/blender/pulls/126353
2024-08-19 15:37:48 +02:00
vulkan/vk_resource_pool.hh
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
vulkan/vk_sampler.hh
Vulkan: Implement Samplers Until now the Vulkan backend supported a single pre-configured sampler. This PR realizes creation, caching and freeing of samplers based on what is required by the state manager. The implementation is similar to OpenGL or Metal. This fixes many issues including: - Textures in workbench and eevee use the correct extend and filtering - Custom icons render correctly - Depth sampling issues - Removes artifacts using EEVEE world shader, lighting and indirect lighting. Pull Request: https://projects.blender.org/blender/blender/pulls/114827
2023-11-14 11:12:19 +01:00
vulkan/vk_samplers.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_shader.hh
Vulkan: Parallel shader compilation This PR introduces parallel shader compilation for Vulkan shader modules. This will improve shader compilation when switching to material preview or EEVEE render preview. It also improves material compilation. However in order to measure the differences shaderc needs to be updated. PR has been created so we can already start with the code review. This PR doesn't include SPIR-V caching, what will land in a separate PR as it needs more validation. Parallel shader compilation has been tested on AMD/NVIDIA on Linux. Testing on other platforms is planned in the upcoming days. **Performance** ``` AMD Ryzen™ 9 7950X × 32, 64GB Ram Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02 ``` *Test*: Start blender, open barbershop_interior.blend and wait until the viewport has fully settled. | Backend | Test | Duration | | ------- | ------------------------- | -------- | | OpenGL | Coldstart/No subprocesses | 1:52 | | OpenGL | Coldstart/8 Subprocesses | 0:54 | | OpenGL | Warmstart/8 Subprocesses | 0:06 | | Vulkan | Coldstart Without PR | 0:59 | | Vulkan | Warmstart Without PR | 0:58 | | Vulkan | Coldstart With PR | 0:33 | | Vulkan | Warmstart With PR | 0:08 | The difference in time (why OpenGL is faster in a warm start is that all shaders are cached). Vulkan in this case doesn't cache anything and all shaders are recompiled each time. Caching the shaders will be part of a future PR. Main reason not to add it to this PR directly is that SPIR-V cannot easily be validated and would require a sidecar to keep SPIR-V compatible with external tools.. **NOTE**: - This PR was extracted from #127418 - This PR requires #127564 to land and libraries to update. Linux lib is available as attachment in this PR. It works without, but is as slow as single threaded compilation. Pull Request: https://projects.blender.org/blender/blender/pulls/127698
2024-09-20 08:30:09 +02:00
vulkan/vk_shader_compiler.hh
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_shader_interface.hh
GPU: Compile vulkan shaders to Spir-V binaries. Compile each static shader using shaderc to Spir-V binaries. The main goal is to make sure that the GLSL created using ShaderCreateInfo and able to compile to Spir-V. For the second stage a correct pipeline needs to be created and some shader would need more adjustments (push constants size). With this patch future changes to GLSL sources can already be checked against vulkan, without the backend finished. Mechanism has been tested using MacOS and MoltenVK. For other OS, we should finetune CMake files to find the right location to shaderc. ``` ************************************************************ *** Build Mon 12 Dec 2022 11:08:07 CET ************************************************************ Shader Test compilation result: 463 / 463 passed (skipped 118 for compatibility reasons) OpenGL backend shader compilation succeeded. Shader Test compilation result: 529 / 529 passed (skipped 52 for compatibility reasons) Vulkan backend shader compilation succeeded. ``` Reviewed By: fclem Maniphest Tasks: T102760 Differential Revision: https://developer.blender.org/D16610
2022-12-12 12:22:38 +01:00
vulkan/vk_shader_log.hh
Vulkan: Parallel shader compilation This PR introduces parallel shader compilation for Vulkan shader modules. This will improve shader compilation when switching to material preview or EEVEE render preview. It also improves material compilation. However in order to measure the differences shaderc needs to be updated. PR has been created so we can already start with the code review. This PR doesn't include SPIR-V caching, what will land in a separate PR as it needs more validation. Parallel shader compilation has been tested on AMD/NVIDIA on Linux. Testing on other platforms is planned in the upcoming days. **Performance** ``` AMD Ryzen™ 9 7950X × 32, 64GB Ram Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02 ``` *Test*: Start blender, open barbershop_interior.blend and wait until the viewport has fully settled. | Backend | Test | Duration | | ------- | ------------------------- | -------- | | OpenGL | Coldstart/No subprocesses | 1:52 | | OpenGL | Coldstart/8 Subprocesses | 0:54 | | OpenGL | Warmstart/8 Subprocesses | 0:06 | | Vulkan | Coldstart Without PR | 0:59 | | Vulkan | Warmstart Without PR | 0:58 | | Vulkan | Coldstart With PR | 0:33 | | Vulkan | Warmstart With PR | 0:08 | The difference in time (why OpenGL is faster in a warm start is that all shaders are cached). Vulkan in this case doesn't cache anything and all shaders are recompiled each time. Caching the shaders will be part of a future PR. Main reason not to add it to this PR directly is that SPIR-V cannot easily be validated and would require a sidecar to keep SPIR-V compatible with external tools.. **NOTE**: - This PR was extracted from #127418 - This PR requires #127564 to land and libraries to update. Linux lib is available as attachment in this PR. It works without, but is as slow as single threaded compilation. Pull Request: https://projects.blender.org/blender/blender/pulls/127698
2024-09-20 08:30:09 +02:00
vulkan/vk_shader_module.hh
Vulkan: Store Vertex, Index and Storage Buffers on Device Memory Currently all buffer types were stored in host memory, which is visible to the GPU as well. This is typically slow as the data would be transferred over the PCI bus when used. Most of the time Index and Vertex buffers are written once and read many times so it makes more sense to locate them on the GPU. Storage buffers typically require quick access as they are created for shading/compute purposes. This PR will try to store vertex buffers, index buffers and storage buffers on device memory to improve the performance. Uniform buffers are still located on host memory as they can be uploaded during binding process. This can (will) reset the graphics pipeline triggering draw calls using unattached resources. In future this could be optimized further as in: * using different pools for allocating specific buffers, with a fallback when buffers cannot be stored on the GPU anymore. * store uniform buffers in device memory Pull Request: https://projects.blender.org/blender/blender/pulls/115343
2023-11-24 13:52:48 +01:00
vulkan/vk_staging_buffer.hh
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
vulkan/vk_state_manager.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_storage_buffer.hh
vulkan/vk_texture.hh
Vulkan: to_string for used vulkan types Every vulkan installation has a vk.xml file containing the vulkan specification in a machine readable fasion. This PR uses the vk.xml to generate to_string functions for data types blender uses. When updating to a new specification or when changing features/extensions we should re-generate the to_string functions. The generator is implemented in `vk_to_string.py`. Pull Request: https://projects.blender.org/blender/blender/pulls/119880
2024-03-26 11:35:16 +01:00
vulkan/vk_to_string.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_uniform_buffer.hh
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
vulkan/vk_vertex_attribute_object.hh
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
vulkan/vk_vertex_buffer.hh
)
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
set(METAL_SRC
metal/mtl_backend.mm
Metal: MTLBatch and MTLDrawList implementation. MTLBatch and MTLDrawList implementation enables use of Metal Viewport for UI and Workbench. Includes Vertex descriptor caching and SSBO Vertex Fetch mode draw call submission. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D16101
2022-10-18 12:18:25 +02:00
metal/mtl_batch.mm
MTLCommandBufferState for coordinating GPU workload submission and render pass coordination. MTLFrameBuffer has been implemented to support creation of RenderCommandEncoders, along with supporting functionality in the Metal Context. Optimisation stubs for GPU_framebuffer_bind_ext has been added, which enables specific assignment of attachment load-store ops at the bind level, rather than on a framebuffer object as a whole. Begin and end frame markers are used to encapsulate frame boundaries for explicit workload submission. This is required for explicit APIs where implicit flushing of work does not occur. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15027
2022-06-27 11:41:04 +02:00
metal/mtl_command_buffer.mm
Cleanup: sort cmake file-lists
2022-08-09 13:26:37 +10:00
metal/mtl_context.mm
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
metal/mtl_debug.mm
MTLCommandBufferState for coordinating GPU workload submission and render pass coordination. MTLFrameBuffer has been implemented to support creation of RenderCommandEncoders, along with supporting functionality in the Metal Context. Optimisation stubs for GPU_framebuffer_bind_ext has been added, which enables specific assignment of attachment load-store ops at the bind level, rather than on a framebuffer object as a whole. Begin and end frame markers are used to encapsulate frame boundaries for explicit workload submission. This is required for explicit APIs where implicit flushing of work does not occur. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15027
2022-06-27 11:41:04 +02:00
metal/mtl_framebuffer.mm
Metal: MTLContext implementation and immediate mode rendering support. MTLContext provides functionality for command encoding, binding management and graphics device management. MTLImmediate provides simple draw enablement with dynamically encoded data. These draws utilise temporary scratch buffer memory to provide minimal bandwidth overhead during workload submission. This patch also contains empty placeholders for MTLBatch and MTLDrawList to enable testing of first pixels on-screen without failure. The Metal API also requires access to the GHOST_Context to ensure the same pre-initialized Metal GPU device is used by the viewport. Given the explicit nature of Metal, explicit control is also needed over presentation, to ensure correct work scheduling and rendering pipeline state. Authored by Apple: Michael Parkin-White Ref T96261 (The diff is based on 043f59cb3b5835ba1a0bbf6f1cbad080b527f7f6) Reviewed By: fclem Differential Revision: https://developer.blender.org/D15953
2022-09-22 17:27:51 +02:00
metal/mtl_immediate.mm
Metal: MTLIndexBuf class implementation. Implementation also contains a number of optimisations and feature enablements specific to the Metal API and Apple Silicon GPUs. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15369
2022-09-01 21:42:47 +02:00
metal/mtl_index_buffer.mm
Metal: MTLMemoryManager implementation includes functions which manage allocation of MTLBuffer resources. The memory manager includes both a GPUContext-local manager which allocates per-context resources such as Circular Scratch Buffers for temporary data such as uniform updates and resource staging, and a GPUContext-global memory manager which features a pooled memory allocator for efficient re-use of resources, to reduce CPU-overhead of frequent memory allocations. These Memory Managers act as a simple interface for use by other Metal backend modules and to coordinate the lifetime of buffers, to ensure that GPU-resident resources are correctly tracked and freed when no longer in use. Note: This also contains dependent DIFF changes from D15027, though these will be removed once D15027 lands. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15277
2022-07-01 10:30:16 +02:00
metal/mtl_memory.mm
Metal: MTLQueryPool implementation adding support for occlusion queries. When a query begins, the current visibility result buffer needs to be associated with the currently active Render Pass. The MTLContext and MTLCommandBuffer are responsible for ensuring new render pass objects are created if the visibility state changes. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15356
2022-07-19 16:59:42 +02:00
metal/mtl_query.mm
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
metal/mtl_shader.mm
metal/mtl_shader_generator.mm
metal/mtl_shader_interface.mm
Metal: ShaderLog: Add initial implementation This is a really rough implementation. Since the MSL sources do not correspond 1:1 to the GLSL sources, some mapping is needed to retreive the GLSL source file for a given generated line. This will be implemented in a later commit.
2023-05-03 19:08:59 +02:00
metal/mtl_shader_log.mm
Metal: MTLState module implementation. MTLState module implementation and supporting functionality in MTLContext for state tracking, texture binding and sampler state caching. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14827
2022-05-12 20:49:09 +02:00
metal/mtl_state.mm
Metal: Storage buffer and explicit bind location support Adds support for Storage buffers, including changes to the resource binding model to ensure explicit resource bind locations are supported for all resource types. Storage buffer support also includes required changes for shader source generation and SSBO wrapper support for other resource types such as GPUVertBuf, GPUIndexBuf and GPUUniformBuf. Authored by Apple: Michael Parkin-White Pull Request: https://projects.blender.org/blender/blender/pulls/107175
2023-05-03 11:46:30 +02:00
metal/mtl_storage_buffer.mm
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
metal/mtl_texture.mm
metal/mtl_texture_util.mm
Metal: MTLUniformBuffer module implementation Initial implementation. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Differential Revision: https://developer.blender.org/D15357
2022-07-19 17:11:03 +02:00
metal/mtl_uniform_buffer.mm
Metal: MTLVertBuf implementation and support for texture creation from vertex buffers. Metal: MTLVertBuf implementation and support for texture creation from vertex buffers. Authored by Apple: Michael Parkin-White Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15452
2022-09-22 17:13:07 +02:00
metal/mtl_vertex_buffer.mm
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
metal/mtl_backend.hh
Metal: MTLContext implementation and immediate mode rendering support. MTLContext provides functionality for command encoding, binding management and graphics device management. MTLImmediate provides simple draw enablement with dynamically encoded data. These draws utilise temporary scratch buffer memory to provide minimal bandwidth overhead during workload submission. This patch also contains empty placeholders for MTLBatch and MTLDrawList to enable testing of first pixels on-screen without failure. The Metal API also requires access to the GHOST_Context to ensure the same pre-initialized Metal GPU device is used by the viewport. Given the explicit nature of Metal, explicit control is also needed over presentation, to ensure correct work scheduling and rendering pipeline state. Authored by Apple: Michael Parkin-White Ref T96261 (The diff is based on 043f59cb3b5835ba1a0bbf6f1cbad080b527f7f6) Reviewed By: fclem Differential Revision: https://developer.blender.org/D15953
2022-09-22 17:27:51 +02:00
metal/mtl_batch.hh
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
metal/mtl_capabilities.hh
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
metal/mtl_common.hh
metal/mtl_context.hh
metal/mtl_debug.hh
MTLCommandBufferState for coordinating GPU workload submission and render pass coordination. MTLFrameBuffer has been implemented to support creation of RenderCommandEncoders, along with supporting functionality in the Metal Context. Optimisation stubs for GPU_framebuffer_bind_ext has been added, which enables specific assignment of attachment load-store ops at the bind level, rather than on a framebuffer object as a whole. Begin and end frame markers are used to encapsulate frame boundaries for explicit workload submission. This is required for explicit APIs where implicit flushing of work does not occur. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15027
2022-06-27 11:41:04 +02:00
metal/mtl_framebuffer.hh
Metal: MTLContext implementation and immediate mode rendering support. MTLContext provides functionality for command encoding, binding management and graphics device management. MTLImmediate provides simple draw enablement with dynamically encoded data. These draws utilise temporary scratch buffer memory to provide minimal bandwidth overhead during workload submission. This patch also contains empty placeholders for MTLBatch and MTLDrawList to enable testing of first pixels on-screen without failure. The Metal API also requires access to the GHOST_Context to ensure the same pre-initialized Metal GPU device is used by the viewport. Given the explicit nature of Metal, explicit control is also needed over presentation, to ensure correct work scheduling and rendering pipeline state. Authored by Apple: Michael Parkin-White Ref T96261 (The diff is based on 043f59cb3b5835ba1a0bbf6f1cbad080b527f7f6) Reviewed By: fclem Differential Revision: https://developer.blender.org/D15953
2022-09-22 17:27:51 +02:00
metal/mtl_immediate.hh
Metal: MTLIndexBuf class implementation. Implementation also contains a number of optimisations and feature enablements specific to the Metal API and Apple Silicon GPUs. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15369
2022-09-01 21:42:47 +02:00
metal/mtl_index_buffer.hh
Metal: MTLMemoryManager implementation includes functions which manage allocation of MTLBuffer resources. The memory manager includes both a GPUContext-local manager which allocates per-context resources such as Circular Scratch Buffers for temporary data such as uniform updates and resource staging, and a GPUContext-global memory manager which features a pooled memory allocator for efficient re-use of resources, to reduce CPU-overhead of frequent memory allocations. These Memory Managers act as a simple interface for use by other Metal backend modules and to coordinate the lifetime of buffers, to ensure that GPU-resident resources are correctly tracked and freed when no longer in use. Note: This also contains dependent DIFF changes from D15027, though these will be removed once D15027 lands. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15277
2022-07-01 10:30:16 +02:00
metal/mtl_memory.hh
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
metal/mtl_primitive.hh
Cleanup: sort cmake file lists
2022-09-07 15:14:33 +10:00
metal/mtl_pso_descriptor_state.hh
Metal: MTLQueryPool implementation adding support for occlusion queries. When a query begins, the current visibility result buffer needs to be associated with the currently active Render Pass. The MTLContext and MTLCommandBuffer are responsible for ensuring new render pass objects are created if the visibility state changes. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15356
2022-07-19 16:59:42 +02:00
metal/mtl_query.hh
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
metal/mtl_shader.hh
metal/mtl_shader_generator.hh
metal/mtl_shader_interface.hh
Cleanup: sort cmake file lists
2022-09-07 15:14:33 +10:00
metal/mtl_shader_interface_type.hh
Metal: ShaderLog: Add initial implementation This is a really rough implementation. Since the MSL sources do not correspond 1:1 to the GLSL sources, some mapping is needed to retreive the GLSL source file for a given generated line. This will be implemented in a later commit.
2023-05-03 19:08:59 +02:00
metal/mtl_shader_log.hh
Fix: GPU: Broken compilation on Mac
2025-04-16 21:34:18 +02:00
metal/mtl_shader_shared.hh
Metal: MTLState module implementation. MTLState module implementation and supporting functionality in MTLContext for state tracking, texture binding and sampler state caching. Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14827
2022-05-12 20:49:09 +02:00
metal/mtl_state.hh
Metal: Storage buffer and explicit bind location support Adds support for Storage buffers, including changes to the resource binding model to ensure explicit resource bind locations are supported for all resource types. Storage buffer support also includes required changes for shader source generation and SSBO wrapper support for other resource types such as GPUVertBuf, GPUIndexBuf and GPUUniformBuf. Authored by Apple: Michael Parkin-White Pull Request: https://projects.blender.org/blender/blender/pulls/107175
2023-05-03 11:46:30 +02:00
metal/mtl_storage_buffer.hh
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
metal/mtl_texture.hh
Metal: MTLUniformBuffer module implementation Initial implementation. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Differential Revision: https://developer.blender.org/D15357
2022-07-19 17:11:03 +02:00
metal/mtl_uniform_buffer.hh
Metal: MTLVertBuf implementation and support for texture creation from vertex buffers. Metal: MTLVertBuf implementation and support for texture creation from vertex buffers. Authored by Apple: Michael Parkin-White Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15452
2022-09-22 17:13:07 +02:00
metal/mtl_vertex_buffer.hh
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
)
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
set(LIB
Cleanup: CMake: Modernize bf_blenkernel dependencies Pretty straightforward - Remove any bf_blenkernel paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132282
2024-12-23 20:08:37 +01:00
PRIVATE bf::blenkernel
Cleanup: CMake: Modernize bf_blenlib dependencies Pretty straightforward - Remove any blenlib paths from INC - Add a dependency though LIB Pull Request: https://projects.blender.org/blender/blender/pulls/109934
2023-07-10 22:04:18 +02:00
PRIVATE bf::blenlib
Cleanup: CMake: Modernize bf_bmesh dependencies Pretty straightforward - Remove any bf_bmesh paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132203
2024-12-23 17:47:25 +01:00
PRIVATE bf::bmesh
Cleanup: CMake: Modernize bf_dna dependencies There's quite a few libraries that depend on dna_type_offsets.h but had gotten to it by just adding the folder that contains it to their includes INC section without declaring a dependency to bf_dna in the LIB section. which occasionally lead to the lib building before bf_dna and the header being missing, while this generally gets fixed in CMake by adding bf_dna to the LIB section of the lib, however until last week all libraries in the LIB section were linked as INTERFACE so adding it in there did not resolve the build issue. To make things still build, we sprinkled add_dependencies wherever we needed it to force a build order. This diff : Declares public include folders for the bf_dna target so there's no more fudging the INC section required to get to them. Removes all dna related paths from the INC section for all libraries. Adds an alias target bf:dna to signify it has been updated to modern cmake Declares a dependency on bf::dna for all libraries that require it Removes (almost) all calls to add_dependencies for bf_dna Future work: Because of the manual dependency management that was done, there is now some "clutter" with libs depending on bf_dna that realistically don't. Example bf_intern_opencolorio itself has no dependency on bf_dna at all, doesn't need it, doesn't use it. However the dna include folder had been added to it in the past since bf_blenlib uses dna headers in some of its public headers and bf_intern_opencolorio does use those blenlib headers. Given bf_blenlib now correctly declares the dependency on bf_dna as public bf_intern_opencolorio will get the dna header directory automatically from CMake, hence some cleanup could be done for bf_intern_opencolorio Because 99% of the changes in this diff have been automated, this diff does not seek to address these issues as there is no easy way to determine why a certain dependency is in place. A developer will have to make a pass a this at some later point in time. As I'd rather not mix automated and manual labour. There are a few libraries that could not be automatically processed (ie bf_blendthumb) that also will need this manual look-over. Pull Request: https://projects.blender.org/blender/blender/pulls/109835
2023-07-10 15:07:37 +02:00
PRIVATE bf::dna
Cleanup: CMake: Modernize bf_draw dependencies Pretty straightforward - Remove any bf_draw paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132411
2024-12-28 21:38:19 +01:00
PRIVATE bf::draw
Cleanup: CMake: Modernize bf_imbuf dependencies Pretty straightforward - Remove any bf_imbuf paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132336
2024-12-25 23:32:15 +01:00
PRIVATE bf::imbuf
Cleanup: Cmake: use alias target for bf_intern_atomic This introduces an alias target `bf::intern::atomic` for `bf_intern_atomic`. This has the following benefits: - Any target name with `::` in it will be recognized as an actual target by cmake, rather than a library name it may not know about. and will be validated by cmake to exist. Which means if you make a typo in the LIB section, CMake will error out telling you it doesn't know about this specific target rather than passing it on to the build system, where you'll either get build or linker errors because of said typo. - Given there is quite a cleanup still to do in the build system, it won't always be obvious which targets have been updated to modern targets and which still need to be done. Having a namespaced target name is a good indicator there. Pull Request: https://projects.blender.org/blender/blender/pulls/109784
2023-07-07 15:37:02 +02:00
PRIVATE bf::intern::atomic
Cleanup: CMake: Modernize bf_intern_clog dependencies Pretty straightforward - Remove any bf_intern_clog paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/115323
2023-11-24 17:12:24 +01:00
PRIVATE bf::intern::clog
Cleanup: CMake: Modernize bf_guardedalloc dependencies Pretty straightforward - Removes any guardedalloc paths from INC - Adds a dependency though LIB Pull Request: https://projects.blender.org/blender/blender/pulls/109925
2023-07-10 18:44:19 +02:00
PRIVATE bf::intern::guardedalloc
Cleanup: GPU: Avoid raw pointers for shader API strings Avoid measuring the length of strings repeatedly by passing their length along with their data with `StringRefNull`. Null termination seems to be necessary still for passing the shader sources to OpenGL. Though I doubt this is a bottleneck, it's still nice to avoid overhead from string operations and this helps move in that direction. Pull Request: https://projects.blender.org/blender/blender/pulls/127702
2024-11-01 20:00:31 +01:00
PRIVATE bf::extern::fmtlib
Cleanup: CMake: Modernize bf_nodes dependencies Pretty straightforward - Remove any bf_nodes paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132356
2024-12-26 19:52:49 +01:00
PRIVATE bf::nodes
Refactor: OpenColorIO integration Briefly about this change: - OpenColorIO C-API is removed. - The information about color spaces in ImBuf module is removed. It was stored in global ListBase in colormanagement.cc. - Both OpenColorIO and fallback implementation supports GPU drawing. - Fallback implementation supports white point, RGB curves, etc. - Removed check for support of GPU drawing in IMB. Historically it was implemented in a separate library with C-API, this is because way back C++ code needed to stay in intern. This causes all sort of overheads, and even calls that are strictly considered bad level. This change moves OpenColorIO integration into a module within imbuf, next to movie, and next to IMB_colormanagement which is the main user of it. This allows to avoid copy of color spaces, displays, views etc in the ImBuf: they were used to help quickly querying information to be shown on the interface. With this change it can be stored in the same data structures as what is used by the OpenColorIO integration. While it might not be fully avoiding duplication it is now less, and there is no need in the user code to maintain the copies. In a lot of cases this change also avoids allocations done per access to the OpenColorIO. For example, it is not needed anymore to allocate image descriptor in a heap. The bigger user-visible change is that the fallback implementation now supports GLSL drawing, with the whole list of supported features, such as curve mapping and white point. This should help simplifying code which relies on color space conversion on GPU: there is no need to figure out fallback solution in such cases. The only case when drawing will not work is when there is some actual bug, or driver issue, and shader has failed to compile. The change avoids having an opaque type for color space, and instead uses forward declaration. It is a bit verbose on declaration, but helps avoiding unsafe type-casts. There are ways to solve this in the future, like having a header for forward declaration, or to flatten the name space a bit. There should be no user-level changes under normal operation. When building without OpenColorIO or the configuration has a typo or is missing a fuller set of color management tools is applies (such as the white point correction). Pull Request: https://projects.blender.org/blender/blender/pulls/138433
2025-05-09 14:01:43 +02:00
PRIVATE bf::dependencies::optional::opencolorio
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
)
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
# Select Backend source based on availability
GHOST: Replace WITH_OPENGL build option Replaces it by WITH_OPENGL_BACKEND and cleanup its usage. Limits visibility of opengl enums and cases. Pull Request: https://projects.blender.org/blender/blender/pulls/109947
2023-07-11 09:17:31 +02:00
if(WITH_OPENGL_BACKEND)
CMake: WITH_OPENGL_BACKEND=OFF excludes EGL/EPOXY includes & libraries This isn't complete as opensubdiv, hydra & XR still depend on OpenGL.
2023-10-07 18:29:52 +11:00
list(APPEND INC_SYS
${Epoxy_INCLUDE_DIRS}
)
list(APPEND SRC
${OPENGL_SRC}
)
list(APPEND LIB
${Epoxy_LIBRARIES}
)
GHOST: Replace WITH_OPENGL build option Replaces it by WITH_OPENGL_BACKEND and cleanup its usage. Limits visibility of opengl enums and cases. Pull Request: https://projects.blender.org/blender/blender/pulls/109947
2023-07-11 09:17:31 +02:00
add_definitions(-DWITH_OPENGL_BACKEND)
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
endif()
if(WITH_METAL_BACKEND)
list(APPEND SRC ${METAL_SRC})
endif()
CMake: prepare for BLENDER_SORTED_LIBS removal No functional change, this adds LIB definition and args to cmake files. Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS' since there are many platforms/configurations that could break when changing linking order. Manually add and enable WITHOUT_SORTED_LIBS to try building without sorted libs (currently fails since all variables are empty). This check will eventually be removed. See T46725.
2019-04-14 15:18:44 +02:00
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
if(WITH_VULKAN_BACKEND)
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
list(APPEND INC
Cleanup: add missing CMake headers & sort file lists
2023-03-01 22:46:04 +11:00
../../../extern/vulkan_memory_allocator
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
)
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
list(APPEND INC_SYS
${VULKAN_INCLUDE_DIRS}
CMake: quiet undefined variable use with MOLTENVK on non-apple systems
2023-10-07 18:25:44 +11:00
)
list(APPEND INC_SYS
Vulkan: Changes to CMake config. Paths to vulkan libraries, paths and related components were hardcoded in the platform cmake file. This patch separates this by using adding CMake modules for Vulkan and ShaderC. This change has only been applied to the macOs configuration as that is currently our main platform for development. Other platforms will be added during the development of the Vulkan back-end.
2023-01-30 11:24:06 +01:00
${SHADERC_INCLUDE_DIRS}
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
)
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
list(APPEND SRC
${VULKAN_SRC}
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
)
list(APPEND LIB
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
${VULKAN_LIBRARIES}
Vulkan: Changes to CMake config. Paths to vulkan libraries, paths and related components were hardcoded in the platform cmake file. This patch separates this by using adding CMake modules for Vulkan and ShaderC. This change has only been applied to the macOs configuration as that is currently our main platform for development. Other platforms will be added during the development of the Vulkan back-end.
2023-01-30 11:24:06 +01:00
${SHADERC_LIBRARIES}
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
extern_vulkan_memory_allocator
Fix #130942: Vulkan: Hash collision in graphics pipeline pool Blender stores all pipelines in a pool. Using a hash it checks if a the pipeline was already created and the previous could be reused. Due to performance issues when working with graphics pipelines some equal operations only used a hash check. For scissors and viewports this isn't enough and could lead to issues. This PR fixes this to still perform an exact check if the hash are equal. Note that the performance drops a bit. And should be countered with other performance improvements in the future. Pull Request: https://projects.blender.org/blender/blender/pulls/132005
2024-12-17 12:43:20 +01:00
PRIVATE bf::extern::xxhash
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
)
Vulkan: Fix Compilation Issue on Windows. Vulkan uses IMath. IMath on windows requires an option to indicate it is used as dll file. This option wasn't set for the GPU module. Thanks to Kazashi Yoshioka for mentioning this. Pull Request: https://projects.blender.org/blender/blender/pulls/106932
2023-04-14 10:17:35 +02:00
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
add_definitions(-DWITH_VULKAN_BACKEND)
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
endif()
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
set(GLSL_SRC
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_shader_shared.hh
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
shaders/infos/gpu_clip_planes_infos.hh
shaders/infos/gpu_index_load_infos.hh
shaders/infos/gpu_interface_infos.hh
shaders/infos/gpu_shader_2D_area_borders_infos.hh
shaders/infos/gpu_shader_2D_checker_infos.hh
shaders/infos/gpu_shader_2D_diag_stripes_infos.hh
shaders/infos/gpu_shader_2D_image_desaturate_color_infos.hh
shaders/infos/gpu_shader_2D_image_infos.hh
shaders/infos/gpu_shader_2D_image_overlays_merge_infos.hh
shaders/infos/gpu_shader_2D_image_overlays_stereo_merge_infos.hh
shaders/infos/gpu_shader_2D_image_rect_color_infos.hh
shaders/infos/gpu_shader_2D_image_shuffle_color_infos.hh
shaders/infos/gpu_shader_2D_node_socket_infos.hh
shaders/infos/gpu_shader_2D_nodelink_infos.hh
shaders/infos/gpu_shader_2D_point_uniform_size_uniform_color_aa_infos.hh
shaders/infos/gpu_shader_2D_point_uniform_size_uniform_color_outline_aa_infos.hh
shaders/infos/gpu_shader_2D_point_varying_size_varying_color_infos.hh
shaders/infos/gpu_shader_2D_widget_infos.hh
shaders/infos/gpu_shader_3D_depth_only_infos.hh
shaders/infos/gpu_shader_3D_flat_color_infos.hh
shaders/infos/gpu_shader_3D_image_infos.hh
shaders/infos/gpu_shader_3D_point_infos.hh
shaders/infos/gpu_shader_3D_polyline_infos.hh
shaders/infos/gpu_shader_3D_smooth_color_infos.hh
shaders/infos/gpu_shader_3D_uniform_color_infos.hh
shaders/infos/gpu_shader_fullscreen_infos.hh
shaders/infos/gpu_shader_gpencil_stroke_infos.hh
shaders/infos/gpu_shader_icon_infos.hh
shaders/infos/gpu_shader_index_infos.hh
shaders/infos/gpu_shader_keyframe_shape_infos.hh
shaders/infos/gpu_shader_line_dashed_uniform_color_infos.hh
shaders/infos/gpu_shader_print_infos.hh
shaders/infos/gpu_shader_sequencer_infos.hh
shaders/infos/gpu_shader_simple_lighting_infos.hh
shaders/infos/gpu_shader_text_infos.hh
shaders/infos/gpu_srgb_to_framebuffer_space_infos.hh
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/gpu_shader_depth_only_frag.glsl
shaders/gpu_shader_uniform_color_frag.glsl
shaders/gpu_shader_checker_frag.glsl
shaders/gpu_shader_diag_stripes_frag.glsl
shaders/gpu_shader_simple_lighting_frag.glsl
shaders/gpu_shader_flat_color_frag.glsl
shaders/gpu_shader_2D_vert.glsl
shaders/gpu_shader_2D_area_borders_vert.glsl
shaders/gpu_shader_2D_area_borders_frag.glsl
shaders/gpu_shader_2D_widget_base_vert.glsl
shaders/gpu_shader_2D_widget_base_frag.glsl
shaders/gpu_shader_2D_widget_shadow_vert.glsl
shaders/gpu_shader_2D_widget_shadow_frag.glsl
Nodes: Add new shader for node sockets Add a new shader specifically for node sockets rather than using the keyframe shader. Motivation: 1. Allow easier addition of new socket shapes 2. Simplify socket drawing by avoiding special handling of multi-inputs 3. Support multi-inputs for all socket types (diamond, square, etc.) The new shader is tweaked to look the same to the old ones. **Comparison** The biggest difference is that the multi socket is now more consistent with the other sockets. For single sockets there can be small size differences depending on zoom level because the old socket shader always aligned the sockets to the pixel grid. This could cause a bit of jiggling compared to the rest of the node when slowly zooming. Therefore I left it out of the new shader and it now scales strictly linear with the view. **Multi Socket Types** While there currently is no need for (.) internally, there are a few obvious use-cases for multi-input field (diamond) sockets like generalized math nodes with an arbitrary number of inputs (Add, Multiply, Minimum etc.). Co-authored-by: Jacques Lucke <jacques@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/119243
2024-11-23 16:42:38 +01:00
shaders/gpu_shader_2D_node_socket_frag.glsl
shaders/gpu_shader_2D_node_socket_vert.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/gpu_shader_2D_nodelink_frag.glsl
shaders/gpu_shader_2D_nodelink_vert.glsl
shaders/gpu_shader_2D_line_dashed_frag.glsl
shaders/gpu_shader_2D_image_vert.glsl
shaders/gpu_shader_2D_image_rect_vert.glsl
Fix #103398: Fix Icon sampler initialization in Metal backend. Resolves issue with nearest filtering on UI Icons. Note that as Metal does not support LOD bias as a parameter on a sampler object, the original code has been modified to perform LOD biasing at the shader level. As GPU_SAMPLER_ICON is not widely used, it is more efficient to apply directly to the affected shaders, rather than workaround passing in the sampler LOD bias as a separate value e.g. uniform or push constant. Original PR feedback addressed to also refactor ICON shaders to use consistent style for single and multi Icon rendering. Authored by Apple: Michael Parkin-White Ref #96261 Pull Request #105145
2023-02-26 13:23:40 +01:00
shaders/gpu_shader_icon_multi_vert.glsl
UI: Icon number indicator for data-blocks Adds the possibility of having a little number on top of icons. At the moment this is used for: * Outliner * Node Editor bread-crumb * Node Group node header For the outliner there is almost no functional change. It is mostly a refactor to handle the indicators as part of the icon shader instead of the outliner draw code. (note that this was already recently changed in a5d3b648e3e2). The difference is that now we use rounded border rectangle instead of circles, and we can go up to 999 elements. So for the outliner this shows the number of collapsed elements of a certain type (e.g., mesh objects inside a collapsed collection). For the node editors is being used to show the use count for the data-block. This is important for the node editor, so users know whether the node-group they are editing (or are about to edit) is used elsewhere. This is particularly important when the Node Options are hidden, which is the default for node groups appended from the asset libraries. --- Note: This can be easily enabled for ID templates which can then be part of T84669. It just need to call UI_but_icon_indicator_number_set in the function template_add_button_search_menu. --- Special thanks Clément Foucault for the help figuring out the shader, Julian Eisel for the help navigating the UI code, and Pablo Vazquez for the collaboration in this design solution. For images showing the result check the Differential Revision. Differential Revision: https://developer.blender.org/D16284
2022-10-20 16:37:07 +02:00
shaders/gpu_shader_icon_frag.glsl
shaders/gpu_shader_icon_vert.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/gpu_shader_image_frag.glsl
shaders/gpu_shader_image_desaturate_frag.glsl
shaders/gpu_shader_image_overlays_merge_frag.glsl
shaders/gpu_shader_image_overlays_stereo_merge_frag.glsl
shaders/gpu_shader_image_shuffle_color_frag.glsl
shaders/gpu_shader_image_color_frag.glsl
shaders/gpu_shader_3D_image_vert.glsl
shaders/gpu_shader_3D_vert.glsl
shaders/gpu_shader_3D_normal_vert.glsl
shaders/gpu_shader_3D_flat_color_vert.glsl
shaders/gpu_shader_3D_line_dashed_uniform_color_vert.glsl
shaders/gpu_shader_3D_polyline_frag.glsl
shaders/gpu_shader_3D_polyline_vert.glsl
shaders/gpu_shader_3D_smooth_color_vert.glsl
shaders/gpu_shader_3D_smooth_color_frag.glsl
shaders/gpu_shader_3D_clipped_uniform_color_vert.glsl
shaders/gpu_shader_point_uniform_color_aa_frag.glsl
shaders/gpu_shader_point_uniform_color_outline_aa_frag.glsl
shaders/gpu_shader_point_varying_color_frag.glsl
shaders/gpu_shader_3D_point_varying_size_varying_color_vert.glsl
shaders/gpu_shader_3D_point_uniform_size_aa_vert.glsl
Fix #139565: PyGPU: Add builtin point shaders This PR adds builtin shaders for drawing points. Using `FLAT_COLOR`, `SMOOTH_COLOR`, `UNIFORM_COLOR` can lead to undesired behavior on Metal and Vulkan backends. To ensure future compatibility this PR adds `POINT_FLAT_COLOR` and `POINT_UNIFORM_COLOR`. The point size can be set using `gpu.state.point_size_set`. Pull Request: https://projects.blender.org/blender/blender/pulls/139583
2025-05-29 14:36:32 +02:00
shaders/gpu_shader_3D_point_flat_color_vert.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/gpu_shader_2D_point_varying_size_varying_color_vert.glsl
shaders/gpu_shader_2D_point_uniform_size_aa_vert.glsl
shaders/gpu_shader_2D_point_uniform_size_outline_aa_vert.glsl
shaders/gpu_shader_text_vert.glsl
shaders/gpu_shader_text_frag.glsl
shaders/gpu_shader_keyframe_shape_vert.glsl
shaders/gpu_shader_keyframe_shape_frag.glsl
VSE: Do Scopes on the GPU, improve their look, HDR for waveform/parade Faster and better looking VSE scopes & "show overexposed". Waveform & RGB Parade now can also show HDR color intensities. (Note: this is only about VSE scopes; Image Space scopes are to be improved separately) - Waveform, RGB Parade, Vectorscope scopes are done on the GPU now, by drawing points for each input pixel, and placing them according to scope logic. The point drawing is implemented in a compute shader, with a fragment shader resolve pass; this is because drawing lots of points in the same location is very slow on some GPUs (e.g. Apple). The compute shader rasterizer is several times faster on regular desktop GPU as well. - If a non-default color management is needed (e.g. VSE colorspace is not the same as display colorspace, or a custom look transform is used etc. etc.), then transform the VSE preview texture into display space RGBA 16F texture using OCIO GPU machinery, and calculate scopes from that. - The "show overexposed" (zebra) preview option is also done on the GPU now. - Waveform/Parade scopes unlock zoom X/Y aspect for viewing HDR scope, similar to how it was done for HDR histograms recently. - Added SEQ_preview_cache.hh that holds GPU textures of VSE preview, this is so that when you have a preview and several scopes, each of them does not have to create/upload their own GPU texture (that would both waste memory, and be slow). Screenshots and performance details in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/144867
2025-08-26 12:25:43 +02:00
shaders/gpu_shader_sequencer_scope_comp.glsl
shaders/gpu_shader_sequencer_scope_frag.glsl
VSE: Rounded corners for timeline strips VSE timeline strips now have rounded corners. Strip corner rounding radius is 4, 6 or 8px depending on strip height (if strip is too narrow to fit rounding, then rounding is turned off). This is achieved with a dedicated GPU shader for drawing most of VSE strip widget, that it could do proper rounded corner masking. More details and images in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/122576
2024-06-04 20:05:35 +02:00
shaders/gpu_shader_sequencer_strips_vert.glsl
shaders/gpu_shader_sequencer_strips_frag.glsl
VSE: Faster timeline thumbnail drawing VSE timeline, when many (hundreds/thousands) of thumbnails were visible, was very slow to redraw. This PR makes them 3-10x faster to redraw, by stopping doing things that are slow :) Part of #126087 thumbnail improvements task. - No longer do mute semitransparency or corner rounding on the CPU, do it in shader instead. - Stop creating a separate GPU texture for each thumbnail, on every repaint, and drawing each thumbnail as a separate draw call. Instead, put thumbnails into a single texture atlas (using a simple shelf packing algorithm), and draw them in batch, passing data via UBO. The atlas is still re-created every frame, but that does not seem to be a performance issue. Thumbnails are cropped horizontally based on how much of their parts are visible (e.g. a narrow strip on screen), so realistically the atlas size is kinda proportional to screen size, and ends up being just several megabytes of data transfer between CPU -> GPU each frame. On this Sprite Fright edit timeline view (612 visible thumbnails), time taken to repaint the timeline window: - Mac (M1 Max, Metal): 68.1ms -> 4.7ms - Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 23.7ms -> 6.8ms This also fixes a visual issue with thumbnails, where when strips are very tall, the "rounded corners" that were poked right into the thumbnail bitmap on the CPU were showing up due to actual bitmap being scaled up a lot. Pull Request: https://projects.blender.org/blender/blender/pulls/126972
2024-09-03 08:25:15 +02:00
shaders/gpu_shader_sequencer_thumbs_vert.glsl
shaders/gpu_shader_sequencer_thumbs_frag.glsl
VSE: Do Scopes on the GPU, improve their look, HDR for waveform/parade Faster and better looking VSE scopes & "show overexposed". Waveform & RGB Parade now can also show HDR color intensities. (Note: this is only about VSE scopes; Image Space scopes are to be improved separately) - Waveform, RGB Parade, Vectorscope scopes are done on the GPU now, by drawing points for each input pixel, and placing them according to scope logic. The point drawing is implemented in a compute shader, with a fragment shader resolve pass; this is because drawing lots of points in the same location is very slow on some GPUs (e.g. Apple). The compute shader rasterizer is several times faster on regular desktop GPU as well. - If a non-default color management is needed (e.g. VSE colorspace is not the same as display colorspace, or a custom look transform is used etc. etc.), then transform the VSE preview texture into display space RGBA 16F texture using OCIO GPU machinery, and calculate scopes from that. - The "show overexposed" (zebra) preview option is also done on the GPU now. - Waveform/Parade scopes unlock zoom X/Y aspect for viewing HDR scope, similar to how it was done for HDR histograms recently. - Added SEQ_preview_cache.hh that holds GPU textures of VSE preview, this is so that when you have a preview and several scopes, each of them does not have to create/upload their own GPU texture (that would both waste memory, and be slow). Screenshots and performance details in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/144867
2025-08-26 12:25:43 +02:00
shaders/gpu_shader_sequencer_zebra_frag.glsl
VSE: Rounded corners for timeline strips VSE timeline strips now have rounded corners. Strip corner rounding radius is 4, 6 or 8px depending on strip height (if strip is too narrow to fit rounding, then rounding is turned off). This is achieved with a dedicated GPU shader for drawing most of VSE strip widget, that it could do proper rounded corner masking. More details and images in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/122576
2024-06-04 20:05:35 +02:00
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/gpu_shader_codegen_lib.glsl
DRW: Primitive Expansion This PR introduces the concept of primitive expansion draws. This allows to create a drawcall that will generate N amount of new primitive for an original primitive in a `gpu::Batch`. The intent is to phase out the use of geometry shader for this purpose. This adds a new `Frequency::GEOMETRY` only available for SSBOs. The resources using this will be fed the current `gpu::Batch` VBOs using name matching. A dedicated slot is reserved for the index buffer, which has its own internal lib to decode the index buffer content. A new attribute lib is added to ease the loading of unaligned attribute. This should be revisited and made obsolete once more refactor lands. It is similar to the Metal backend SSBO vertex fetch path but it is defined on a different level. The main difference is that this PR is backend independant and modify the draw module instead of the GPU module. However, it doesn't cover all possible attribute conversion cases. This will only be added if needed. This system is less automatic than the Metal backend one and needs more care to make sure the data matches what the shader expects. The Metal system will be removed once all its usage have been converted. This PR only shows example usage for workbench shadows. Cleanup PRs will follow this one. Rel #105221 Pull Request: https://projects.blender.org/blender/blender/pulls/125782
2024-08-03 11:06:17 +02:00
shaders/common/gpu_shader_attribute_load_lib.glsl
Realtime Compositor: Implement bicubic interpolation This patch implements the bicubic interpolation option in the transform nodes. The path merely reuse the code in the shader image texture and adds bicubic variants to the domain realization shader. Pull Request: https://projects.blender.org/blender/blender/pulls/105533
2023-03-07 18:02:20 +01:00
shaders/common/gpu_shader_bicubic_sampler_lib.glsl
GPU: Move common shaders into a common directory This patch moves some of the utility library shaders into a common directory and makes the necessary renames across shaders. Additionally, material-specific transform functions were moved outside of math utils into a separate transform_utils.glsl file. This is needed in preparation for the viewport compositor, which will make use of some of those utilities and will require all material specific bit to be removed out of those files. Reviewed By: fclem Differential Revision: https://developer.blender.org/D14688
2022-05-06 12:58:14 +02:00
shaders/common/gpu_shader_common_color_ramp.glsl
shaders/common/gpu_shader_common_color_utils.glsl
EEVEE: Refactor curve nodes This patches rewrites the GPU shaders of curve nodes for easier future development. This is a non-functional change. The new code avoids code duplication by moving common code into BKE curve mapping functions. It also avoids ambiguous data embedding into the gradient vectors that are passed to vectors and reduces the size of uniforms uploaded to the shader by avoiding redundancies. This is needed in preparation for the viewport compositor, which will utilize and extend this implementation. Reviewed By: fclem Differential Revision: https://developer.blender.org/D14689
2022-05-06 13:33:23 +02:00
shaders/common/gpu_shader_common_curves.glsl
GPU: Move common shaders into a common directory This patch moves some of the utility library shaders into a common directory and makes the necessary renames across shaders. Additionally, material-specific transform functions were moved outside of math utils into a separate transform_utils.glsl file. This is needed in preparation for the viewport compositor, which will make use of some of those utilities and will require all material specific bit to be removed out of those files. Reviewed By: fclem Differential Revision: https://developer.blender.org/D14688
2022-05-06 12:58:14 +02:00
shaders/common/gpu_shader_common_hash.glsl
shaders/common/gpu_shader_common_math_utils.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_common_math.glsl
GPU: Move common shaders into a common directory This patch moves some of the utility library shaders into a common directory and makes the necessary renames across shaders. Additionally, material-specific transform functions were moved outside of math utils into a separate transform_utils.glsl file. This is needed in preparation for the viewport compositor, which will make use of some of those utilities and will require all material specific bit to be removed out of those files. Reviewed By: fclem Differential Revision: https://developer.blender.org/D14688
2022-05-06 12:58:14 +02:00
shaders/common/gpu_shader_common_mix_rgb.glsl
EEVEE-Next: Remove common lib usage Replaces all usage by the the gpu_shader_math equivalent. This is because the old shader library was quite tangled. This avoids dependency hell trying to mix libraries. Changes are split into isolated commits until I had to do mass changes because of inter- dependencies. Pull Request: https://projects.blender.org/blender/blender/pulls/113631
2023-10-13 17:59:46 +02:00
shaders/common/gpu_shader_debug_gradients_lib.glsl
DRW: Move fullscreen vertex shader to gpu common This makes no sense to have in the draw namespace. Also take the opportunity for making the coordinates a float2 and rename them to something more descriptive.
2025-04-16 20:08:28 +02:00
shaders/common/gpu_shader_fullscreen_vert.glsl
DRW: Primitive Expansion This PR introduces the concept of primitive expansion draws. This allows to create a drawcall that will generate N amount of new primitive for an original primitive in a `gpu::Batch`. The intent is to phase out the use of geometry shader for this purpose. This adds a new `Frequency::GEOMETRY` only available for SSBOs. The resources using this will be fed the current `gpu::Batch` VBOs using name matching. A dedicated slot is reserved for the index buffer, which has its own internal lib to decode the index buffer content. A new attribute lib is added to ease the loading of unaligned attribute. This should be revisited and made obsolete once more refactor lands. It is similar to the Metal backend SSBO vertex fetch path but it is defined on a different level. The main difference is that this PR is backend independant and modify the draw module instead of the GPU module. However, it doesn't cover all possible attribute conversion cases. This will only be added if needed. This system is less automatic than the Metal backend one and needs more care to make sure the data matches what the shader expects. The Metal system will be removed once all its usage have been converted. This PR only shows example usage for workbench shadows. Cleanup PRs will follow this one. Rel #105221 Pull Request: https://projects.blender.org/blender/blender/pulls/125782
2024-08-03 11:06:17 +02:00
shaders/common/gpu_shader_index_load_lib.glsl
DRW: New Curve Drawing Implementation of the design task #142969. This adds the following: - Exact GPU interpolation of curves of all types. - Radius attribute support. - Cyclic curve support. - Resolution attribute support. - New Cylinder hair shape type. ![image.png](/attachments/a8e7aea0-b0e5-4694-b660-89fb3df1ddcd) What changed: - EEVEE doesn't compute random normals for strand hairs anymore. These are considered legacy now. - EEVEE now have an internal shadow bias to avoid self shadowing on hair. - Workbench Curves Strip display option is no longer flat and has better shading. - Legacy Hair particle system evaluates radius at control points before applying additional subdivision. This now matches Cycles. - Color Attribute Node without a name do not fetch the active color attribute anymore. This now matches Cycles. Notes: - This is not 100% matching the CPU implementation for interpolation (see the epsilons in the tests). - Legacy Hair Particle points is now stored in local space after interpolation. The new cylinder shape allows for more correct hair shading in workbench and better intersection in EEVEE. | | Strand | Strip | Cylinder | | ---- | --- | --- | --- | | Main | ![main_strand.png](/attachments/67d3b792-962c-4272-a92c-1c0c7c6cf8de) | ![main_strip.png](/attachments/f2aa3575-368e-4fbb-b888-74df845918f1) | N/A | | PR | ![pr_strand.png](/attachments/cc012483-25f0-491f-a06e-ad3029981d47) | ![pr_strip.png](/attachments/73fa2f5c-5252-4b30-a334-e935ed0fb938) | ![pr_cylinder.png](/attachments/3133b2d4-a6f2-41ee-8e2d-f6fd00db0c8d) | | | Strand | Strip | Cylinder | | ---- | --- | --- | --- | | Main | ![main_strand_closeup.png](/attachments/730bd79c-6762-446d-819b-3ea47961ff9f) |![main_strip_closeup.png](/attachments/d9ace578-cfeb-4895-9896-3625b6ad7a02) | N/A | | PR | ![pr_strand_closeup.png](/attachments/ac8f3b0c-6ef6-4d54-b714-6322f9865036)|![pr_strip_closeup.png](/attachments/8504711a-955b-4ab2-aa3d-c2d114baf9d4)| ![pr_cylinder_closeup.png](/attachments/1e2899a8-0a5c-431f-ac6c-5184d87e9598) | Cyclic Curve, Mixed curve type, and proper radius support: ![image.png](/attachments/7f0bf05e-62ee-4ae9-aef9-a5599249b8d7) Test file for attribute lookup: [test_attribute_lookup.blend](/attachments/1d54dd06-379b-4480-a1c5-96adc1953f77) Follow Up Tasks: - Correct full tube segments orientation based on tangent and normal attributes - Correct V resolution property per object - More attribute type support (currently only color) TODO: - [x] Attribute Loading Changes - [x] Generic Attributes - [x] Length Attribute - [x] Intercept Attribute - [x] Original Coordinate Attribute - [x] Cyclic Curves - [x] Legacy Hair Particle conversion - [x] Attribute Loading - [x] Additional Subdivision - [x] Move some function to generic headers (VertBuf, OffsetIndices) - [x] Fix default UV/Color attribute assignment Pull Request: https://projects.blender.org/blender/blender/pulls/143180
2025-08-27 09:49:43 +02:00
shaders/common/gpu_shader_index_range_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_math_angle_lib.glsl
shaders/common/gpu_shader_math_axis_angle_lib.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
shaders/common/gpu_shader_math_base_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_math_constants_lib.glsl
shaders/common/gpu_shader_math_euler_lib.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
shaders/common/gpu_shader_math_fast_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_math_matrix_adjoint_lib.glsl
shaders/common/gpu_shader_math_matrix_compare_lib.glsl
shaders/common/gpu_shader_math_matrix_construct_lib.glsl
shaders/common/gpu_shader_math_matrix_conversion_lib.glsl
shaders/common/gpu_shader_math_matrix_interpolate_lib.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
shaders/common/gpu_shader_math_matrix_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_math_matrix_normalize_lib.glsl
shaders/common/gpu_shader_math_matrix_projection_lib.glsl
shaders/common/gpu_shader_math_matrix_transform_lib.glsl
shaders/common/gpu_shader_math_quaternion_lib.glsl
shaders/common/gpu_shader_math_rotation_conversion_lib.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
shaders/common/gpu_shader_math_rotation_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_math_safe_lib.glsl
shaders/common/gpu_shader_math_vector_compare_lib.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
shaders/common/gpu_shader_math_vector_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_math_vector_reduce_lib.glsl
shaders/common/gpu_shader_math_vector_safe_lib.glsl
DRW: New Curve Drawing Implementation of the design task #142969. This adds the following: - Exact GPU interpolation of curves of all types. - Radius attribute support. - Cyclic curve support. - Resolution attribute support. - New Cylinder hair shape type. ![image.png](/attachments/a8e7aea0-b0e5-4694-b660-89fb3df1ddcd) What changed: - EEVEE doesn't compute random normals for strand hairs anymore. These are considered legacy now. - EEVEE now have an internal shadow bias to avoid self shadowing on hair. - Workbench Curves Strip display option is no longer flat and has better shading. - Legacy Hair particle system evaluates radius at control points before applying additional subdivision. This now matches Cycles. - Color Attribute Node without a name do not fetch the active color attribute anymore. This now matches Cycles. Notes: - This is not 100% matching the CPU implementation for interpolation (see the epsilons in the tests). - Legacy Hair Particle points is now stored in local space after interpolation. The new cylinder shape allows for more correct hair shading in workbench and better intersection in EEVEE. | | Strand | Strip | Cylinder | | ---- | --- | --- | --- | | Main | ![main_strand.png](/attachments/67d3b792-962c-4272-a92c-1c0c7c6cf8de) | ![main_strip.png](/attachments/f2aa3575-368e-4fbb-b888-74df845918f1) | N/A | | PR | ![pr_strand.png](/attachments/cc012483-25f0-491f-a06e-ad3029981d47) | ![pr_strip.png](/attachments/73fa2f5c-5252-4b30-a334-e935ed0fb938) | ![pr_cylinder.png](/attachments/3133b2d4-a6f2-41ee-8e2d-f6fd00db0c8d) | | | Strand | Strip | Cylinder | | ---- | --- | --- | --- | | Main | ![main_strand_closeup.png](/attachments/730bd79c-6762-446d-819b-3ea47961ff9f) |![main_strip_closeup.png](/attachments/d9ace578-cfeb-4895-9896-3625b6ad7a02) | N/A | | PR | ![pr_strand_closeup.png](/attachments/ac8f3b0c-6ef6-4d54-b714-6322f9865036)|![pr_strip_closeup.png](/attachments/8504711a-955b-4ab2-aa3d-c2d114baf9d4)| ![pr_cylinder_closeup.png](/attachments/1e2899a8-0a5c-431f-ac6c-5184d87e9598) | Cyclic Curve, Mixed curve type, and proper radius support: ![image.png](/attachments/7f0bf05e-62ee-4ae9-aef9-a5599249b8d7) Test file for attribute lookup: [test_attribute_lookup.blend](/attachments/1d54dd06-379b-4480-a1c5-96adc1953f77) Follow Up Tasks: - Correct full tube segments orientation based on tangent and normal attributes - Correct V resolution property per object - More attribute type support (currently only color) TODO: - [x] Attribute Loading Changes - [x] Generic Attributes - [x] Length Attribute - [x] Intercept Attribute - [x] Original Coordinate Attribute - [x] Cyclic Curves - [x] Legacy Hair Particle conversion - [x] Attribute Loading - [x] Additional Subdivision - [x] Move some function to generic headers (VertBuf, OffsetIndices) - [x] Fix default UV/Color attribute assignment Pull Request: https://projects.blender.org/blender/blender/pulls/143180
2025-08-27 09:49:43 +02:00
shaders/common/gpu_shader_offset_indices_lib.glsl
GPU: Add support for in shader printf This allows much easier debugging of shader programs. Usage is as simple as adding `printf` calls inside shaders. example: `printf("Formating %d\n", my_var);` Contrary to the `drw_print`, this is not limited to draw manager shader dispatch/draws. It is compatible with any shader inside blender. Most notably, this doesn't need a viewport to display. So this can be used to debug render pipeline. Data formating is currently limited to only `%x`, `%d`, `%u` and `%f`. This could be easily extended if this is really needed. There is no type checking, so values are directly reinterpreted as specified by the printf format. The current approach for making this work is to bind a storage buffer inside `GPU_shader_bind`, making it available to any shader that needs it. The storage buffer is downloaded back to CPU after a frame or a render step and the content printed to the console. This scheduling means that you cannot rely on these printfs to detect crashes. We could add a mode to force flushing at shader binding to avoid this limitation. The values are written from the shaders in binary form and only formated on the CPU. This avoid issues with manual printing like with `drw_print`. Pull Request: https://projects.blender.org/blender/blender/pulls/125071
2024-07-19 15:48:00 +02:00
shaders/common/gpu_shader_print_lib.glsl
GPU: Simplify matrix lib to reduce dead code This greatly reduce shader compilation time on some systems. Pull Request: https://projects.blender.org/blender/blender/pulls/146100
2025-09-15 12:07:26 +02:00
shaders/common/gpu_shader_ray_utils_lib.glsl
EEVEE: Reduce necessary includes This saves a few milisecond of compile time per shader. This removes the need for occlusion lib when not using occlusion node. To improve detection of uneeded includes, we add a new logging system which output can be fed to mermaid to inspect dependencies. The new dependencies can be inspected using `--log "gpu.shader_dependencies"` Example pasted here: ```mermaid flowchart LR draw_curves_lib.glsl_7298 --> gpu_shader_math_constants_lib.glsl_600 style gpu_shader_math_constants_lib.glsl_600 fill:#0f0 gpu_shader_math_matrix_conversion_lib.glsl_1032 --> gpu_shader_math_base_lib.glsl_1406 style gpu_shader_math_base_lib.glsl_1406 fill:#1e0 gpu_shader_math_matrix_conversion_lib.glsl_1032 --> gpu_shader_math_euler_lib.glsl_461 style gpu_shader_math_euler_lib.glsl_461 fill:#0f0 gpu_shader_math_matrix_compare_lib.glsl_2964 --> gpu_shader_math_vector_compare_lib.glsl_2489 style gpu_shader_math_vector_compare_lib.glsl_2489 fill:#2d0 gpu_shader_math_matrix_conversion_lib.glsl_1032 --> gpu_shader_math_matrix_compare_lib.glsl_2964 style gpu_shader_math_matrix_compare_lib.glsl_2964 fill:#2d0 gpu_shader_math_matrix_conversion_lib.glsl_1032 --> gpu_shader_math_quaternion_lib.glsl_395 style gpu_shader_math_quaternion_lib.glsl_395 fill:#0f0 gpu_shader_math_matrix_conversion_lib.glsl_1032 --> gpu_shader_utildefines_lib.glsl_3112 style gpu_shader_utildefines_lib.glsl_3112 fill:#3c0 draw_curves_lib.glsl_7298 --> gpu_shader_math_matrix_conversion_lib.glsl_1032 style gpu_shader_math_matrix_conversion_lib.glsl_1032 fill:#1e0 draw_curves_lib.glsl_7298 --> gpu_shader_math_matrix_transform_lib.glsl_706 style gpu_shader_math_matrix_transform_lib.glsl_706 fill:#0f0 eevee_surf_deferred_frag.glsl_4531 --> draw_curves_lib.glsl_7298 style draw_curves_lib.glsl_7298 fill:#780 eevee_surf_deferred_frag.glsl_4531 --> draw_view_lib.glsl_3551 style draw_view_lib.glsl_3551 fill:#3c0 eevee_gbuffer_lib.glsl_14598 --> gpu_shader_math_vector_reduce_lib.glsl_1383 style gpu_shader_math_vector_reduce_lib.glsl_1383 fill:#1e0 eevee_gbuffer_lib.glsl_14598 --> gpu_shader_codegen_lib.glsl_6143 style gpu_shader_codegen_lib.glsl_6143 fill:#690 eevee_gbuffer_lib.glsl_14598 --> gpu_shader_math_vector_lib.glsl_5038 style gpu_shader_math_vector_lib.glsl_5038 fill:#5a0 eevee_gbuffer_lib.glsl_14598 --> gpu_shader_utildefines_lib.glsl_3112 style gpu_shader_utildefines_lib.glsl_3112 fill:#3c0 eevee_gbuffer_write_lib.glsl_7324 --> eevee_gbuffer_lib.glsl_14598 style eevee_gbuffer_lib.glsl_14598 fill:#e10 eevee_surf_deferred_frag.glsl_4531 --> eevee_gbuffer_write_lib.glsl_7324 style eevee_gbuffer_write_lib.glsl_7324 fill:#780 eevee_ambient_occlusion_lib.glsl_10738 --> draw_view_lib.glsl_3551 style draw_view_lib.glsl_3551 fill:#3c0 draw_math_geom_lib.glsl_5172 --> gpu_shader_math_vector_lib.glsl_5038 style gpu_shader_math_vector_lib.glsl_5038 fill:#5a0 draw_math_geom_lib.glsl_5172 --> gpu_shader_math_vector_reduce_lib.glsl_1383 style gpu_shader_math_vector_reduce_lib.glsl_1383 fill:#1e0 eevee_ray_types_lib.glsl_2390 --> draw_math_geom_lib.glsl_5172 style draw_math_geom_lib.glsl_5172 fill:#5a0 eevee_ray_types_lib.glsl_2390 --> draw_view_lib.glsl_3551 style draw_view_lib.glsl_3551 fill:#3c0 eevee_ray_types_lib.glsl_2390 --> gpu_shader_math_matrix_transform_lib.glsl_706 style gpu_shader_math_matrix_transform_lib.glsl_706 fill:#0f0 gpu_shader_math_safe_lib.glsl_1235 --> gpu_shader_math_constants_lib.glsl_600 style gpu_shader_math_constants_lib.glsl_600 fill:#0f0 eevee_ray_types_lib.glsl_2390 --> gpu_shader_math_safe_lib.glsl_1235 style gpu_shader_math_safe_lib.glsl_1235 fill:#1e0 eevee_ray_types_lib.glsl_2390 --> gpu_shader_ray_lib.glsl_137 style gpu_shader_ray_lib.glsl_137 fill:#0f0 eevee_ambient_occlusion_lib.glsl_10738 --> eevee_ray_types_lib.glsl_2390 style eevee_ray_types_lib.glsl_2390 fill:#2d0 eevee_sampling_lib.glsl_4291 --> gpu_shader_math_base_lib.glsl_1406 style gpu_shader_math_base_lib.glsl_1406 fill:#1e0 eevee_sampling_lib.glsl_4291 --> gpu_shader_math_constants_lib.glsl_600 style gpu_shader_math_constants_lib.glsl_600 fill:#0f0 eevee_sampling_lib.glsl_4291 --> gpu_shader_math_safe_lib.glsl_1235 style gpu_shader_math_safe_lib.glsl_1235 fill:#1e0 eevee_ambient_occlusion_lib.glsl_10738 --> eevee_sampling_lib.glsl_4291 style eevee_sampling_lib.glsl_4291 fill:#4b0 eevee_ambient_occlusion_lib.glsl_10738 --> eevee_utility_tx_lib.glsl_1225 style eevee_utility_tx_lib.glsl_1225 fill:#1e0 eevee_ambient_occlusion_lib.glsl_10738 --> gpu_shader_math_base_lib.glsl_1406 style gpu_shader_math_base_lib.glsl_1406 fill:#1e0 gpu_shader_math_fast_lib.glsl_921 --> gpu_shader_math_constants_lib.glsl_600 style gpu_shader_math_constants_lib.glsl_600 fill:#0f0 eevee_ambient_occlusion_lib.glsl_10738 --> gpu_shader_math_fast_lib.glsl_921 style gpu_shader_math_fast_lib.glsl_921 fill:#0f0 gpu_shader_math_vector_safe_lib.glsl_5847 --> gpu_shader_math_safe_lib.glsl_1235 style gpu_shader_math_safe_lib.glsl_1235 fill:#1e0 eevee_ambient_occlusion_lib.glsl_10738 --> gpu_shader_math_vector_safe_lib.glsl_5847 style gpu_shader_math_vector_safe_lib.glsl_5847 fill:#5a0 eevee_ambient_occlusion_lib.glsl_10738 --> gpu_shader_utildefines_lib.glsl_3112 style gpu_shader_utildefines_lib.glsl_3112 fill:#3c0 eevee_nodetree_frag_lib.glsl_395 --> eevee_ambient_occlusion_lib.glsl_10738 style eevee_ambient_occlusion_lib.glsl_10738 fill:#a50 eevee_nodetree_frag_lib.glsl_395 --> eevee_geom_types_lib.glsl_682 style eevee_geom_types_lib.glsl_682 fill:#0f0 draw_model_lib.glsl_2563 --> draw_view_lib.glsl_3551 style draw_view_lib.glsl_3551 fill:#3c0 eevee_nodetree_lib.glsl_16051 --> draw_model_lib.glsl_2563 style draw_model_lib.glsl_2563 fill:#2d0 draw_object_infos_lib.glsl_1114 --> draw_model_lib.glsl_2563 style draw_model_lib.glsl_2563 fill:#2d0 eevee_nodetree_lib.glsl_16051 --> draw_object_infos_lib.glsl_1114 style draw_object_infos_lib.glsl_1114 fill:#1e0 eevee_nodetree_lib.glsl_16051 --> draw_view_lib.glsl_3551 style draw_view_lib.glsl_3551 fill:#3c0 eevee_nodetree_lib.glsl_16051 --> eevee_renderpass_lib.glsl_1793 style eevee_renderpass_lib.glsl_1793 fill:#1e0 eevee_nodetree_lib.glsl_16051 --> eevee_utility_tx_lib.glsl_1225 style eevee_utility_tx_lib.glsl_1225 fill:#1e0 eevee_nodetree_lib.glsl_16051 --> gpu_shader_codegen_lib.glsl_6143 style gpu_shader_codegen_lib.glsl_6143 fill:#690 eevee_nodetree_lib.glsl_16051 --> gpu_shader_math_base_lib.glsl_1406 style gpu_shader_math_base_lib.glsl_1406 fill:#1e0 eevee_nodetree_lib.glsl_16051 --> gpu_shader_math_safe_lib.glsl_1235 style gpu_shader_math_safe_lib.glsl_1235 fill:#1e0 eevee_nodetree_lib.glsl_16051 --> gpu_shader_math_vector_reduce_lib.glsl_1383 style gpu_shader_math_vector_reduce_lib.glsl_1383 fill:#1e0 eevee_nodetree_lib.glsl_16051 --> gpu_shader_utildefines_lib.glsl_3112 style gpu_shader_utildefines_lib.glsl_3112 fill:#3c0 eevee_nodetree_frag_lib.glsl_395 --> eevee_nodetree_lib.glsl_16051 style eevee_nodetree_lib.glsl_16051 fill:#f00 gpu_shader_material_ambient_occlusion.glsl_558 --> gpu_shader_math_vector_safe_lib.glsl_5847 style gpu_shader_math_vector_safe_lib.glsl_5847 fill:#5a0 eevee_nodetree_frag_lib.glsl_395 --> gpu_shader_material_ambient_occlusion.glsl_558 style gpu_shader_material_ambient_occlusion.glsl_558 fill:#0f0 eevee_nodetree_frag_lib.glsl_395 --> gpu_shader_material_emission.glsl_380 style gpu_shader_material_emission.glsl_380 fill:#0f0 gpu_shader_material_output_material.glsl_850 --> gpu_shader_material_transform_utils.glsl_2136 style gpu_shader_material_transform_utils.glsl_2136 fill:#2d0 eevee_nodetree_frag_lib.glsl_395 --> gpu_shader_material_output_material.glsl_850 style gpu_shader_material_output_material.glsl_850 fill:#0f0 eevee_nodetree_frag_lib.glsl_395 --> gpu_shader_material_world_normals.glsl_128 style gpu_shader_material_world_normals.glsl_128 fill:#0f0 eevee_surf_deferred_frag.glsl_4531 --> eevee_nodetree_frag_lib.glsl_395 style eevee_nodetree_frag_lib.glsl_395 fill:#0f0 eevee_surf_deferred_frag.glsl_4531 --> eevee_sampling_lib.glsl_4291 style eevee_sampling_lib.glsl_4291 fill:#4b0 eevee_surf_lib.glsl_3650 --> draw_view_lib.glsl_3551 style draw_view_lib.glsl_3551 fill:#3c0 eevee_surf_lib.glsl_3650 --> gpu_shader_codegen_lib.glsl_6143 style gpu_shader_codegen_lib.glsl_6143 fill:#690 eevee_surf_lib.glsl_3650 --> gpu_shader_math_base_lib.glsl_1406 style gpu_shader_math_base_lib.glsl_1406 fill:#1e0 eevee_surf_lib.glsl_3650 --> gpu_shader_math_vector_safe_lib.glsl_5847 style gpu_shader_math_vector_safe_lib.glsl_5847 fill:#5a0 eevee_surf_deferred_frag.glsl_4531 --> eevee_surf_lib.glsl_3650 style eevee_surf_lib.glsl_3650 fill:#3c0 ``` Pull Request: https://projects.blender.org/blender/blender/pulls/146580
2025-09-23 17:21:56 +02:00
shaders/common/gpu_shader_ray_lib.glsl
VSE: Faster timeline thumbnail drawing VSE timeline, when many (hundreds/thousands) of thumbnails were visible, was very slow to redraw. This PR makes them 3-10x faster to redraw, by stopping doing things that are slow :) Part of #126087 thumbnail improvements task. - No longer do mute semitransparency or corner rounding on the CPU, do it in shader instead. - Stop creating a separate GPU texture for each thumbnail, on every repaint, and drawing each thumbnail as a separate draw call. Instead, put thumbnails into a single texture atlas (using a simple shelf packing algorithm), and draw them in batch, passing data via UBO. The atlas is still re-created every frame, but that does not seem to be a performance issue. Thumbnails are cropped horizontally based on how much of their parts are visible (e.g. a narrow strip on screen), so realistically the atlas size is kinda proportional to screen size, and ends up being just several megabytes of data transfer between CPU -> GPU each frame. On this Sprite Fright edit timeline view (612 visible thumbnails), time taken to repaint the timeline window: - Mac (M1 Max, Metal): 68.1ms -> 4.7ms - Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 23.7ms -> 6.8ms This also fixes a visual issue with thumbnails, where when strips are very tall, the "rounded corners" that were poked right into the thumbnail bitmap on the CPU were showing up due to actual bitmap being scaled up a lot. Pull Request: https://projects.blender.org/blender/blender/pulls/126972
2024-09-03 08:25:15 +02:00
shaders/common/gpu_shader_sequencer_lib.glsl
GPU: Add library for handling shared exponent format in software This allows reducing bandwidth at the cost of some instructions for packing and decoding the texture. Pull Request: https://projects.blender.org/blender/blender/pulls/122446
2024-05-30 19:59:18 +02:00
shaders/common/gpu_shader_shared_exponent_lib.glsl
Realtime Compositor: Implement Anti-Aliasing node This patch implements the Anti-Aliasing node by porting SMAA from Workbench into a generic library that can be used by the realtime compositor and potentially other users. SMAA was encapsulated in an algorithm to prepare it for use by other nodes that require SMAA support. Pull Request: https://projects.blender.org/blender/blender/pulls/106114
2023-03-26 16:59:13 +02:00
shaders/common/gpu_shader_smaa_lib.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
shaders/common/gpu_shader_test_lib.glsl
shaders/common/gpu_shader_utildefines_lib.glsl
GPU: Move common shaders into a common directory This patch moves some of the utility library shaders into a common directory and makes the necessary renames across shaders. Additionally, material-specific transform functions were moved outside of math utils into a separate transform_utils.glsl file. This is needed in preparation for the viewport compositor, which will make use of some of those utilities and will require all material specific bit to be removed out of those files. Reviewed By: fclem Differential Revision: https://developer.blender.org/D14688
2022-05-06 12:58:14 +02:00
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_add_shader.glsl
shaders/material/gpu_shader_material_ambient_occlusion.glsl
shaders/material/gpu_shader_material_attribute.glsl
shaders/material/gpu_shader_material_background.glsl
shaders/material/gpu_shader_material_bevel.glsl
shaders/material/gpu_shader_material_wavelength.glsl
shaders/material/gpu_shader_material_blackbody.glsl
shaders/material/gpu_shader_material_bright_contrast.glsl
shaders/material/gpu_shader_material_bump.glsl
shaders/material/gpu_shader_material_camera.glsl
shaders/material/gpu_shader_material_clamp.glsl
Nodes: Add general Combine/Separate Color nodes Inspired by D12936 and D12929, this patch adds general purpose "Combine Color" and "Separate Color" nodes to Geometry, Compositor, Shader and Texture nodes. - Within Geometry Nodes, it replaces the existing "Combine RGB" and "Separate RGB" nodes. - Within Compositor Nodes, it replaces the existing "Combine RGBA/HSVA/YCbCrA/YUVA" and "Separate RGBA/HSVA/YCbCrA/YUVA" nodes. - Within Texture Nodes, it replaces the existing "Combine RGBA" and "Separate RGBA" nodes. - Within Shader Nodes, it replaces the existing "Combine RGB/HSV" and "Separate RGB/HSV" nodes. Python addons have not been updated to the new nodes yet. **New shader code** In node_color.h, color.h and gpu_shader_material_color_util.glsl, missing methods hsl_to_rgb and rgb_to_hsl are added by directly converting existing C code. They always produce the same result. **Old code** As requested by T96219, old nodes still exist but are not displayed in the add menu. This means Python scripts can still create them as usual. Otherwise, versioning replaces the old nodes with the new nodes when opening .blend files. Differential Revision: https://developer.blender.org/D14034
2022-05-04 18:44:03 +02:00
shaders/material/gpu_shader_material_combine_color.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_combine_xyz.glsl
shaders/material/gpu_shader_material_diffuse.glsl
shaders/material/gpu_shader_material_displacement.glsl
shaders/material/gpu_shader_material_eevee_specular.glsl
shaders/material/gpu_shader_material_emission.glsl
shaders/material/gpu_shader_material_fractal_noise.glsl
Nodes: add Fractal Voronoi Noise Fractal noise is the idea of evaluating the same noise function multiple times with different input parameters on each layer and then mixing the results. The individual layers are usually called octaves. The number of layers is controlled with a "Detail" slider. The "Lacunarity" input controls a factor by which each successive layer gets scaled. The existing Noise node already supports fractal noise. Now the Voronoi Noise node supports it as well. The node also has a new "Normalize" property that ensures that the output values stay in a [0.0, 1.0] range. That is except for the F2 feature where in rare cases the output may be outside that range even with "Normalize" turned on. How the individual octaves are mixed depends on the feature and output socket: - F1/Smooth F1/F2: - Distance/Color output: The individual Distance/Color octaves are first multiplied by a factor of `Roughness ^ (#layers - 1.0)` then added together to create the final output. - Position output: Each Position octave gets linearly interpolated with the combined output of the previous octaves. The Roughness input serves as an interpolation factor with 0.0 resutling in only using the combined output of the previous octaves and 1.0 resulting in only using the current highest octave. - Distance to Edge: - Distance output: The Distance octaves are mixed exactly like the Position octaves for F1/Smooth F1/F2. It should be noted that Voronoi Noise is a relatively slow noise function, especially at higher dimensions. Increasing the "Detail" makes it even slower. Therefore, when optimizing a scene one should consider trying to use simpler noise functions instead of Voronoi if the final result is close enough. Pull Request: https://projects.blender.org/blender/blender/pulls/106827
2023-06-13 09:18:12 +02:00
shaders/material/gpu_shader_material_fractal_voronoi.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_fresnel.glsl
shaders/material/gpu_shader_material_gamma.glsl
shaders/material/gpu_shader_material_geometry.glsl
shaders/material/gpu_shader_material_glass.glsl
shaders/material/gpu_shader_material_glossy.glsl
shaders/material/gpu_shader_material_hair_info.glsl
GPU: Make nodetree GLSL Codegen render engine agnostic This commit removes all EEVEE specific code from the `gpu_shader_material*.glsl` files. It defines a clear interface to evaluate the closure nodes leaving more flexibility to the render engine. Some of the long standing workaround are fixed: - bump mapping support is no longer duplicating a lot of node and is instead compiled into a function call. - bump rewiring to Normal socket is no longer needed as we now use a global `g_data.N` for that. Closure sampling with upstread weight eval is now supported if the engine needs it. This also makes all the material GLSL sources use `GPUSource` for better debugging experience. The `GPUFunction` parsing now happens in `GPUSource` creation. The whole `GPUCodegen` now uses the `ShaderCreateInfo` and is object type agnostic. Is has also been rewritten in C++. This patch changes a view behavior for EEVEE: - Mix shader node factor imput is now clamped. - Tangent Vector displacement behavior is now matching cycles. - The chosen BSDF used for SSR might change. - Hair shading may have very small changes on very large hairs when using hair polygon stripes. - ShaderToRGB node will remove any SSR and SSS form a shader. - SSS radius input now is no longer a scaling factor but defines an average radius. The SSS kernel "shape" (radii) are still defined by the socket default values. Appart from the listed changes no other regressions are expected.
2022-04-14 18:47:58 +02:00
shaders/material/gpu_shader_material_hair.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_holdout.glsl
shaders/material/gpu_shader_material_hue_sat_val.glsl
shaders/material/gpu_shader_material_invert.glsl
shaders/material/gpu_shader_material_layer_weight.glsl
shaders/material/gpu_shader_material_light_falloff.glsl
shaders/material/gpu_shader_material_light_path.glsl
shaders/material/gpu_shader_material_mapping.glsl
shaders/material/gpu_shader_material_map_range.glsl
Shader: Add Metallic BSDF Node Add Metallic BSDF Node to the shader editor. This node can primarily be used to create more realistic looking metallic materials than the existing Glossy BSDF node. This commit does not add any new closures to Cycles, it simply exposes existing closures that were previous hard to access on their own. - Exposes the F82 fresnel type that is currently used by the metallic component of the Principled BSDF. Results should match between the Metallic BSDF and Principled BSDF when using the same settings. - Exposes the Physical Conductor fresnel type that was previously limited to custom OSL scripts. The Conductor fresnel type accepts IOR and Extinction coefficients to define the appearance of the material based off real life measurements. EEVEE only supports the F82 fresnel type with internal code to convert the the physical conductor inputs in to a colour format for F82, which can lead to noticeable rendering differences with some configurations. Pull Request: https://projects.blender.org/blender/blender/pulls/114958
2024-08-27 17:20:46 +02:00
shaders/material/gpu_shader_material_metallic.glsl
Node: Mix node This patch is a response to T92588 and is implemented as a Function/Shader node. This node has support for Float, Vector and Color data types. For Vector it supports uniform and non-uniform mixing. For Color it now has the option to remove factor clamping. It replaces the Mix RGB for Shader and Geometry node trees. As discussed in T96219, this patch converts existing nodes in .blend files. The old node is still available in the Python API but hidden from the menus. Reviewed By: HooglyBoogly, JacquesLucke, simonthommes, brecht Maniphest Tasks: T92588 Differential Revision: https://developer.blender.org/D13749
2022-08-30 11:05:46 +01:00
shaders/material/gpu_shader_material_mix_color.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_mix_shader.glsl
shaders/material/gpu_shader_material_noise.glsl
shaders/material/gpu_shader_material_normal.glsl
shaders/material/gpu_shader_material_normal_map.glsl
shaders/material/gpu_shader_material_object_info.glsl
shaders/material/gpu_shader_material_output_aov.glsl
shaders/material/gpu_shader_material_output_material.glsl
shaders/material/gpu_shader_material_output_world.glsl
shaders/material/gpu_shader_material_particle_info.glsl
Cycles: add Point Info node With (center) position, radius and random value outputs. Eevee does not yet support rendering point clouds, but an untested implementation of this node was added for when it does. Ref T92573
2022-01-25 13:25:33 +01:00
shaders/material/gpu_shader_material_point_info.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_principled.glsl
Cycles: Ray Portal BSDF Transport rays that enter to another location in the scene, with specified ray position and normal. This may be used to render portals for visual effects, and other production rendering tricks. This acts much like a Transparent BSDF. Render passes are passed through, and this is affected by light path max transparent bounces. Pull Request: https://projects.blender.org/blender/blender/pulls/114386
2024-04-29 12:37:51 +02:00
shaders/material/gpu_shader_material_ray_portal.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_refraction.glsl
shaders/material/gpu_shader_material_rgb_to_bw.glsl
Nodes: Add Radial Tiling Node On its own, the main functionality of the Radial Tiling node is the ability to divide a 2D Cartesian coordinate system into as many radial segments as specified by the "Segments" input. Each segment has its own affinely transformed coordinate system, provided through the "Segment Coordinates" output, which can be used to tile textures in a radially symmetric manner. Additionally, a unique index is provided for every segment through the "Segment ID" output, the width of each segment at Y-coordinate of the "Segment Coordinates" output without normalization = 0 is provided through the "Segment Width" output and the rotation value of the affine transformation of the coordinate system of each segment is provided through the "Segment Rotation" output. The roundness of the coordinate lines of the "Segment Coordinates" output can be controlled through the "Roundness" inputs. This can be used to make the coordinate systems of the segments a mix of Cartesian and polar coordinates. Lastly, the lines of points of the "Segment Coordinates" output with constant Y-coordinates have the shape of polygon with rounded corners, which can be used to procedurally create rounded polygons. Pull Request: https://projects.blender.org/blender/blender/pulls/127711
2025-09-22 16:02:37 +02:00
shaders/material/gpu_shader_material_radial_tiling.glsl
shaders/material/gpu_shader_material_radial_tiling_shared.glsl
Nodes: Add general Combine/Separate Color nodes Inspired by D12936 and D12929, this patch adds general purpose "Combine Color" and "Separate Color" nodes to Geometry, Compositor, Shader and Texture nodes. - Within Geometry Nodes, it replaces the existing "Combine RGB" and "Separate RGB" nodes. - Within Compositor Nodes, it replaces the existing "Combine RGBA/HSVA/YCbCrA/YUVA" and "Separate RGBA/HSVA/YCbCrA/YUVA" nodes. - Within Texture Nodes, it replaces the existing "Combine RGBA" and "Separate RGBA" nodes. - Within Shader Nodes, it replaces the existing "Combine RGB/HSV" and "Separate RGB/HSV" nodes. Python addons have not been updated to the new nodes yet. **New shader code** In node_color.h, color.h and gpu_shader_material_color_util.glsl, missing methods hsl_to_rgb and rgb_to_hsl are added by directly converting existing C code. They always produce the same result. **Old code** As requested by T96219, old nodes still exist but are not displayed in the add menu. This means Python scripts can still create them as usual. Otherwise, versioning replaces the old nodes with the new nodes when opening .blend files. Differential Revision: https://developer.blender.org/D14034
2022-05-04 18:44:03 +02:00
shaders/material/gpu_shader_material_separate_color.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_separate_xyz.glsl
shaders/material/gpu_shader_material_set.glsl
shaders/material/gpu_shader_material_shader_to_rgba.glsl
Cycles: Update Velvet BSDF to Sheen BSDF with new Microfiber sheen model This patch extends the old Velvet BSDF node with a new shading model, and renames it to Sheen BSDF accordingly. The old model is still available, but new nodes now default to the "Microfiber" model, which is an implementation of https://tizianzeltner.com/projects/Zeltner2022Practical/. Pull Request: https://projects.blender.org/blender/blender/pulls/108869
2023-07-24 15:36:36 +02:00
shaders/material/gpu_shader_material_sheen.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_squeeze.glsl
shaders/material/gpu_shader_material_subsurface_scattering.glsl
shaders/material/gpu_shader_material_tangent.glsl
shaders/material/gpu_shader_material_tex_brick.glsl
shaders/material/gpu_shader_material_tex_checker.glsl
shaders/material/gpu_shader_material_tex_environment.glsl
Nodes: Implement Gabor noise This patch implements a new Gabor noise node based on [1] but with the improvements from [2] and the phasor formulation from [3]. We compare with the most popular existing implementation, that of OSL, from the user's point of view: - This implementation produces C1 continuous noise as opposed to the non continuous OSL implementation, so it can be used for bump mapping and is generally smother. This is achieved by windowing the Gabor kernel using a Hann window. - The Bandwidth input of OSL was hard-coded to 1 and was replaced with a frequency input, which OSL hard codes to 2, since frequency is more natural to control. This is even more true now that that Gabor kernel is windowed as opposed to truncated, which means increasing the bandwidth will just turn the Gaussian component of the Gabor into a Hann window. While decreasing the bandwidth will eliminate the harmonic from the Gabor kernel, which is the point of Gabor noise. - OSL had three discrete modes of operation for orienting the kernel. Anisotropic, Isotropic, and a hybrid mode. While this implementation provides a continuous Anisotropy parameter which users are already familiar with from the Glossy BSDF node. - This implementation provides not just the Gabor noise value, but also its phase and intensity components. The Gabor noise value is basically sin(phase) * intensity, but the phase is arguably more useful since it does not suffer from the low contrast issues that Gabor suffers from. While the intensity is useful to hide the singularities in the phase. - This implementation converges faster that OSL's relative to the impulse count, so we fix the impulses count to 8 for simplicitly. - This implementation does not implement anisotropic filtering. Future improvements to the node includes implementing surface noise and filtering. As well as extending the spectral control of the noise, either by providing specialized kernels as was done in #110802, or by providing some more procedural control over the frequencies of the Gabor. References: [1]: Lagae, Ares, et al. "Procedural noise using sparse Gabor convolution." ACM Transactions on Graphics (TOG) 28.3 (2009): 1-10. [2]: Tavernier, Vincent, et al. "Making gabor noise fast and normalized." Eurographics 2019-40th Annual Conference of the European Association for Computer Graphics. 2019. [3]: Tricard, Thibault, et al. "Procedural phasor noise." ACM Transactions on Graphics (TOG) 38.4 (2019): 1-13. Pull Request: https://projects.blender.org/blender/blender/pulls/121820
2024-06-19 09:33:32 +02:00
shaders/material/gpu_shader_material_tex_gabor.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_tex_gradient.glsl
shaders/material/gpu_shader_material_tex_image.glsl
shaders/material/gpu_shader_material_tex_magic.glsl
shaders/material/gpu_shader_material_tex_noise.glsl
shaders/material/gpu_shader_material_tex_sky.glsl
shaders/material/gpu_shader_material_texture_coordinates.glsl
shaders/material/gpu_shader_material_tex_voronoi.glsl
shaders/material/gpu_shader_material_tex_wave.glsl
shaders/material/gpu_shader_material_tex_white_noise.glsl
shaders/material/gpu_shader_material_toon.glsl
GPU: Move common shaders into a common directory This patch moves some of the utility library shaders into a common directory and makes the necessary renames across shaders. Additionally, material-specific transform functions were moved outside of math utils into a separate transform_utils.glsl file. This is needed in preparation for the viewport compositor, which will make use of some of those utilities and will require all material specific bit to be removed out of those files. Reviewed By: fclem Differential Revision: https://developer.blender.org/D14688
2022-05-06 12:58:14 +02:00
shaders/material/gpu_shader_material_transform_utils.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_translucent.glsl
shaders/material/gpu_shader_material_transparent.glsl
shaders/material/gpu_shader_material_uv_map.glsl
shaders/material/gpu_shader_material_vector_displacement.glsl
shaders/material/gpu_shader_material_vector_math.glsl
shaders/material/gpu_shader_material_vector_rotate.glsl
shaders/material/gpu_shader_material_vertex_color.glsl
shaders/material/gpu_shader_material_volume_absorption.glsl
shaders/material/gpu_shader_material_volume_principled.glsl
shaders/material/gpu_shader_material_volume_scatter.glsl
Shader: New Volume Coefficients Shader Add a new shader node to control volume coefficients (scattering, absorption and emission) directly, making it easier to model existing volumes with measured data. Pull Request: https://projects.blender.org/blender/blender/pulls/136287
2025-05-08 19:19:35 +02:00
shaders/material/gpu_shader_material_volume_coefficients.glsl
Nodes: add Fractal Voronoi Noise Fractal noise is the idea of evaluating the same noise function multiple times with different input parameters on each layer and then mixing the results. The individual layers are usually called octaves. The number of layers is controlled with a "Detail" slider. The "Lacunarity" input controls a factor by which each successive layer gets scaled. The existing Noise node already supports fractal noise. Now the Voronoi Noise node supports it as well. The node also has a new "Normalize" property that ensures that the output values stay in a [0.0, 1.0] range. That is except for the F2 feature where in rare cases the output may be outside that range even with "Normalize" turned on. How the individual octaves are mixed depends on the feature and output socket: - F1/Smooth F1/F2: - Distance/Color output: The individual Distance/Color octaves are first multiplied by a factor of `Roughness ^ (#layers - 1.0)` then added together to create the final output. - Position output: Each Position octave gets linearly interpolated with the combined output of the previous octaves. The Roughness input serves as an interpolation factor with 0.0 resutling in only using the combined output of the previous octaves and 1.0 resulting in only using the current highest octave. - Distance to Edge: - Distance output: The Distance octaves are mixed exactly like the Position octaves for F1/Smooth F1/F2. It should be noted that Voronoi Noise is a relatively slow noise function, especially at higher dimensions. Increasing the "Detail" makes it even slower. Therefore, when optimizing a scene one should consider trying to use simpler noise functions instead of Voronoi if the final result is close enough. Pull Request: https://projects.blender.org/blender/blender/pulls/106827
2023-06-13 09:18:12 +02:00
shaders/material/gpu_shader_material_voronoi.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/material/gpu_shader_material_wireframe.glsl
shaders/material/gpu_shader_material_world_normals.glsl
shaders/gpu_shader_gpencil_stroke_vert.glsl
shaders/gpu_shader_gpencil_stroke_frag.glsl
Fix: Cycles display without OpenColorIO not working for Metal Cycles fallback display shader previously did not use viewport. This would crash or cause the display not to show when using GPU backends other than OpenGL, if another display shader was unavailable. Now use ShaderCreateInfo for Cycles fallback display. Authored by Apple: Michael Parkin-White Ref #96261 Pull Request #104987
2023-02-23 14:25:08 +01:00
shaders/gpu_shader_display_fallback_vert.glsl
shaders/gpu_shader_display_fallback_frag.glsl
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
shaders/gpu_shader_cfg_world_clip_lib.glsl
shaders/gpu_shader_colorspace_lib.glsl
DRW: Curves: Indexbuf optimization for large numbers of curves This optimizes a few loops that become significant bottlenecks during viewport rendering of scenes with large numbers of curves. To render a curves object, Blender needs to generate a potentially very large (but trivial) index buffer. As previously implemented, this index buffer is generated in an extremely inefficient manner, with a single-threaded loop and an explicit function call per entry. The buffer then needs to be pushed onto the GPU, which is also a fairly slow task. The PR generates the index buffer directly on the GPU with compute shader. Pull Request: https://projects.blender.org/blender/blender/pulls/116617
2024-02-25 17:22:58 +01:00
shaders/gpu_shader_index_2d_array_points.glsl
shaders/gpu_shader_index_2d_array_lines.glsl
shaders/gpu_shader_index_2d_array_tris.glsl
GPU: Add Math libraries to GPU shaders code This implement most of the functions provided by the BLI math library. This is part of the effort to unify GLSL and C++ syntax. Ref T103026. This also adds some infrastructure to make it possible to run GLSL shader unit test. Some code already present in other libs is being copied to the new libs. This patch does not make use of the new libs outside of the tests. Note that the test is still crashing when using metal.
2023-01-06 22:22:11 +01:00
GPU: Split GLSL, C++ and metal shader defines This makes all the defines and boiler plate code use the generated source include system. This makes source hierarchy more understandable. Pull Request: https://projects.blender.org/blender/blender/pulls/146289
2025-09-15 17:22:19 +02:00
shaders/gpu_shader_compat_glsl.glsl
shaders/gpu_shader_glsl_extension.glsl
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
GPU_shader_shared_utils.hh
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
)
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
set(GLSL_SRC_TEST
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
shaders/infos/gpu_shader_test_infos.hh
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
tests/shaders/gpu_math_test.glsl
Vulkan: Add Support For Texture Buffers Texture buffers are vbos that can be sampled as textures inside shaders. This adds support for them to the Vulkan Backend. Pull Request: https://projects.blender.org/blender/blender/pulls/108193
2023-05-30 13:54:51 +02:00
tests/shaders/gpu_buffer_texture_test.glsl
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
tests/shaders/gpu_compute_1d_test.glsl
tests/shaders/gpu_compute_2d_test.glsl
tests/shaders/gpu_compute_ibo_test.glsl
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
tests/shaders/gpu_compute_ssbo_test.glsl
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
tests/shaders/gpu_compute_vbo_test.glsl
GPU: Add SSBO binding test to new structure. This test was added to test the shader info structure binding information for SSBOs. It still used the legacy GLSL structure.
2023-01-30 19:07:33 +01:00
tests/shaders/gpu_compute_dummy_test.glsl
GPU: Add Shader specialization constant API Adds API to allow usage of specialization constants in shaders. Specialization constants are dynamic runtime constants which can be compiled into a shader pipeline state object (PSO) to improve runtime performance by reducing shader complexity through shader compiler constant-folding. This API allows specialization constant values to be specified along with a default value if no constant value has been declared. Each GPU backend is then responsible for caching PSO permutations against the current specialization configuration. This patch adds support for specialization constants in the Metal backend and provides a generalised high-level solution which can be adopted by other graphics APIs supporting this feature. Authored by Apple: Michael Parkin-White Authored by Blender: Clément Foucault (files in gpu/test folder) Pull Request: https://projects.blender.org/blender/blender/pulls/115193
2023-12-28 05:34:38 +01:00
tests/shaders/gpu_specialization_test.glsl
GPU: Framebuffer: Add multi viewport support This add the possibility to define different viewports inside a single framebuffer and let the vertex shader decide which viewport to render to. This only contain the GL and VK implementation. The Vulkan implementation works but still has a validation error related to shader features and extension. The test passes nonetheless. Pull Request: https://projects.blender.org/blender/blender/pulls/110923
2023-08-08 17:12:49 +02:00
tests/shaders/gpu_framebuffer_layer_viewport_test.glsl
GPU: Rename ROG to SubpassInput, add tests and documentation This is in order to follow the vulkan terminology like the rest of the module. Other implementations (GL, VK) are not supposed to work yet. Pull Request: https://projects.blender.org/blender/blender/pulls/112026
2023-09-06 14:39:38 +02:00
tests/shaders/gpu_framebuffer_subpass_input_test.glsl
Vulkan: Push constants **What are push constants?** Push constants is a way to quickly provide a small amount of uniform data to shaders. It should be much quicker than UBOs but a huge limitation is the size of data - spec requires 128 bytes to be available for a push constant range. **What are the challenges with push constants?** The challenge with push constants is that the limited available size. According to the Vulkan spec each platform should at least have 128 bytes reserved for push constants. Current Mesa/AMD drivers supports 256 bytes, but Mesa/Intel is only 128 bytes. **What is our solution?** Some shaders of Blender uses more than these boundaries. When more data is needed push constants will not be used, but the shader will be patched to use an uniform buffer instead. This mechanism will be part of the Vulkan backend and shader developers should not see any difference on API level. **Known limitations** Current state of the vulkan backend does not track resources that are in the command queue. This patch includes some test cases that identified this issue as well. See #104771. Pull Request #104880
2023-03-06 12:28:55 +01:00
tests/shaders/gpu_push_constants_test.glsl
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
)
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
set(MTL_BACKEND_GLSL_SRC
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
metal/kernels/depth_2d_update_infos.hh
metal/kernels/gpu_shader_fullscreen_blit_infos.hh
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
metal/kernels/depth_2d_update_float_frag.glsl
metal/kernels/depth_2d_update_int24_frag.glsl
metal/kernels/depth_2d_update_int32_frag.glsl
metal/kernels/depth_2d_update_vert.glsl
metal/kernels/gpu_shader_fullscreen_blit_vert.glsl
metal/kernels/gpu_shader_fullscreen_blit_frag.glsl
GPU: Split GLSL, C++ and metal shader defines This makes all the defines and boiler plate code use the generated source include system. This makes source hierarchy more understandable. Pull Request: https://projects.blender.org/blender/blender/pulls/146289
2025-09-15 17:22:19 +02:00
shaders/gpu_shader_msl_atomic.msl
shaders/gpu_shader_msl_attribute.msl
shaders/gpu_shader_msl_builtin.msl
shaders/gpu_shader_msl_image.msl
shaders/gpu_shader_msl_matrix_legacy.msl
shaders/gpu_shader_msl_matrix.msl
shaders/gpu_shader_msl_sampler.msl
shaders/gpu_shader_msl_types_legacy.msl
shaders/gpu_shader_msl_defines.msl
shaders/gpu_shader_compat_msl.msl
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
)
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
set(MSL_SRC
Cleanup: Metal: DeDuplicate sources in Cmakefile
2025-04-17 01:04:16 +02:00
metal/mtl_shader_shared.hh
metal/kernels/compute_texture_update.msl
metal/kernels/compute_texture_read.msl
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
)
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
set(VULKAN_BACKEND_GLSL_SRC
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
vulkan/shaders/vk_backbuffer_blit_infos.hh
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
vulkan/shaders/vk_backbuffer_blit_comp.glsl
)
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
if(WITH_GTESTS)
GPU: Split GPU backend and Draw manager unit tests Both the draw manager and gpu backend used the same compilation directive for enablement. This PR seperates them into `WITH_GPU_DRAW_TESTS` for draw manager related tests and `WITH_GPU_BACKEND_TESTS` for gpu backend related tests. Pull Request: https://projects.blender.org/blender/blender/pulls/132018
2024-12-17 13:28:21 +01:00
if(WITH_GPU_BACKEND_TESTS)
GPU: Only compile test shaders when test cases option is enabled. The glsl files + create infos of shaders that are only used during development where still being compiled into blender. This isn't needed and shouldn't be included. This change will only include them when WITH_GTEST and WITH_OPENGL_DRAW_TESTS are enabled. All other cases those files will be skipped.
2023-01-30 15:43:49 +01:00
list(APPEND GLSL_SRC ${GLSL_SRC_TEST})
endif()
endif()
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
if(WITH_METAL_BACKEND)
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
list(APPEND GLSL_SRC ${MTL_BACKEND_GLSL_SRC})
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
set(MSL_C)
foreach(MSL_FILE ${MSL_SRC})
GPU: GLSL Preprocess: Always remove quotes We cannot do this for the MSL files. Also they are written in MSL which should not be processed. So use datatoc for them. Also add quote linting for GLSL files.
2024-10-16 08:59:36 +02:00
data_to_c_simple(${MSL_FILE} MSL_C)
Metal: MTLTexture core implementation for Metal backend, with minimal surrounding functionality. This covers implementation of the GPUTexture abstraction for the Metal backend, with additional utility functionality as required. Some components have been temporarily disabled pending dependencies on upcoming Metal backend components, and these will be addressed as the backend is fleshed out. One core challenge addressed in the Metal backend is the requirement for read/update routines for textures. MTLBlitCommandEncoders offer a limited range of the full functionality provided by OpenGLs texture update and read functions such that a series of compute kernels have been implemented to provide advanced functionality such as data format conversion and partial/swizzled component updates. This diff is provided in full, but if further division is required for purposes of code review, this can be done. Authored by Apple: Michael Parkin-White Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14543
2022-04-27 12:34:57 +02:00
endforeach()
endif()
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
if(WITH_VULKAN_BACKEND)
list(APPEND GLSL_SRC ${VULKAN_BACKEND_GLSL_SRC})
endif()
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
set(GLSL_C)
foreach(GLSL_FILE ${GLSL_SRC})
GPU: Add GLSL preprocessor This splits the GLSL processing into its own file as it will grow in complexity. Removes the complexity from `datatoc` and chain them during the build process. Rel #128076 Pull Request: https://projects.blender.org/blender/blender/pulls/128261
2024-10-04 11:33:21 +02:00
glsl_to_c(${GLSL_FILE} GLSL_C)
DRW: New Curve Drawing Implementation of the design task #142969. This adds the following: - Exact GPU interpolation of curves of all types. - Radius attribute support. - Cyclic curve support. - Resolution attribute support. - New Cylinder hair shape type. ![image.png](/attachments/a8e7aea0-b0e5-4694-b660-89fb3df1ddcd) What changed: - EEVEE doesn't compute random normals for strand hairs anymore. These are considered legacy now. - EEVEE now have an internal shadow bias to avoid self shadowing on hair. - Workbench Curves Strip display option is no longer flat and has better shading. - Legacy Hair particle system evaluates radius at control points before applying additional subdivision. This now matches Cycles. - Color Attribute Node without a name do not fetch the active color attribute anymore. This now matches Cycles. Notes: - This is not 100% matching the CPU implementation for interpolation (see the epsilons in the tests). - Legacy Hair Particle points is now stored in local space after interpolation. The new cylinder shape allows for more correct hair shading in workbench and better intersection in EEVEE. | | Strand | Strip | Cylinder | | ---- | --- | --- | --- | | Main | ![main_strand.png](/attachments/67d3b792-962c-4272-a92c-1c0c7c6cf8de) | ![main_strip.png](/attachments/f2aa3575-368e-4fbb-b888-74df845918f1) | N/A | | PR | ![pr_strand.png](/attachments/cc012483-25f0-491f-a06e-ad3029981d47) | ![pr_strip.png](/attachments/73fa2f5c-5252-4b30-a334-e935ed0fb938) | ![pr_cylinder.png](/attachments/3133b2d4-a6f2-41ee-8e2d-f6fd00db0c8d) | | | Strand | Strip | Cylinder | | ---- | --- | --- | --- | | Main | ![main_strand_closeup.png](/attachments/730bd79c-6762-446d-819b-3ea47961ff9f) |![main_strip_closeup.png](/attachments/d9ace578-cfeb-4895-9896-3625b6ad7a02) | N/A | | PR | ![pr_strand_closeup.png](/attachments/ac8f3b0c-6ef6-4d54-b714-6322f9865036)|![pr_strip_closeup.png](/attachments/8504711a-955b-4ab2-aa3d-c2d114baf9d4)| ![pr_cylinder_closeup.png](/attachments/1e2899a8-0a5c-431f-ac6c-5184d87e9598) | Cyclic Curve, Mixed curve type, and proper radius support: ![image.png](/attachments/7f0bf05e-62ee-4ae9-aef9-a5599249b8d7) Test file for attribute lookup: [test_attribute_lookup.blend](/attachments/1d54dd06-379b-4480-a1c5-96adc1953f77) Follow Up Tasks: - Correct full tube segments orientation based on tangent and normal attributes - Correct V resolution property per object - More attribute type support (currently only color) TODO: - [x] Attribute Loading Changes - [x] Generic Attributes - [x] Length Attribute - [x] Intercept Attribute - [x] Original Coordinate Attribute - [x] Cyclic Curves - [x] Legacy Hair Particle conversion - [x] Attribute Loading - [x] Additional Subdivision - [x] Move some function to generic headers (VertBuf, OffsetIndices) - [x] Fix default UV/Color attribute assignment Pull Request: https://projects.blender.org/blender/blender/pulls/143180
2025-08-27 09:49:43 +02:00
endforeach()
Metal: MTLShader and MTLShaderGenerator implementation. Full support for translation and compilation of shaders in Metal, using GPUShaderCreateInfo. Includes render pipeline state creation and management, enabling all standard GPU viewport rendering features in Metal. Authored by Apple: Michael Parkin-White, Marco Giordano Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D15563
2022-09-01 22:22:32 +02:00
set(SHADER_C)
list(APPEND SHADER_C ${GLSL_C})
if(WITH_METAL_BACKEND)
list(APPEND SHADER_C ${MSL_C})
endif()
blender_add_lib(bf_gpu_shaders "${SHADER_C}" "" "" "")
Build: Add WITH_OPTIMIZED_BUILD_TOOLS Enable optimizations on Debug builds for executables used for the build process (datatoc and glsl_preprocess) and enable unity builds for shader preprocessing targets. Debug: From 28.9s to 5.7s Release: From 4.9s to 3.5s Pull Request: https://projects.blender.org/blender/blender/pulls/138274
2025-05-02 18:33:44 +02:00
blender_set_target_unity_build(bf_gpu_shaders 10)
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
list(APPEND LIB
bf_gpu_shaders
)
DRW: Refactor to support draw call batching Reviewers: brecht Differential Revision: D4997
2019-05-31 01:45:41 +02:00
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
set(GLSL_SOURCE_CONTENT "")
GPU: Remove runtime parsing of GLSL source See #129009 for context. The preprocessor parses metadata and writes a header file containing an inline function that inits the `GPUSource` with the metadata. These header files are then included inside `gpu_shader_dependency.cc`. This still keep the usage of the `metadata` enums and classes to avoid pulling the whole blender module inside the preprocessor executable. This speeds-up startup time in Debug build: `gpu_shader_dependency_init` - Before : 37ms - After : 4ms I didn't measure release, but it is unlikely to be noticeable (in the order of 4ms > 1ms). Pull Request: https://projects.blender.org/blender/blender/pulls/138070
2025-04-29 15:32:36 +02:00
set(GLSL_METADATA_CONTENT "")
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
set(GLSL_INFOS_CONTENT "")
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
foreach(GLSL_FILE ${GLSL_SRC})
get_filename_component(GLSL_FILE_NAME ${GLSL_FILE} NAME)
string(REPLACE "." "_" GLSL_FILE_NAME_UNDERSCORES ${GLSL_FILE_NAME})
GPU: Remove runtime parsing of GLSL source See #129009 for context. The preprocessor parses metadata and writes a header file containing an inline function that inits the `GPUSource` with the metadata. These header files are then included inside `gpu_shader_dependency.cc`. This still keep the usage of the `metadata` enums and classes to avoid pulling the whole blender module inside the preprocessor executable. This speeds-up startup time in Debug build: `gpu_shader_dependency_init` - Before : 37ms - After : 4ms I didn't measure release, but it is unlikely to be noticeable (in the order of 4ms > 1ms). Pull Request: https://projects.blender.org/blender/blender/pulls/138070
2025-04-29 15:32:36 +02:00
string(APPEND GLSL_SOURCE_CONTENT "SHADER_SOURCE\(${GLSL_FILE_NAME_UNDERSCORES}, \"${GLSL_FILE_NAME}\", \"${GLSL_FILE}\"\)\n")
string(APPEND GLSL_METADATA_CONTENT "#include \"${GLSL_FILE}.hh\"\n")
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
string(APPEND GLSL_INFOS_CONTENT "#include \"${GLSL_FILE}.info\"\n")
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
endforeach()
set(glsl_source_list_file "${CMAKE_CURRENT_BINARY_DIR}/glsl_gpu_source_list.h")
file(GENERATE OUTPUT ${glsl_source_list_file} CONTENT "${GLSL_SOURCE_CONTENT}")
list(APPEND SRC ${glsl_source_list_file})
GPU: Remove runtime parsing of GLSL source See #129009 for context. The preprocessor parses metadata and writes a header file containing an inline function that inits the `GPUSource` with the metadata. These header files are then included inside `gpu_shader_dependency.cc`. This still keep the usage of the `metadata` enums and classes to avoid pulling the whole blender module inside the preprocessor executable. This speeds-up startup time in Debug build: `gpu_shader_dependency_init` - Before : 37ms - After : 4ms I didn't measure release, but it is unlikely to be noticeable (in the order of 4ms > 1ms). Pull Request: https://projects.blender.org/blender/blender/pulls/138070
2025-04-29 15:32:36 +02:00
set(glsl_metadata_list_file "${CMAKE_CURRENT_BINARY_DIR}/glsl_gpu_metadata_list.hh")
file(GENERATE OUTPUT ${glsl_metadata_list_file} CONTENT "${GLSL_METADATA_CONTENT}")
list(APPEND SRC ${glsl_metadata_list_file})
GPU: Shader: Make info files generated This is the first step of moving the create infos back inside shader sources. All info files are now treated as source files. However, they are not considered in the include tree yet. This will come in another following PR. Each shader source file now generate a `.info` file containing only the create info declarations. This renames all info files so that they do not conflict with their previous versions that were copied (non-generated). Pull Request: https://projects.blender.org/blender/blender/pulls/146676
2025-09-25 10:57:02 +02:00
set(glsl_infos_list_file "${CMAKE_CURRENT_BINARY_DIR}/glsl_gpu_infos_list.hh")
file(GENERATE OUTPUT ${glsl_infos_list_file} CONTENT "${GLSL_INFOS_CONTENT}")
list(APPEND SRC ${glsl_infos_list_file})
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
list(APPEND INC ${CMAKE_CURRENT_BINARY_DIR})
Mantaflow [Part 6]: Updates in /blender/source A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming. Reviewed By: sergey Maniphest Tasks: T59995 Differential Revision: https://developer.blender.org/D3855
2019-12-16 15:50:14 +01:00
if(WITH_MOD_FLUID)
add_definitions(-DWITH_FLUID)
cmake option to build without smoke sim: WITH_MOD_SMOKE
2011-07-13 18:40:21 +00:00
endif()
SubDiv: Use shader create info for patch evaluation shader This PR migrates the subdiv_patch_evaluation_comp.glsl to use shader create info. The part of OSD that is used is included as a typedef source (osd_patch_basis.glsl). Pull Request: https://projects.blender.org/blender/blender/pulls/134917
2025-02-27 15:42:08 +01:00
if(WITH_OPENSUBDIV)
add_definitions(-DWITH_OPENSUBDIV)
endif()
GPU: Split GPU backend and Draw manager unit tests Both the draw manager and gpu backend used the same compilation directive for enablement. This PR seperates them into `WITH_GPU_DRAW_TESTS` for draw manager related tests and `WITH_GPU_BACKEND_TESTS` for gpu backend related tests. Pull Request: https://projects.blender.org/blender/blender/pulls/132018
2024-12-17 13:28:21 +01:00
if(WITH_GPU_BACKEND_TESTS)
add_definitions(-DWITH_GPU_BACKEND_TESTS)
Fix: GPU: Tests not passing on Metal with ASAN on Fixes a few stack overflow error, reduce framebuffer size to avoid errors flooding the output.
2024-11-09 19:09:49 +01:00
endif()
CMake: Add WITH_TBB definition to prevent ODR violation for BLI_spin API The BLI_spin APIs use a `SpinLock` typedef whose underlying type is contingent on the precense of `WITH_TBB`. Since our projects did not consistently define the `WITH_TBB` definition, multiple `SpinLock` types would end up in our final binary creating ODR violations. Pull Request: https://projects.blender.org/blender/blender/pulls/124285
2024-07-10 23:02:17 +02:00
GPU: Missing create info when running tests When running tests `WITH_GTESTS` and `WITH_GPU_DRAW_TESTS` the GPUShaderCreateInfo's specfically created for the tests could not be found. This failed running tests on any backend. This PR fixes this. The root cause what that the name of the compile directive was incorrect. It should have been `WITH_GTESTS` but was `WITH_GTEST`. Pull Request: https://projects.blender.org/blender/blender/pulls/131956
2024-12-16 09:58:42 +01:00
if(WITH_GTESTS)
add_definitions(-DWITH_GTESTS)
Fix: GPU: Asserts when building WITH_GPU_DRAW_TESTS but without WITH_GTEST
2024-11-26 22:39:13 +01:00
endif()
CMake: prepare for BLENDER_SORTED_LIBS removal No functional change, this adds LIB definition and args to cmake files. Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS' since there are many platforms/configurations that could break when changing linking order. Manually add and enable WITHOUT_SORTED_LIBS to try building without sorted libs (currently fails since all variables are empty). This check will eventually be removed. See T46725.
2019-04-14 15:18:44 +02:00
blender_add_lib(bf_gpu "${SRC}" "${INC}" "${INC_SYS}" "${LIB}")
Cleanup: CMake: Modernize bf_gpu dependencies Pretty straightforward - Remove any bf_gpu paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/132286
2024-12-23 21:38:19 +01:00
add_library(bf::gpu ALIAS bf_gpu)
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
target_link_libraries(bf_gpu PUBLIC
Realtime Compositor: Move shaders to compositor module This patch moves the GLSL shaders and their infos to the compositor module as decided by the EEVEE & Viewport module. This is a non functional change. Differential Revision: https://developer.blender.org/D16360 Reviewed By: Clement Foucault
2022-11-02 13:55:23 +02:00
bf_compositor_shaders
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
bf_draw_shaders
bf_gpu_shaders
Refactor: OpenColorIO integration Briefly about this change: - OpenColorIO C-API is removed. - The information about color spaces in ImBuf module is removed. It was stored in global ListBase in colormanagement.cc. - Both OpenColorIO and fallback implementation supports GPU drawing. - Fallback implementation supports white point, RGB curves, etc. - Removed check for support of GPU drawing in IMB. Historically it was implemented in a separate library with C-API, this is because way back C++ code needed to stay in intern. This causes all sort of overheads, and even calls that are strictly considered bad level. This change moves OpenColorIO integration into a module within imbuf, next to movie, and next to IMB_colormanagement which is the main user of it. This allows to avoid copy of color spaces, displays, views etc in the ImBuf: they were used to help quickly querying information to be shown on the interface. With this change it can be stored in the same data structures as what is used by the OpenColorIO integration. While it might not be fully avoiding duplication it is now less, and there is no need in the user code to maintain the copies. In a lot of cases this change also avoids allocations done per access to the OpenColorIO. For example, it is not needed anymore to allocate image descriptor in a heap. The bigger user-visible change is that the fallback implementation now supports GLSL drawing, with the whole list of supported features, such as curve mapping and white point. This should help simplifying code which relies on color space conversion on GPU: there is no need to figure out fallback solution in such cases. The only case when drawing will not work is when there is some actual bug, or driver issue, and shader has failed to compile. The change avoids having an opaque type for color space, and instead uses forward declaration. It is a bit verbose on declaration, but helps avoiding unsafe type-casts. There are ways to solve this in the future, like having a header for forward declaration, or to flatten the name space a bit. There should be no user-level changes under normal operation. When building without OpenColorIO or the configuration has a typo or is missing a fuller set of color management tools is applies (such as the white point correction). Pull Request: https://projects.blender.org/blender/blender/pulls/138433
2025-05-09 14:01:43 +02:00
bf_imbuf_opencolorio_shaders
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
)
GPU: Extract GPU Base Test case The draw manager test case initialized ghost, gpu and draw manager. This change splits the base test case to GPU specific and draw manager specific test case. The GPU test base test case will be used for low level GPU tests.
2020-09-08 11:31:47 +02:00
Build: Only link to librt on Linux The code that uses this is within #ifdef __linux__. This fixes a build failure on OpenBSD where this library does not exist. Pull Request: https://projects.blender.org/blender/blender/pulls/143682
2025-08-08 15:23:42 +02:00
if(WITH_OPENGL_BACKEND AND CMAKE_SYSTEM_NAME STREQUAL "Linux")
Cleanup: correct indentation for CMake files, strip trailing space
2025-01-03 13:23:38 +11:00
target_link_libraries(bf_gpu PUBLIC rt)
GPU: Add GPU_shader_batch_create_from_infos This is the first commit of the several required to support subprocess-based parallel compilation on OpenGL. This provides the base API and implementation, and exposes the max subprocesses setting on the UI, but it's not used by any code yet. More information and the rest of the code can be found in #121925. This one includes: - A new `GPU_shader_batch` API that allows requesting the compilation of multiple shaders at once, allowing GPU backed to compile them in parallel and asynchronously without blocking the Blender UI. - A virtual `ShaderCompiler` class that backends can use to add their own implementation. - A `ShaderCompilerGeneric` class that implements synchronous/blocking compilation of batches for backends that don't have their own implementation yet. - A `GLShaderCompiler` that supports parallel compilation using subprocesses. - A new `BLI_subprocess` API, including IPC (required for the `GLShaderCompiler` implementation). - The implementation of the subprocess program in `GPU_compilation_subprocess`. - A new `Max Shader Compilation Subprocesses` option in `Preferences > System > Memory & Limits` to enable parallel shader compilation and the max number of subprocesses to allocate (each subprocess has a relatively high memory footprint). Implementation Overview: There's a single `GLShaderCompiler` shared by all OpenGL contexts. This class stores a pool of up to `GCaps.max_parallel_compilations` subprocesses that can be used for compilation. Each subprocess has a shared memory pool used for sending the shader source code from the main Blender process and for receiving the already compiled shader binary from the subprocess. This is synchronized using a series of shared semaphores. The subprocesses maintain a shader cache on disk inside a `BLENDER_SHADER_CACHE` folder at the OS temporary folder. Shaders that fail to compile are tried to be compiled again locally for proper error reports. Hanged subprocesses are currently detected using a timeout of 30s. Pull Request: https://projects.blender.org/blender/blender/pulls/122232
2024-06-05 18:45:57 +02:00
endif()
Build: resolve linking error on *BSD systems Ref !144247
2025-09-02 04:04:20 +00:00
# If `execinfo.h` exists on a *BSD system then also link in `libexecinfo`.
# Needed for `backtrace` / `backtrace_symbols` (GNU extensions)
# brought in by `blenlib/intern/system.cc`.
if(HAVE_EXECINFO_H AND CMAKE_SYSTEM_NAME MATCHES "FreeBSD|NetBSD|OpenBSD|DragonFly")
target_link_libraries(bf_gpu PUBLIC execinfo)
endif()
SubDiv: Migrate GPU subdivision to use GPU module Blender already had its own copy of OpenSubDiv containing some local fixes and code-style. This code still used gl-calls. This PR updates the calls to use GPU module. This allows us to use OpenSubDiv to be usable on other backends as well. This PR was tested on OpenGL, Vulkan and Metal. Metal can be enabled, but Vulkan requires some API changes to work with loose geometry. ![metal.png](/attachments/bb042c3a-1a87-4140-9958-a80da10d417b) # Considerations **ShaderCreateInfo** intern/opensubdiv now requires access to GPU module. This to create buffers in the correct context and trigger correct dispatches. ShaderCreateInfo is used to construct the shader for cross compilation to Metal/Vulkan. However opensubdiv shader caching structures are still used. **Vertex buffers vs storage buffers** Implementation tries to keep as close to the original OSD implementation. If they used storage buffers for data, we will use GPUStorageBuf. If it uses vertex buffers, we will use gpu::VertBuf. **Evaluator const** The evaluator cannot be const anymore as the GPU module API only allows updating SSBOs when constructing. API could be improved to support updating SSBOs. Current implementation has a change to use reads out of bounds when constructing SSBOs. An API change is in the planning to remove this issue. This will be fixed in an upcoming PR. We wanted to land this PR as the visibility of the issue is not common and multiple other changes rely on this PR to land. Pull Request: https://projects.blender.org/blender/blender/pulls/135296
2025-03-10 07:31:59 +01:00
if(WITH_OPENSUBDIV)
target_link_libraries(bf_gpu PUBLIC bf_osd_shaders)
endif()
GPU: Renderdoc Frame Capturing This PR uses renderdoc for frame capturing when enabled. It enabled an easier workflow for frame capturing. - Capture GPU API calls from test cases - Capture GPU API calls from background threads - Capture GPU API calls from background rendering. Renderdoc is an important GPU debugger used by the Eevee/ Viewport module. Previously we needed to change code in order to record background rendering, that could on its own lead to other side-effects. The integration with renderdoc can be enabled using `WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin` and `GPU_debug_capture_end` can be added to the section of the code you want to debug. When running Blender inside renderdoc this part will automatically be captured. All GPU test cases are now guarded by these calls. In order to capture the test cases you need to start the test cases from renderdoc and the captured GPU API calls will appear where each capture is a single test case. Pull Request: https://projects.blender.org/blender/blender/pulls/105921
2023-03-23 16:37:52 +01:00
if(WITH_RENDERDOC)
target_link_libraries(bf_gpu PUBLIC bf_intern_renderdoc_dynload)
endif()
OCIO: Port shader creation logic to use GPUShaderCreateInfo This commit should suffice to make the shader API agnostic now (given that all users of it use the GPU API). This makes the shaders not trigger a false positive error anymore since the binding slots are now garanteed by the backend and not changed at after compilation. This also bundles all uniforms into UBOs. Making them extendable without limitations of push constants. The generated uniforms from OCIO are not densely packed in the UBO to avoid complexity. Another approach would be to use GPU_uniformbuf_create_from_list but this requires converting uniforms to GPUInputs which is too complex for what it is. Reviewed by: brecht, jbakker Differential Revision: https://developer.blender.org/D14123
2022-02-17 17:03:23 +01:00
macOS: Fix unknown -Wsuggest-override warning Added in rB7cef01b090c4c2d2703274edb91886ae37d3ce82 and rB87bfa2b207b90b5e34ebd835a23c2a82afbed878 Reviewed by: jbakker, #platform_macos Differential Revision: https://developer.blender.org/D11012
2021-04-24 01:54:30 +05:30
if(CXX_WARN_NO_SUGGEST_OVERRIDE)
GPU: Enable suggest-override for CPP.
2021-04-09 13:07:21 +02:00
target_compile_options(bf_gpu PRIVATE $<$<COMPILE_LANGUAGE:CXX>:-Wsuggest-override>)
endif()
Revert "Revert "GPUShaderCreateInfo for interface abstraction"" This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17 14:45:22 +01:00
GPU: Extract GPU Base Test case The draw manager test case initialized ghost, gpu and draw manager. This change splits the base test case to GPU specific and draw manager specific test case. The GPU test base test case will be used for low level GPU tests.
2020-09-08 11:31:47 +02:00
if(WITH_GTESTS)
Vulkan: Enable Tests Not Relying on a Context Some test cases inside the vulkan backend don't rely on an initialized Vulkan Context and can always be run. This PR enables those test cases when `WITH_GTEST` and `WITH_VULKAN_BACKEND` is on. Allowing some tests to run on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/114574
2023-11-24 13:27:41 +01:00
set(TEST_SRC)
set(TEST_INC)
Tests: add option to build one binary per GTest file Bundling many tests in a single binary reduces build time and disk space usage, but is less convenient for running individual tests command line as filter flags need to be used. This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per source file. Note that enabling this option requires a significant amount of disk space. Due to refactoring, the resulting ctest names are a bit different than before. The number of tests is also a bit different depending if this option is used, as one uses gtests discovery and the other is organized purely by filename, which isn't always 1:1. Co-authored-by: Sergey Sharybin <sergey@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/114604
2024-01-03 18:35:50 +01:00
set(TEST_LIB
bf_intern_ghost
bf_imbuf
bf_windowmanager
)
Vulkan: Enable Tests Not Relying on a Context Some test cases inside the vulkan backend don't rely on an initialized Vulkan Context and can always be run. This PR enables those test cases when `WITH_GTEST` and `WITH_VULKAN_BACKEND` is on. Allowing some tests to run on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/114574
2023-11-24 13:27:41 +01:00
GPU: Split GPU backend and Draw manager unit tests Both the draw manager and gpu backend used the same compilation directive for enablement. This PR seperates them into `WITH_GPU_DRAW_TESTS` for draw manager related tests and `WITH_GPU_BACKEND_TESTS` for gpu backend related tests. Pull Request: https://projects.blender.org/blender/blender/pulls/132018
2024-12-17 13:28:21 +01:00
if(WITH_GPU_BACKEND_TESTS)
Vulkan: Enable Tests Not Relying on a Context Some test cases inside the vulkan backend don't rely on an initialized Vulkan Context and can always be run. This PR enables those test cases when `WITH_GTEST` and `WITH_VULKAN_BACKEND` is on. Allowing some tests to run on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/114574
2023-11-24 13:27:41 +01:00
list(APPEND TEST_SRC
Vulkan: Add Support For Texture Buffers Texture buffers are vbos that can be sampled as textures inside shaders. This adds support for them to the Vulkan Backend. Pull Request: https://projects.blender.org/blender/blender/pulls/108193
2023-05-30 13:54:51 +02:00
tests/buffer_texture_test.cc
Vulkan: Indirect Compute This PR adds support for indirect compute. Indirect compute is almost the same as regular compute. The only difference is that the parameters for the compute dispatch isn't passed as a parameter, but that these parameters are part of a buffer. Pull Request: https://projects.blender.org/blender/blender/pulls/108879
2023-06-12 14:56:38 +02:00
tests/compute_test.cc
Vulkan: Clearing Framebuffer + Scissors This PR adds support for clearing framebuffers and scissor testing. Tweaks had to be made to VKTexture to keep track of its layout on the device. Based on the actual call the layout can switch to a more optimum layout. For example during upload of a texture the texture will be converted to a transfer destination optimized layout. When reading from the texture it will be converted to a transfer source optimized layout. The order of the attachments in the framebuffer follows the next rules - When only color attachments are there the color attachments will be placed in the slot they are defined. This way it will match the ShaderCreateInfo binding location. - When a stencil/depth attachment is added it will be placed right after the color attachments. When there isn't a color attachment it will be the first attachment. Pull Request: https://projects.blender.org/blender/blender/pulls/106044
2023-03-28 11:51:32 +02:00
tests/framebuffer_test.cc
GPU: Added Tests For Blend state And Immediate Mode This PR adds several tests to GTest for testing blend states and immediate mode. The immediate mode test are basic and will be extended in the near future. The tests have been developed in order to get the first pixel on screen for the Vulkan backend. In the first phase of this goal we had to validate that everything was working as expected without being able to validate it by starting Blender. Pull Request: https://projects.blender.org/blender/blender/pulls/107834
2023-05-11 09:15:39 +02:00
tests/immediate_test.cc
Cleanup: Remove gpu prefix in gpu test cases. The _gpu_ prefix is redundant as they are inside a namespace and run as part of a test suite that already contain the name gpu. (GPUOpenGLTest) This patch also moved the texture test cases to its own compile module.
2023-03-13 11:12:05 +01:00
tests/index_buffer_test.cc
tests/push_constants_test.cc
Cleanup: sort cmake file lists
2024-01-09 12:17:12 +11:00
tests/shader_create_info_test.cc
GPU: Shader Preprocess: Add string utilities Allow faster and more robust parsing / mutation.
2025-05-05 10:53:42 +02:00
tests/shader_preprocess_test.cc
Cleanup: sort CMake file lists
2025-06-14 15:57:33 +10:00
tests/shader_test.cc
GPU: Add Shader specialization constant API Adds API to allow usage of specialization constants in shaders. Specialization constants are dynamic runtime constants which can be compiled into a shader pipeline state object (PSO) to improve runtime performance by reducing shader complexity through shader compiler constant-folding. This API allows specialization constant values to be specified along with a default value if no constant value has been declared. Each GPU backend is then responsible for caching PSO permutations against the current specialization configuration. This patch adds support for specialization constants in the Metal backend and provides a generalised high-level solution which can be adopted by other graphics APIs supporting this feature. Authored by Apple: Michael Parkin-White Authored by Blender: Clément Foucault (files in gpu/test folder) Pull Request: https://projects.blender.org/blender/blender/pulls/115193
2023-12-28 05:34:38 +01:00
tests/specialization_constants_test.cc
GPU: Added Tests For Blend state And Immediate Mode This PR adds several tests to GTest for testing blend states and immediate mode. The immediate mode test are basic and will be extended in the near future. The tests have been developed in order to get the first pixel on screen for the Vulkan backend. In the first phase of this goal we had to validate that everything was working as expected without being able to validate it by starting Blender. Pull Request: https://projects.blender.org/blender/blender/pulls/107834
2023-05-11 09:15:39 +02:00
tests/state_blend_test.cc
Cleanup: Remove gpu prefix in gpu test cases. The _gpu_ prefix is redundant as they are inside a namespace and run as part of a test suite that already contain the name gpu. (GPUOpenGLTest) This patch also moved the texture test cases to its own compile module.
2023-03-13 11:12:05 +01:00
tests/storage_buffer_test.cc
tests/texture_test.cc
Vulkan: Convert VertexBuffer to Contain Supported Attributes Vulkan doesn't have a conversion from uint32_t/int32_t to float. It does have conversions from 16/8 bits. Main reason is that Vulkan expects that there is no benefit when converting 32 bits from one type to the other and should be solved by passing the right data type. In Blender however this isn't the case as there are benefits on other GPU backends (OpenGL for example). This PR adds helper function to check if conversion is needed and perform any conversions in place. It also implements the function to upload vertex buffers to the GPU. NOTE: Test cases have been added to validate this, but they are not able to run on the Vulkan backend just yet, because they require the graphics pipeline to be available. Pull Request: https://projects.blender.org/blender/blender/pulls/107733
2023-05-11 12:23:23 +02:00
tests/vertex_buffer_test.cc
GPU: Extract GPU Base Test case The draw manager test case initialized ghost, gpu and draw manager. This change splits the base test case to GPU specific and draw manager specific test case. The GPU test base test case will be used for low level GPU tests.
2020-09-08 11:31:47 +02:00
)
Vulkan: Enable Tests Not Relying on a Context Some test cases inside the vulkan backend don't rely on an initialized Vulkan Context and can always be run. This PR enables those test cases when `WITH_GTEST` and `WITH_VULKAN_BACKEND` is on. Allowing some tests to run on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/114574
2023-11-24 13:27:41 +01:00
endif()
Vulkan: Push constants **What are push constants?** Push constants is a way to quickly provide a small amount of uniform data to shaders. It should be much quicker than UBOs but a huge limitation is the size of data - spec requires 128 bytes to be available for a push constant range. **What are the challenges with push constants?** The challenge with push constants is that the limited available size. According to the Vulkan spec each platform should at least have 128 bytes reserved for push constants. Current Mesa/AMD drivers supports 256 bytes, but Mesa/Intel is only 128 bytes. **What is our solution?** Some shaders of Blender uses more than these boundaries. When more data is needed push constants will not be used, but the shader will be patched to use an uniform buffer instead. This mechanism will be part of the Vulkan backend and shader developers should not see any difference on API level. **Known limitations** Current state of the vulkan backend does not track resources that are in the command queue. This patch includes some test cases that identified this issue as well. See #104771. Pull Request #104880
2023-03-06 12:28:55 +01:00
Vulkan: Enable Tests Not Relying on a Context Some test cases inside the vulkan backend don't rely on an initialized Vulkan Context and can always be run. This PR enables those test cases when `WITH_GTEST` and `WITH_VULKAN_BACKEND` is on. Allowing some tests to run on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/114574
2023-11-24 13:27:41 +01:00
if(WITH_VULKAN_BACKEND)
list(APPEND TEST_SRC
Cleanup: Move vulkan specific tests in tests folder When reviewing the render graph core PR, we discussed where specific backend tests should be located. The code style is clear that it needs to be located in a tests folder next to the code it tests. This PR moved the tests folder from next to the files they test to a tests folder. Pull Request: https://projects.blender.org/blender/blender/pulls/120777
2024-04-18 12:47:23 +02:00
vulkan/tests/vk_data_conversion_test.cc
vulkan/tests/vk_memory_layout_test.cc
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
vulkan/render_graph/tests/vk_render_graph_test_compute.cc
vulkan/render_graph/tests/vk_render_graph_test_present.cc
Vulkan: Render graph clear attachments Adds support for clear attachments to the render graph. Clearing attachments require that the command buffer is being set for rendering (vkCmdBeginRendering). **What works** - Clear attachments are working with dynamic rendering and the render graph - `GPUVulkanTest.framebuffer_clear_color_single_attachment` - `GPUVulkanTest.framebuffer_clear_color_multiple_attachments` - `GPUVulkanTest.framebuffer_clear_multiple_color_multiple_attachments` - `GPUVulkanTest.framebuffer_scissor_test` - `GPUVulkanTest.framebuffer_clear_depth` **What still needs to be addressed** When a command buffer is rendering it cannot do any pipeline barriers. For clearing attachments this isn't needed, but when we address drawing we might need to register drawing resource dependencies to the dependency list of the begin rendering node. This will be solved when drawing will be implemented. [#121648] The begin rendering node is large as it has to store data for framebuffers with 8 color attachments as well. This might become an overhead and we could solve this by splicing the data of larger nodes into 2 lists. This will be addressed after we are able to draw a screen so we can collect data on this topic. [#121649] Pull Request: https://projects.blender.org/blender/blender/pulls/121073
2024-05-10 15:39:56 +02:00
vulkan/render_graph/tests/vk_render_graph_test_render.cc
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
vulkan/render_graph/tests/vk_render_graph_test_scheduler.cc
Cleanup: sort cmake file lists
2024-05-06 09:20:57 +10:00
vulkan/render_graph/tests/vk_render_graph_test_transfer.cc
CMake: include headers in source lists
2024-07-25 11:24:11 +10:00
vulkan/render_graph/tests/vk_render_graph_test_types.hh
GPU: Extract GPU Base Test case The draw manager test case initialized ghost, gpu and draw manager. This change splits the base test case to GPU specific and draw manager specific test case. The GPU test base test case will be used for low level GPU tests.
2020-09-08 11:31:47 +02:00
)
Vulkan: Enable Tests Not Relying on a Context Some test cases inside the vulkan backend don't rely on an initialized Vulkan Context and can always be run. This PR enables those test cases when `WITH_GTEST` and `WITH_VULKAN_BACKEND` is on. Allowing some tests to run on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/114574
2023-11-24 13:27:41 +01:00
endif()
Cleanup: spelling in comments
2024-09-20 13:14:57 +10:00
# Enable shader validation on build-bot for Metal
Refactor: Make header files more clangd and clang-tidy friendly When using clangd or running clang-tidy on headers there are currently many errors. These are noisy in IDEs, make auto fixes impossible, and break features like code completion, refactoring and navigation. This makes source/blender headers work by themselves, which is generally the goal anyway. But #includes and forward declarations were often incomplete. * Add #includes and forward declarations * Add IWYU pragma: export in a few places * Remove some unused #includes (but there are many more) * Tweak ShaderCreateInfo macros to work better with clangd Some types of headers still have errors, these could be fixed or worked around with more investigation. Mostly preprocessor template headers like NOD_static_types.h. Note that that disabling WITH_UNITY_BUILD is required for clangd to work properly, otherwise compile_commands.json does not contain the information for the relevant source files. For more details see the developer docs: https://developer.blender.org/docs/handbook/tooling/clangd/ Pull Request: https://projects.blender.org/blender/blender/pulls/132608
2025-01-07 12:39:13 +01:00
if(WITH_METAL_BACKEND AND NOT WITH_GPU_DRAW_TESTS AND
NOT (WITH_GTESTS AND WITH_GPU_BACKEND_TESTS)) # Avoid duplicate source file
Metal: Enable Shader Validation on Buildbot This PR enables shader validation testing on buildbot for Metal. OpenGL isn't enabled as OpenGL requires an actual driver and GPU attached to the build bot infrastructure. Also the OpenGL backend caches data (glsl_patch) globally and requires a restart in order to create the correct one. Vulkan isn't enabled as it requires some changes: * For windows it requires to install more recent vulkan software versions as part of the buildbot windows configuration * For Linux it requires to start a GHOST System without any X11/Wayland This currently fails on the buildbot. We should check if we can use `GHOST_SystemHeadless` with `GHOST_ContextVK` Each shaders are compiled twice. Once based on the actual features of the installed GPU/backend. And once with all the work-arounds enabled, simulating a platform close to the minimum requirements of Blender. Pull Request: https://projects.blender.org/blender/blender/pulls/116040
2023-12-12 10:14:13 +01:00
list(APPEND TEST_SRC
tests/shader_create_info_test.cc
)
endif()
macOS: Fix `WITH_GPU_DRAW_TESTS` build linking error The issue was twofold, the `draw_tests` library was missing a link dependency on `gpu_tests`, and the `gpu_tests` would only be generated if `WITH_GPU_BACKEND_TESTS` or `WITH_VULKAN_BACKEND` were also ON due to a superflous condition. Pull Request: https://projects.blender.org/blender/blender/pulls/133511
2025-01-24 11:00:34 +01:00
set(TEST_COMMON_SRC
tests/gpu_testing.cc
tests/gpu_testing.hh
)
Metal: Enable Shader Validation on Buildbot This PR enables shader validation testing on buildbot for Metal. OpenGL isn't enabled as OpenGL requires an actual driver and GPU attached to the build bot infrastructure. Also the OpenGL backend caches data (glsl_patch) globally and requires a restart in order to create the correct one. Vulkan isn't enabled as it requires some changes: * For windows it requires to install more recent vulkan software versions as part of the buildbot windows configuration * For Linux it requires to start a GHOST System without any X11/Wayland This currently fails on the buildbot. We should check if we can use `GHOST_SystemHeadless` with `GHOST_ContextVK` Each shaders are compiled twice. Once based on the actual features of the installed GPU/backend. And once with all the work-arounds enabled, simulating a platform close to the minimum requirements of Blender. Pull Request: https://projects.blender.org/blender/blender/pulls/116040
2023-12-12 10:14:13 +01:00
macOS: Fix `WITH_GPU_DRAW_TESTS` build linking error The issue was twofold, the `draw_tests` library was missing a link dependency on `gpu_tests`, and the `gpu_tests` would only be generated if `WITH_GPU_BACKEND_TESTS` or `WITH_VULKAN_BACKEND` were also ON due to a superflous condition. Pull Request: https://projects.blender.org/blender/blender/pulls/133511
2025-01-24 11:00:34 +01:00
blender_add_test_suite_lib(gpu
"${TEST_SRC}" "${INC};${TEST_INC}" "${INC_SYS}" "${LIB};${TEST_LIB}" "${TEST_COMMON_SRC}"
)
GPU: Extract GPU Base Test case The draw manager test case initialized ghost, gpu and draw manager. This change splits the base test case to GPU specific and draw manager specific test case. The GPU test base test case will be used for low level GPU tests.
2020-09-08 11:31:47 +02:00
endif()
Reference in New Issue Copy Permalink