In this case a triangle shader was used to render points.
This change entails:
- Using point shaders in this case
- Add support for `GPU_point_size` to update the uniform of the point
shader.
Pull Request: https://projects.blender.org/blender/blender/pulls/139574
This allows multiple threads to request different specializations without
locking usage of all specialized shaders program when a new specialization
is being compiled.
The specialization constants are bundled in a structure that is being
passed to the `Shader::bind()` method. The structure is owned by the
calling thread and only used by the `Shader::bind()`.
Only querying for the specialized shader (Map lookup) is locking the shader
usage.
The variant compilation is now also locking and ensured that
multiple thread trying to compile the same variant will never result
in race condition.
Note that this removes the `is_dirty` optimization. This can be added
back if this becomes a bottleneck in the future. Otherwise, the
performance impact is not noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/136991
Importing memory is done to often. when memory doens't change the
previous imported memory can be used.
The idea is to keep track of the last used buffer and keep reusing
it until the view/resolution has changed. This should not happen during
a session.
Pull Request: https://projects.blender.org/blender/blender/pulls/138984
- Reduce artifacts during resizing to also recreate the swapchain
when acquire image is suboptimal
- Do not stretch when backbuffer and swapchain have a different size
Pull Request: https://projects.blender.org/blender/blender/pulls/138925
Part of #136993.
Share as much of the ShaderCompiler implementations as possible.
Remove the ShaderCompiler/ShaderCompilerGeneric split and make most of
its functions non virtual.
Move the `get_compiler` function from `Context` to `GPUBackend` and
creation/deletion to `GPUBackend::init/delete_resources`.
Add a `batch_cancel` function to `ShaderCompiler` (needed for the
GPUPass refactor).
As a nice extra, the multithreaded OpenGL compilation has become faster
too.
The barbershop materials + EEVEE static shaders have gone from 27s to
22s.
I have not observed any performance difference on Vulkan or Metal.
Pull Request: https://projects.blender.org/blender/blender/pulls/136676
Descriptor pools were never discarded, leading to out of memory issues
when running for a long time. This PR discards used descriptor pool when
the render graph is submitted to the device.
- Detected that to descriptor sets could be uploaded multiple times
however once was always empty.
- When render graph is flushed all descriptor pools are discarded.
- Improved debugging of discard pools.
Pull Request: https://projects.blender.org/blender/blender/pulls/137521
A couple of memory leak fixes for the vulkan backend.
We increment the submission_id on render_graphs upon reset. This
triggers cleanup of anything tracked as a VKResourceTracker. Notably
uniform buffers created for push constant fallbacks. This fixes a memory
leak that was accumulating VKUniformBuffers every frame without cleaning
them up.
Reset resource pools when a swapchain image is presented. This ends up
calling vkResetDescriptorPool, freeing up descriptor set resources. This
fixes a memory leak that was accumulate descriptor sets and pools over
time without freeing them.
Pull Request: https://projects.blender.org/blender/blender/pulls/137305
Incorrect data format was selected when using CPU data transfers in
OpenXR. It always used `GPU_DATA_HALF_FLOAT`, also when the swapchains
where `GPU_RGBA8`. This resulted in black screens in release mode, and
asserts in debud mode.
Fixed by selecting the correct data transfer data type based on the
swapchain format.
Co-authored-by: jeroen@blender.org <Jeroen Bakker>
Pull Request: https://projects.blender.org/blender/blender/pulls/137269
This PR add support to use a win32 handle to perform share render
result with the OpenXR vulkan instance. This is only possible when
the GPU matches. Otherwise a CPU roundtrip will be performed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137093
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
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
This PR refactors the way how swapchains are used.
Allow scaling of the swapchain content to the actual resolution of the swapchain.
can reduce artefacts when resizing windows when supported.
When frame rate is to fast the previous implementation could use a semaphore
that were still in use, leading to unwanted stuttering on certain platforms. Waiting
when the rendering has finished (GHOST_Frame.submission_fence), before the
next image is acquired from the swap chain.
Mailbox has been disabled as it can calculate more frames then actually been
presented, leading to a lag and increased power usage on others.
Pull Request: https://projects.blender.org/blender/blender/pulls/136603
After reviewing the locations where `GPU_flush()` are used it doesn't seem
to be harmfull to include these for the Vulkan backend as well. Hopefully
will save some lag that can happen when submitting one huge render graph.
Improved playback of rain_restaurant.blend where frames could be dropped
resulting into UI lag.
Pull Request: https://projects.blender.org/blender/blender/pulls/136654
The Blender's VkInstance cannot be shared with OpenXR VkInstance. The
reason is a chicken and egg problem where OpenXR needs to be started
before Vulkan. OpenXR can add special vulkan specific requirements
(instance&device) that are only available when the user starts an OpenXR
session.
The goal implementation is to share memory between both instances using
[VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems
to be a bridge to far as a initial step. Reason: There are not that many
samples/ guides and documentation to be found to handle the workflow that
we require. We want to do a smaller step by step approach to gain the needed
knowledge.
For that reason this PR does the most stupidest thing that can be done to
share memory between instances. Download the render result to CPU RAM share
the host pointer with the OpenXR instance which copies it to the swap chain.
Also the synchronization is done using wait idle commands.
<video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video>
**Gaining knowledge**
- Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR).
- Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional
memcpy on OpenXR side.
- Export host pointer from Blender side from a mappable buffer.
- Replace host pointers with fd/dmabuf/winhandle
- Remove mappable buffer.
Ref #133718
Pull Request: https://projects.blender.org/blender/blender/pulls/133824
This PR adds swapchain synchronization. When the swapchain swaps the
buffers it can add a wait semaphore/signal semaphore to support GPU
based synchronization
10 times playback of `rain_restaurant.blend` on AMD RX 7700
Before: 10 × Animation playback: 72347.5540 ms, average: 7234.75539684 ms
After: 10 × Animation playback: 41523.2441 ms, average: 4152.32441425 ms
Getting around the OpenGL performance target.
Pull Request: https://projects.blender.org/blender/blender/pulls/136259
When swap chain is updated the logic could select an incorrect
framebuffer. This isn't actually the case during normal usage, but has
been detected during the development of OpenXR support. Here it did
matter.
Pull Request: https://projects.blender.org/blender/blender/pulls/136115
This PR implements a new the threading model for building render graphs
based on tests performed last month. For out workload multithreaded
command building will block in the driver or device. So better to use a
single thread for command building.
Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/
- When a context is activated on a thread the context asks for a
render graph it can use by calling `VKDevice::render_graph_new`.
- Parts of the GPU backend that requires GPU commands will add a
specific render graph node to the render graph. The nodes also
contains a reference to all resources it needs including the
access it needs and the image layout.
- When the context is flushed the render graph is submitted to the
device by calling `VKDevice::render_graph_submit`.
- The device puts the render graph in `VKDevice::submission_pool`.
- There is a single background thread that gets the next render
graph to send to the GPU (`VKDevice::submission_runner`).
- Reorder the commands of the render graph to comply with Vulkan
specific command order rules and reducing possible bottlenecks.
(`VKScheduler`)
- Generate the required barriers `VKCommandBuilder::groups_extract_barriers`.
This is a separate step to reduce resource locking giving other
threads access to the resource states when they are building
the render graph nodes.
- GPU commands and pipeline barriers are recorded to a VkCommandBuffer.
(`VKCommandBuilder::record_commands`)
- When completed the command buffer can be submitted to the device
queue. `vkQueueSubmit`
- Render graphs that have been submitted can be reused by a next
thread. This is done by pushing the render graph to the
`VKDevice::unused_render_graphs` queue.
Pull Request: https://projects.blender.org/blender/blender/pulls/132681
Images used to be tracked with ownership in order to reset swap chain
images to its original layout. This isn't used anymore as we always mark
them in VK_IMAGE_LAYOUT_UNDEFINED to make the first pipeline barrier a
nop.
This change reduces unneeded complexity and safe a few CPU cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133197
Blender always updates all pixels of the swap chain. As an optimization
we can skip the initial layout transition from present to transfer
destination as all pixels will be rewritten.
Pull Request: https://projects.blender.org/blender/blender/pulls/133061
Framebuffers are getting freed in the GPUContext base class destructor. But
the framebuffer destructors use the MTL/VK/GLContext derived class, whose
destructor has already completed at this point. So these contexts are no
longer valid to use.
Now free the framebuffers earlier.
This caused ASAN warnings, it's not known to cause actual bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/132504
Its not standard how `Present Engines` return images for presentation, and
currently is expected that they cycle between swap-chain images with each
`vkAcquireNextImageKHR` call.
However present engines could return any available image, that can mean
to reuse the last presented one if available. (This seem to be the behavior
using `Layered on DXGI Swapchain` the default `Present Method` used
with latest NVIDIA drivers on Windows).
Since resource pools expects to images to cycle in a sequential order, if any
present engine always return the same image for presentation only a single
resource pool would be used for each rendered frame, and since resources
are only released by cycling between resource pools, this resource pool would
overflow since it never releases any resource.
This changes makes resource pools to cycle each time a image is presented.
Pull Request: https://projects.blender.org/blender/blender/pulls/131129
When lighting baking is used in a background render the resources are
freed to early. The cause is that light baking does some initialization
within a context, that isn't send to the GPU. The first iteration of
light baking is expecting that it can free resources, what leads to GPU
resources to be deleted that are still used by commands that are
scheduled to be send to the GPU.
This PR fixes this by using multiple resource pools when background
rendering and ensure that contexts are send to the GPU when rendering
ends.
Pull Request: https://projects.blender.org/blender/blender/pulls/131094
Dynamic rendering is a Vulkan 1.3 feature. Most platforms have support
for them, but there are several legacy platforms that don't support dynamic
rendering or have driver bugs that don't allow us to use it.
This change will make dynamic rendering optional allowing legacy
platforms to use Vulkan.
**Limitations**
`GPU_LOADACTION_CLEAR` is implemented as clear attachments.
Render passes do support load clear, but adding support to it would
add complexity as it required multiple pipeline variations to support
suspend/resume rendering. It isn't clear when which variation should
be used what lead to compiling to many pipelines and branches in the
codebase. Using clear attachments doesn't require the complexity
for what is expected to be only used by platforms not supported by
the GPU vendors.
Subpass inputs and dual source blending are not supported as
Subpass inputs can alter the exact binding location of attachments.
Fixing this would add code complexity that is not used.
Ref: #129063
**Current state**
Pull Request: https://projects.blender.org/blender/blender/pulls/129062
When copying the window to the swap chain the image needs to be copied
upside down to match Vulkan/OpenGL image coordinate differences.
There was an of by 1 error when copying resulting in minor drawing
glitch which was noticeable when looking at the viewport grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/130328
WITH_VULKAN_GUARDEDALLOC is a development option to use Blenders guarded
allocator when allocating internal vulkan driver resources. It does not provide any benefits
as this should be covered by vulkan validation and drivers are often ignoring this. This
change will remove the option from cmake and source code.
Pull Request: https://projects.blender.org/blender/blender/pulls/129039
Resources are shared, when running multiple contexts on the same thread.
Cycles uses the same context on multiple threads and expected same resources.
This change will introduce a single render graph per context and an updated
resource management. Render graphs are not shared anymore; Resource pools
are still shared, but garbage collection depends on the thread and if
background rendering is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/128983
When performing preview job rendering the memory wasn't recycled leading
to a memory leak. For background rendering we already recycled memory in
a correct way. This change enables the same branch during preview
rendering.
Also adds a better `VKDevice::debug_print` to see the resources being
tracked by the different threads and resource pools.
Pull Request: https://projects.blender.org/blender/blender/pulls/128377
Immediate mode uses the old 'resource tracker' which has been replaced
by swap chain resource pools. This PR optimizes immediate mode buffers
by utilizing resource pools.
Pull Request: https://projects.blender.org/blender/blender/pulls/128188
Resource binding was over-complicated as I didn't understood the state
manager and vulkan to make the correct decisions at that time. This
refactor will remove a lot of the complexity and improves the performance.
**Performance**
The performance improvement is noticeable in complex grease pencil
scenes.
Grease pencil benchmark file picknick:
- `NVIDIA Quadro RTX 6000` 17 fps -> 24 fps
- `Intel(R) Arc(tm) A750 Graphics (DG2)` 6 -> 21 fps
**Bottle-neck**
The performance improvements originates from moving the update entry
point from state manager to shader interface. The previous implementation
(state manager) had to loop over all the bound resources and find in the
shader interface where it was located in the descriptor set. Ignoring
resources that were not used by the shader. But also making it hard
to determine if descriptor sets actually changed. Previous implementation
assumed descriptor sets always changed.
When descriptor set changed a new descriptor set needed to be allocated.
Most drivers this is a fast operation, but on Intel/Mesa this was measurable
slow. Using an allocation pool doesn't fit the Vulkan API as you are only
able to reuse when the layout matches exactly. Of course doable, but requires
another structure to keep track of the actual layouts.
**Solution**
By using the shader interface as entry point we can:
1. Keep track if there are any changes in the state manager. If not and the
layout is the same, the previous shader can be reused.
2. In stead of looping over each bound resource, we loop over bind points.
**Future extensions**
Bundle all descriptor set uploads just before use. This would be more
in line with how 'modern' Vulkan should be implemented. This PR already
separates the uploading from the updating and technically allows to upload
more than one descriptor set.
Instead of looking 1 set back we should measure if we can handle multiple
or keep track of the different layouts resources to improve the performance
even further.
Optional use `VK_KHR_descriptor_buffer` when available.
Pull Request: https://projects.blender.org/blender/blender/pulls/128068
Since parallel compilations was introduced, a validation error
was signalling that push constants for compute shaders didn't have
the correct pipeline binding. The root cause was that the pipeline
binding was determined, before the type of shader was known.
This PR fixes this by detemining if a shader is a compute shader up
front. It also removes some code that could lead to issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/128010
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
Vulkan would crash when generating a thumbnail in case there is no
3D viewport in the active workspace. When this happens the front buffer
is downscaled as thumbnail. We didn't create a front buffer as swap
chains are handled differently.
We work around this issue in the same way as Metal does. Create a dummy
front framebuffer and share the surface texture. When the thumbnail
generator reads from the front buffer it will read the data that was
created by the back buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/127393
- Resource pools are shared between multiple swap chains to reduce
code complexity
- Fix issue where activating a new graphical context could still leave
the previous context rendering.
- Known issue: opening files with more windows require a redraw.
Reference: #126499
Pull Request: https://projects.blender.org/blender/blender/pulls/126961
When orcos are not available in the geometry data it is bound with
a default buffer. This buffer was initialized with only zeros. But
orcos required to read the 0, 0, 0, 1.
Fixes `render/shader/tex_voronoi.blend` render test.
Pull Request: https://projects.blender.org/blender/blender/pulls/126838
When rendering in background there is no swap chain in play and
resources would never be collected. Resulting in out of resources and
crashes.
This PR is an initial fix what cycles resource pools every time a layer
has been rendered. It counts the render hierarchy
(GPU_rendering_begin/end) to identify if the background render is
completed and if so would cycle to the next resource pool.
Pull Request: https://projects.blender.org/blender/blender/pulls/126819
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
EEVEE can bind layers of a texture that is also used as an attachment. When binding
the image layout of these specific layers can be different that the image layout of
the whole image.
This fixes the known synchronization issues inside EEVEE. wasp_bot, tree_creature and
wanderer scenes can be rendered without any synchronization issue reported by the
Vulkan validation layers.
Design task: #124214
When beginning to render the attachments are being evaluated. If there is an arrayed
texture (with multiple layers) the individual layers of that texture can be tracked
during until the rendering is ended.
When the same texture is bound to a shader it will be a different layer (otherwise
there is a feedback loop, which isn't allowed). The bound layers will typically need
a different layout the transition to the new layout is executed and recorded. When
the rendering ends, the layers are transitioned back to the layout the texture is
expected in.
It can happen that a layer is used multiple times during the same rendering. In
that case the rendering should be suspended to perform the transition. Image layout
transitions are not allowed during rendering.
There is one place where a layer needs to be transited multiple times that is when
EEVEE wants to extract the thickness from the shadow. The thickness is stored inside
the gbuffer_normal which is also used as an attachment. Eval then samples the thickness
from the gbuffer_normal as a sampler. To work around this issue we suspend the rendering
when a `GPU_BARRIER_SHADER_IMAGE_ACCESS` is signaled.
Pull Request: https://projects.blender.org/blender/blender/pulls/124407
This PR will share render graphs between all contexts that run in
the same thread. This allows the draw manager commands to be added
to the same render graph as the UI.
- Fixes debug groups hiearchy. Draw manager would restart a hierarchy as
it wasn't aware of the debug groups already added by the UI
- Removes cpu sync when switching between contexts.
In a future change this is needed to improve discarding resources.
Pull Request: https://projects.blender.org/blender/blender/pulls/124715
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
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 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
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
