The array-length of a texture view isn't stored at the same location as
the array-base and was forgotten that it was a feature what had to be
supported.
Detected when testing `monster.blend` where the SSS object id wasn't
set and lead to missing materials.
**Before**

**After**

Pull Request: https://projects.blender.org/blender/blender/pulls/124590
When clearing depth attachment the write depth state should be enabled.
When this isn't the case a clear texture is being performed. Before
the render graph this used to be a performance issue as the rendering
would be suspended.
The render graph currently reorders these texture clears before of
the rendering context and therefore isn't seen as a performance issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/124340
This PR adds device statistics which can be printed to the console.
By default nothing is printed, but developer can choose to enable
it during development.
Pull Request: https://projects.blender.org/blender/blender/pulls/124150
EEVEE Eval light shader could still make a collision between
texture and image bind space making rendering glitch
when not using `--debug-gpu`. The problem was that the bind space
wasn't aware of the offset that the shader interface was using.
Pull Request: https://projects.blender.org/blender/blender/pulls/124140
Barycentric coordinates are used for the wireframe shader. It was
already implemented, but was made broken or when we change the depth
range or when we added support for fallback of shader viewport/layer
rendering. The previous implementation didn't use the correct
EmitVertex leading to incorrect depths. Also the shader layouts where
not Vulkan compliant.

Pull Request: https://projects.blender.org/blender/blender/pulls/124048
HiZ update performs a read/write on different buffers, this lead
to write-after-write hazards as the resources where added multiple
times in the same pipeline barrier with different access masks.
This is fixed by merging pipeline barriers based on their resource.
Pull Request: https://projects.blender.org/blender/blender/pulls/124036
Adds debug print function to output a node with its inputs and outputs.
Also keep track of the name of the resource (only images) what will
be presented. Tracking of the resource name is only done in debug builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/124033
When copying the depth aspect of a depth+stencil image the incorrect
barriers where created. The barrier needs to have the full aspect, even
when we only copy a single aspect from the image.
Pull Request: https://projects.blender.org/blender/blender/pulls/123890
When a buffer resource was read, and after that read from another
shader stage it would not generate the appropriate pipeline barrier.
This is fixed by keeping the last write action around and check
if the shader stage was already included in the previous barriers.
Pull Request: https://projects.blender.org/blender/blender/pulls/123845
Draw Manager visibility compute shader triggered a read-after-write
hazard. This root cause was that the incorrect access was read from
the shader interface. It was set to none, skipping the needed pipeline
barrier.
Pull Request: https://projects.blender.org/blender/blender/pulls/123839
When a shader uses push constants fallback the push constants are
stored inside a uniform buffer. The uniform buffer needs to be guarded
with a read barrier.
Pull Request: https://projects.blender.org/blender/blender/pulls/123777
The image views type can change depending based on how they are bound
to shaders. When a shader accesses a view without array operations,
the image view should not be an array. This was previously ignored.
Pull Request: https://projects.blender.org/blender/blender/pulls/123726
When clearing only the depth of a depth/stencil only the depth
part of the image aspect was stored in the node. This is invalid
when the image needed to be transitioned.
Pull Request: https://projects.blender.org/blender/blender/pulls/123713
When having a sequential read image barriers for the same resource
and the second one requires an image layout transition the incorrect
barriers where generated.
This was fixed by aligning the implementation with write image barriers.
Pull Request: https://projects.blender.org/blender/blender/pulls/123712
Internally the image and texture resources where kept in a vector
where the elements were referenced. When using more than 16 images
this vector is reallocated and previous references become invalid.
This is a quick fix and should be changed with something more
stable.
Pull Request: https://projects.blender.org/blender/blender/pulls/123656
Due to incompatible binding namespaces between Vulkan and OpenGL we
offset the images in the ubo list. In the previous implementation
this could still go wrong as the images and textures bindings where
sequential. When EEVEE binds resources it can also try to bind resources
that aren't valid for the current shader. In this case it was still
possible that the incorrect binding was chosen.
This is fixed by offsetting the images by a large number.
Pull Request: https://projects.blender.org/blender/blender/pulls/123649
When many text using BLF the glymp texture could be re-written.
In this case the new upload should be done in a separate render
graph node group. This wasn't the case and resulted in
validation warnings about the glyph texture being in an layout
that wasn't expected.
This PR simplifies the group extraction a bit by looking ahead
when the group ends.
Pull Request: https://projects.blender.org/blender/blender/pulls/123547
Due to incorrect logic any multi viewport setup could be cleaned
when dynamic rendering begins. This patch moves the clearing
of the viewport/scissor setup when binding.
This issue fixes shadow rendering in EEVEE.
Pull Request: https://projects.blender.org/blender/blender/pulls/123484
`VK_EXT_shader_stencil_export` isn't supported by NVIDIA devices.
This extension was recently added to support EEVEE PBR layer selection.
This PR makes this extension optional and selects the work around
when not supported by the physical device.
Fixes#114385
Pull Request: https://projects.blender.org/blender/blender/pulls/123470
Vulkan backend has recently switched to a render graph approach. Many
code was left so we could develop the render graph beside the previous
implementation. Last week we removed the switch. This PR will remove
most of the unused code. There might be some left and will be removed
when detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123422
Add a `.data<T>()` method that retrieves a mutable span. This is useful
more and more as we change to filling in vertex buffer data arrays
directly, and compared to raw pointers it's safer too because of asserts
in debug builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/123338
Texture update ignored layered based offsets and extents. This was
an oversight due to misintepreting the API. This fixes uploading the
utility texture of EEVEE and enables correct material shading.
Pull Request: https://projects.blender.org/blender/blender/pulls/123371
When using GPU_SAMPLER_EXTEND_MODE_EXTEND the incorrect sampler
was created, making the OCIO shader fail. This PR selects the
correct wrapping mode (CLAMP_TO_EDGE).
Pull Request: https://projects.blender.org/blender/blender/pulls/123234
This PR hooks up the vulkan backend with the render graph
for drawing. It can run Blender better than the previous
implementation so we also flipped it to be the default
implementation.
**Some highlights**
- Adds support for framebuffer load/store operations
- Adds support for framebuffer subpass transitions
- Fixes workbench shadows
- Performance is just below OpenGL performance when comparing
fps. But the screen feels more fluent when using complex
scenes.
- Current performance is without doing any optimizations so
will improve in the future.
- EEVEE will not crash but has artifacts and many parts that
require more work.
**Related to**
- #121648
- #118330
**Known Limitation**
- Similar to previous implementation resources can be freed when
still in use crashing Blender. This is typically the case when
playing back an animation or updating a material icon.
**Next steps**
- Remove old implementation
- Get EEVEE to work
- Fix double resource freeing
- Improve performance by identifying hotspots and change them
Pull Request: https://projects.blender.org/blender/blender/pulls/121787
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
Allow precompiling specialization constants variations in parallel.
Only supported in OpenGL as the rest of the batch compilation API,
on the other backends the function is a no-op.
This also moves the `SpecializationConstant` from
`gpu_shader_create_info` (private API) into`GPU_common_types`
(public API).
Pull Request: https://projects.blender.org/blender/blender/pulls/122796
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