The new buffer size could have been non aligned when using the
fractional growing heuristic. This non aligned allocation
would then trigger an assert at the SSBO constructor.
Aligning the alocation size fixes the issue.
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
This was caused by querying on the selection state
before it is setup. It is only setup just before
the draw function.
To fix this, we sync the `info_buf` just before
drawing the overlays.
Also add some safety to avoid uninitialized memory.
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
This avoid stack overflow on GCC because types were getting too
large (70 bytes for a float4) and created a lot of static
memory for UBOs declarations.
When a main window contains a child window and the main window is closed
it can crash as the context isn't available when destructing the
VKFramebuffer of the child window.
Pull Request: https://projects.blender.org/blender/blender/pulls/131137
This happened because NVidia GPUs require higher alignment
for SSBO binds than for vertex inputs.
This is related to #131103 which fixed it for vulkan.
Add a common capability option for that.
Since recently we bind immediate sub buffers as storage buffers to
extend the geometry for line drawing. We didn't add alignment checks and
that raised warnings. This change will fix those warnings.
Pull Request: https://projects.blender.org/blender/blender/pulls/131103
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
Add support for Logic op XOR. This is used in image editors and tracking
editor. Logic ops is required on Linux and Windows, however for macOS it
will be disabled when using MoltenVK. MoltenVK has can be compiled with
support for logic ops, but that isn't the default as it relies on
private APIs.
When the workaround is enabled it will create artifacts when used.
Ref: #130347
Pull Request: https://projects.blender.org/blender/blender/pulls/131089
When debugging render graph the debug group name can narrow down the
place where a node originates from. This PR adds a function to retrieve
the full debug group name of a specific node.
Pull Request: https://projects.blender.org/blender/blender/pulls/131081
This port is not so straightforward.
This shader is used in different configurations and is
available to python bindings. So we need to keep
compatibility with different attributes configurations.
This is why attributes are loaded per component and a
uniform sets the length of the component.
Since this shader can be used from both the imm and batch
API, we need to inject some workarounds to bind the buffers
correctly.
The end result is still less versatile than the previous
metal workaround (i.e.: more attribute fetch mode supported),
but it is also way less code.
### Limitations:
The new shader has some limitation:
- Both `color` and `pos` attributes need to be `F32`.
- Each attribute needs to be 4byte aligned.
- Fetch type needs to be `GPU_FETCH_FLOAT`.
- Primitive type needs to be `GPU_PRIM_LINES`, `GPU_PRIM_LINE_STRIP` or `GPU_PRIM_LINE_LOOP`.
- If drawing using an index buffer, it must contain no primitive restart.
Rel #127493
Co-authored-by: Jeroen Bakker <jeroen@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/129315
When using texture painting Blender could freeze, crash or not showing
any results depending on the platform being used.
There were several issues:
- texture painting could send a layer offset of -1, which would select
an incorrect layer
- source data wasn't copied correctly in the staging buffer as it
ignored `texture_unpack_row_length`
Pull Request: https://projects.blender.org/blender/blender/pulls/130973
Layer tracking allows modifying specific layers of a bound texture to a
different layout. This was only supported when suspending/resuming was
not needed. However when using complex scenes EEVEE can trigger suspend/
resume rendering scopes. This resulted into several validation warnings
as images where in the incorrect state.
Fixes validation warnings:
- rain_restaurant.blend
- classroom.blend
Pull Request: https://projects.blender.org/blender/blender/pulls/130957
Currently `VkCommandBuffer` are allocated with `vkAllocateCommandBuffers`,
however when the commands are submitted pointer are just reset, these leaks
are visible with just play back animations.
This frees commands buffers resolving the leaks.
Ref: #127225 Although related we should check the result as there could be more causes.
Pull Request: https://projects.blender.org/blender/blender/pulls/130203
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
Older drivers seems to not work correctly and stall on the first frame.
We encourage users to use the latest driver and this driver support
devices from GTX 750 to RTX 4000 series.
NOTE: Later we should review this issue as supporting more drivers is
always better. The current issue could also be related to sending empty
command buffers to the GPU. Ideally we should support 535 as well.
Some Linux distributions don't package 550.
Ref: #129157
Pull Request: https://projects.blender.org/blender/blender/pulls/130737
!129062 introduces a workaround for dynamic rendering. However that
change didn't marked dynamic rendering as an optional feature. GPU that
didn't had dynamic rendering would still not be able to start Blender.
This PR marks dynamic rendering optional so the device will be
considered when searching for compatible GPUs.
Ref: #129157
Pull Request: https://projects.blender.org/blender/blender/pulls/130736
When binding sRGB textures as attachment to a none-sRGB framebuffer the
attachment description didn't match the image view. This results into a
validation error. This PR makes sure that the description and image view
uses the same VkFormat.
Pull Request: https://projects.blender.org/blender/blender/pulls/130730
Copying editors to the swap chain is done by a series of draw and copy.
When doing draw, copy, draw the swap chain layout was not matching the
draw command as it resumed previous rendering.
This is solved by validating the pipeline barriers when resuming rendering.
There are also other cases that required this which have been updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/130721
The legacy option is turned off by default and will be removed
in the following weeks. It is only there to check for
regression for a short period of time. Afterward checking
for regression will require to use 4.3 as a reference.
Rel #102179
Pull Request: https://projects.blender.org/blender/blender/pulls/130683
Add-ons can still use the legacy API that only works on OpenGL. Vulkan
however was crashing as there is no shader create info available.
Adding a pre-check when finalizing shaders on availability of shader
create info.
Pull Request: https://projects.blender.org/blender/blender/pulls/130660
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
In multiple parts (framebuffer and shader) the render areas/viewport could be
copied in an array of 16 structs, when only one is needed. This PR will use builder
patters so we don't over-allocate. Would spend less CPU cycles when constructing
render info, render passes/framebuffers, shaders.
Cleanup was part of !129062
Pull Request: https://projects.blender.org/blender/blender/pulls/130515
Shader interface used shader create info bind types to communicate bind
types to descriptor sets. However Vulkan supports more bind types than
Blender exposes in its API. Current implementation resulted that next to
the bind type the actual resource was queried to find out what needed to
be done.
This PR makes it more clear to convert the shader create info bind type
to `VKBindType` that contains the vulkan bind types we support.
Pull Request: https://projects.blender.org/blender/blender/pulls/130509
