This change adds timeline semaphores to track submissions. The previous
implementation used a fence.
Timeline semaphores can be tracked in more detail as it is an counter.
For each submission the counter can be stored locally and when waiting
for completion the counter can be retrieved again and checked if is
known to be succeeded by a higher value.
The timeline semaphore is stored next to the queue and can also be used
to synchronize between multiple contexts.
Pull Request: https://projects.blender.org/blender/blender/pulls/115357
This PR shows the memory footprint in the statusbar when activated.
Only memory allocated on the VRAM is counted. Memory allocated on host
memory is not counted.
Pull Request: https://projects.blender.org/blender/blender/pulls/115184
In Blender a context should not be shared between threads. In Vulkan a
command pool must not be shared between threads. In the current
implementation the command pool are stored on device level and could
therefore be shared between multiple context which made the implementation
not matching these rules.
This PR moves the command pool from device to command buffers where it
would not conflict between other contexts. This PR doesn't make the Vulkan
backend fully multithreaded. The access to the queue is still missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/114977
Goal is to reduce the number of command buffer flushes by tracking what is
happening in the different command queues. This is an initial step towards
advanced queue-ing strategies.
The new (intermediate) strategy records commands to different command
buffers based on what they do. There is a command buffer for data transfers,
compute pipelines and graphics pipelines.
When a compute command is recorded it ensures that all graphic commands
are finished. When a graphic command is recorded it ensures all compute
commands are finished. When a graphic or compute command is scheduled
all recorded data transfer commands are scheduled as well.
Some improvements are expected as multiple compute and data transfers
commands can now be scheduled at the same time and don't need to unbind
and rebind render passes. Especially when using EEVEE-Next which is
compute centric the performance change is visible for the user.
Pull Request: https://projects.blender.org/blender/blender/pulls/114104
Allow binding of framebuffers without sRGB to linear transform.
`GPU_framebuffer_bind_no_srgb`. This Patch removes color transform
artifacts in node, image and sequence editor.
When the framebuffer is an srgb framebuffer and it is bound without
the transformation, the SRGB textures are bound as UNORM variants.
As framebuffer, render pass and subpass recreation is ensured by
`VKCommandBuffer` we don't need to mark the framebuffer dirty at
this time. Later on we can optimize this by adding a state changed
detection for framebuffers and render passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113838
Wireframe mode wasn't working and viewport had flickering artifacts.
Reason was that the render pass creation failed for its framebuffer as
the input data was filled with garbage for attachments that were unused.
Vulkan requires every attachment to be filled upto the highest used attachment
slot. This PR fills missing attachments with a dummy texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/113141
During Blitting it is not allowed to read/write outside
the texture bounds. This patch ensures that the bounds
(called extents in Vulkan) are inside the expected range.
Pull Request: https://projects.blender.org/blender/blender/pulls/113050
In Vulkan (and Metal) it is not possible to use a global as point
size. It needs to be set for each vertex when drawing points. Blender
has specialized shaders for that, but not all code respect those
shaders.
This PR will add an assert inside the vulkan backend when incorrect
usage of shaders are detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/112906
Resources can still be in use inside the vulkan command queue, when
they are destroyed. Especially as Vulkan doesn't allow resetting
bindings to nothing.
This PR will collect the resources that needs to be destroyed inside
the VKDevice and actually destroy the resources when on frame end.
The resources currently include:
* VkBuffer
* VkImage
* VkImageView
* VkFramebuffer
* VkRenderPass
Pull Request: https://projects.blender.org/blender/blender/pulls/112514
This is a rewrite of GHOST_ContextVK to align with Metal backend as described
in #111389 - solution 3 with the adaptation that GHOST is still responsible
for presenting the swap chain image and a post callback is still needed in
case the swapchain is recreated.
This PR also includes some smaller improvements in stability.
Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/
* Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK
* VKFramebuffer doesn't contain a swap chain image.
* Swapchain images can only be used as a blit destination or present source.
Not as an attachment.
* GHOST_ContextVK::swapBuffers would call a callback with the image the
GPU module needs to blit the results to.
* Clearing of depth/stencil attachments when no depth write state is set.
* Enable VK_KHR_maintenance4 to relax the stage interface mapping.
* Removes most vulkan validation warnings/errors.
* Detection of frame buffer changes that needs to be applied before
performing a command requiring render pass (draw/clear attachment)
**Benefits**
* Late retrieval of a swap chain image results in better overall performance as
Blender doesn't need to wait until the image is presented on the screen.
* Easier API and clearer state (transitions)
* More control over Image layouts and command buffer states. (Better alignment with
Vulkan API)
Pull Request: https://projects.blender.org/blender/blender/pulls/111473
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.
The current Vulkan resource management has some issues as context that
are not active can still use resources that are freed via another
context.
When this happens incorrect data can be read on the GPU and even crash
Blender. When trying to bind something that now contains other memory
pointers.
This change introduces that contexts are tracked via the device.
Context will be registered/unregistered with the device instance.
Unbinding of resources must pass the device and the device will check
all registered contexts. Binding of resources will happen via the active
context only.
On user perspective this now allowes:
- Opening/switching files
- Switching workspaces
- Switching render engines
Pull Request: https://projects.blender.org/blender/blender/pulls/108968
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/
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
Vulkan coordinate system is flipped compared to OpenGL. This PR
flips the drawing when drawn to the on-screen frame buffer.
Offscreen frame buffers are still drawn upside down.
The flipping is done by making the viewport of the framebuffer negative.
Pull Request: https://projects.blender.org/blender/blender/pulls/107743
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
This PR adds support for `GPU_unpack_row_length_set` to the vulkan
backend.
Texture unpacking is used when uploading a part of a texture from
host memory to device memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/107360
Apparently we always constructed a Vulkan 1.0 Context, although we
are targetting Vulkan 1.2. This also lead to incorrect expectations
when using the Vulkan Memory allocator.
Pull Request: https://projects.blender.org/blender/blender/pulls/107300
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
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
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
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
Adds two modes of GPU frame capture support for
enhanced debugging. GPU frame capture begin/end
allow instantaneous frame capture of all GPU commands
within the capture boundary.
GPU frame capture scopes allow several user-defined capture
regions which can wrap key parts of code. These scopes are
exposed to connected GPU tools allowing the user to manually
trigger a capture of a known scope at the desired time.
This is currently integrated with the Metal backend for
support with Xcode.
Related to #105591
Pull Request: https://projects.blender.org/blender/blender/pulls/105717
This was backported from tmp-vulkan. When disabling the fence check
in ghost it is able to start blender. It will show a black screen
so not usable for users.
This patch will give access to the physical device limits
of the device associated with the context. In vulkan each
device has different limits and the application is
responsible to match these limits as the vulkan driver
just ignores calls that don't match these limits.
Those limits are GPUBackend specific and therefore are not
added to GPU_capabilities.
Pull Request #105125
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
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
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
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
