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
Printf buffer read needs to be inside render boundaries
to work. Since render boundaries can be nested, use a stack.
Fixes assert when quitting blender.
The list of vulkan devices is empty. This regression was introduced by
91960b07db. Vulkan needs to initialize the
platform twice. Once when the backend starts, and the second time when
the device is selected. The device list is added when the backend
starts, but was cleared when the device was initialized, making the list
empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/130020
When gl_FragDepth is defined in the fragment shader and the depth isn't
written to the driver would reset the value to 0. This PR fixes this by
not putting the gl_FragDepth in the shader when it uses the
`depth_unchanged` qualifier or doesn't find any usage in the GLSL.
Pull Request: https://projects.blender.org/blender/blender/pulls/130016
For Metal we can change the texture usage flags to get more optimal
behaviour - one example is adding the attachment flag so we can utilise
renders to do texture clears. However these usage flags are used as the
part of the match-criteria when trying to reuse released textures in
the texture pool.
The modifications means a request for the same type of texture will
fail causing a cache miss. When we render to an
image-view the texture pool is not released until the final sample has
been rendered as we consider the entire render to be a single frame
(as opposed to normal viewport rendering when we are presenting the
intermediate results).
This causes the texture pool to grow and grow and grow hence the large
memory usage. This fix splits the usage flags
into two sets, the internal ones we use to create the MTLTexture (which
we may modify) and the originally requested ones. The originally requested
ones are used for the texture pool matching.
This fix also improves memory efficiency for normal viewport rendering.
Mr Elephant Scene
Before -> After
Load scene in viewport: 13.04Gb -> 9.15 Gb
Viewport Render Image: 78.69Gb -> 16.61Gb
Authored by Apple: James McCarthy
Pull Request: https://projects.blender.org/blender/blender/pulls/129951
When running test cases
`test_texture_roundtrip__GPU_DATA_10_11_11_REV__GPU_R11F_G11F_B10F`
would read and write outside of allocated memory. This is an error in
the test case itself the GPU API doesn't have a public function to get
the desired byte and component size.
Pull Request: https://projects.blender.org/blender/blender/pulls/129958
