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
OpenGL & Vulkan has workarounds when gl_Layer/gl_ViewportIndex isn't
supported. In this case a geometry shader will is generated. This
geometry shader doesn't follow the GLSL standard and doesn't work on
some platforms. This has not been an issue as the platforms that
don't support gl_Layer/gl_ViewportIndex don't show the issue.
According to the specs gl_Layer and gl_ViewportIndex should be set for
each call to EmitVertex. A shader should not rely on that EmitVertex
reuses the same memory.
Ref https://www.khronos.org/opengl/wiki/Geometry_Shader#Layered_rendering
```
Warning: gl_Layer and gl_ViewportIndex are GS output variables. As such, every time
you call EmitVertex, their values will become undefined. Therefore, you must set
these variables every time you loop over outputs.
```
Issue detected during development of !129062
Pull Request: https://projects.blender.org/blender/blender/pulls/130506
Recently the GLSL code was changed in Blender. For every GLSL file
the #line directive was added. However due to limitations in Blender
we misuse the indexed based line directive to store a hash. This is not
according to the spec where indexes should index the source inside the
array of sources. In vulkan the indexed based approach is not
'supported' as the compiler inputs only accepts a single file.
We tried to support file based approach but that lead to other issues in
renderdoc. Might be related to that the source file doesn't exist on the
file system.
This PR fixes this by scrambling the #line directive so the
step-by-step debugger can be used. The scrabling only happens when
blender is started with the `--debug-gpu-renderdoc` startup argument.
Pull Request: https://projects.blender.org/blender/blender/pulls/130458
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
Some Vulkan platforms don't support framebuffers with gaps between the
color attachments. Workbench framebuffers can create gaps.
(`in_front_fb`, `main_fb` when used for wire frame drawing).
This PR implements a detection mechanism to detect gaps. It also disables
features that are not able to comply to this requirement.
Detected when working on #129062
Pull Request: https://projects.blender.org/blender/blender/pulls/130258
In some cases the MTLContext was being destroyed before all GPU work was completed causing the (outstanding) command buffer completion event handler to update a command buffer that had already been freed. This behaviour was introduced by [this](https://projects.blender.org/blender/blender/commit/6da42e9c951b) change which updated the event handler to track the number of outstanding command buffers per context as well as system-wide.
Reproduced the issue with ASAN enabled and confirmed that waiting for the GPU to complete fixes the issue.
Also contains a minor fix for unitiiliased values in MTLAttachments identified by ASAN.
Authored by Apple: James McCarthy"
Co-authored-by: James McCarthy <jamesmccarthy@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/129686
