This PR will add timeline semaphores to be required. It doesn't use
the timeline semaphores yet, but as multiple developments will
rely on it it is better to add the requirement.
Pull Request: https://projects.blender.org/blender/blender/pulls/132683
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
- Using a main function allows the scripts to be imported without
executing logic.
- Declaring `__all__` lets tools such as "vulture" detect unused code.
Ensure `gl_ViewportIndex` and `gl_Layer` are properly forwarded from the
geometry shader, and don't write to them from the vertex shader if
there's a geometry shader stage.
Fixes the Displacement "dicing" render tests on Nvidia OpenGL.
Pull Request: https://projects.blender.org/blender/blender/pulls/131875
Blender stores all pipelines in a pool. Using a hash it checks if a
the pipeline was already created and the previous could be reused. Due
to performance issues when working with graphics pipelines some equal
operations only used a hash check. For scissors and viewports this isn't
enough and could lead to issues.
This PR fixes this to still perform an exact check if the hash are
equal. Note that the performance drops a bit. And should be countered
with other performance improvements in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/132005
This adds initial support for ReBAR capable platforms.
It ensures that when allocating buffers that should not be host visible, still
tries to allocate in host visible memory. When there is space in this memory
heap the buffer will be automatically mapped to host memory.
When mapped staging buffers can be skipped when the buffer was newly
created. In order to make better usage of ReBAR the `VKBuffer::create`
function will need to be revisit. It currently hides to much options to allocate
in the correct memory heap. This change isn't part of this PR.
Using shader_balls.blend rendering the first 50 frames in main takes 1516ms.
When using ReBAR it takes 1416ms.
```
Operating system: Linux-6.8.0-49-generic-x86_64-with-glibc2.39 64 Bits, X11 UI
Graphics card: AMD Radeon Pro W7700 (RADV NAVI32) Advanced Micro Devices radv Mesa 24.3.1 - kisak-mesa PPA Vulkan Backend
```
Pull Request: https://projects.blender.org/blender/blender/pulls/131856
MoltenVK dynamic rendering is built on top of render passes and framebuffers.
This also means that dynamic rendering has the same limitations.
This PR enables the workarounds for gaps between attachments for MoltenVK.
Pull Request: https://projects.blender.org/blender/blender/pulls/131816
Rendering animations from Python scripts via `bpy.ops.render.opengl()`
did not trigger any of the notifications in the Metal back-end to
indicate a frame had been rendered and that the associated resources
could be released. This adds a call to GPU_render_step() after each
render. For the original asset in the bug report this reduces the high
memory watermark from 30gb to 13gb for 500 frames. 13gb is likely
still too high and therefore it is likely there are additional leaks
that need to be addressed so this should only be considered a partial
fix.
Authored by Apple: James McCarthy
Co-authored-by: James McCarthy <jamesmccarthy@apple.com>
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/131085
This enables moving elements form one vector to another.
Usually this is being doing by extending a vector with the content
from the secondary vector and then clearing the secondary vector.
However sometimes this being performed to transfer ownership of managed elements,
if elements are copied from the secondary vector, but not cleared, this could
lead to 2 vectors to share ownership of objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/131560
NVIDIA driver before 550 doesn't work as expected on Linux. The issue is
known on the internet, but no real solutions are provided.
This change will limit the block list of older driver to the Linux
platform only. It has been reported that Windows these driver are
working and would enable older GPUs to work on Windows.
Ref #129160
Pull Request: https://projects.blender.org/blender/blender/pulls/131674
Vulkan version 1.2 supports Workgroup execution model. Vulkan 1.3
introduced the LocalSizeId execution model and has been backported in
the VK_KHR_maintenance4 extension. In future SPIR-V versions the
Workgroup execution model will be deprecated.
This PR checks the availability of VK_KHR_maintenance4 extension and
when enabled compile the shaders towards Vulkan 1.3. This would
automatically use the LocalSizeId execution model.
See https://registry.khronos.org/vulkan/specs/latest/man/html/WorkgroupSize.html
Pull Request: https://projects.blender.org/blender/blender/pulls/131663
When using a texture as attachment it must be created witht the
GPU_TEXTURE_USAGE_ATTACHMENT flag. If this is not the case it would lead
to incorrect usage in Vulkan. This change adds asserts to detect
incorrect usage.
Pull Request: https://projects.blender.org/blender/blender/pulls/131656
GPU_texture_clear was only used for clearing color textures, but that
changed recently. This PR adds supports for clearing depth/stencil
textures using GPU_texture_clear.
Pull Request: https://projects.blender.org/blender/blender/pulls/131653
Depth 24 stencil 8 texture could not be cleared directly. Recently
GPUViewports clear their attachments when created. This resulted into
non consistent behavior between backends.
This change adds support to clear depth 24 stencil 8 textures using
`GPU_texture_clear`. The implementation currently assumes that the input
value is a float.
Pull Request: https://projects.blender.org/blender/blender/pulls/131650
GPUViewport is creating a bunch of framebuffer textures for itself, but
some space types never initialize/use them. E.g. Sequencer, Nodes etc.
only ever use the "overlay" texture. Eventually when viewport is
"drawn", it combines this uninitialized texture data and then only by
luck it happens that most of the time it is black. But not always!
The textures were only cleared (right now) on Metal backend, under
GPU_clear_viewport_workaround as if it was some driver workaround. Stop
doing that, and just clear them always.
However, there was seemingly a performance issue on OpenGL, when this
clear was being done. At least on my machine (Win10, Geforce RTX
3080Ti), the overhead of doing the clears is measurable, and is caused
by usage of GL4.4 glClearTexImage instead of a framebuffer clear. As if
glClearTexImage makes "pixel data to exist" on the CPU side and then
later on binding this framebuffer sends off that data to the GPU, or
somesuch.
More details in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/131518
Reduces the number of times a graphic context needs to be paused/resumed.
The scheduler reorders the nodes to put these initial data transfer nodes
to the start of the nodes that are about to be submitted.
Pull Request: https://projects.blender.org/blender/blender/pulls/131502
Devices reported by failing drivers were still part of the device
selection list. When selected they would never be picked.
This change hides these devices from the UI
Pull Request: https://projects.blender.org/blender/blender/pulls/131431
In OpenGL the last vertex is the provoking vertex. In Vulkan the first
vertex is the provoking vertex. This PR uses `VK_EXT_provoking_vertex`
to use the last vertex as the provoking vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/131412
When copying from/to depth stencil images the aspect of the image was
set incorrectly. It pointed to only one aspect of the full image when
building resource links, which could lead to incorrect decisions in the
driver.
Found when researching #131269
Pull Request: https://projects.blender.org/blender/blender/pulls/131298
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
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 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
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
