This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
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
Both the draw manager and gpu backend used the same compilation
directive for enablement. This PR seperates them into
`WITH_GPU_DRAW_TESTS` for draw manager related tests and
`WITH_GPU_BACKEND_TESTS` for gpu backend related tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/132018
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
By now it is just a "compositor", so move the files one folder up.
Things that were under realtime_compositor/intern move into
already existing intern folder.
Pull Request: https://projects.blender.org/blender/blender/pulls/132004
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
When running tests `WITH_GTESTS` and `WITH_GPU_DRAW_TESTS` the
GPUShaderCreateInfo's specfically created for the tests could not be
found. This failed running tests on any backend.
This PR fixes this. The root cause what that the name of the compile
directive was incorrect. It should have been `WITH_GTESTS` but was
`WITH_GTEST`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131956
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
Use static CreateInfos for Overlay-Next shaders using a similar approach to Workbench shader variations.
Remove unused infos and shader sources.
Remove the `gpu_shader_create_info_get_unfinalized_copy` workaround.
Pull Request: https://projects.blender.org/blender/blender/pulls/131514
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
In Blender 4.4 (since commit 00a8d006fe), polyline shaders stopped
using geometry shaders and now rely on SSBOs.
In C++, workarounds allow these shaders to function as before, albeit
with some limitations.
However, this change broke the `batch_for_shader` function in Python,
as `GPUShader.attrs_info_get()` only reads attributes and does not
support SSBOs.
To address this, the method now treats polyline shaders differently,
accessing SSBO inputs instead of attributes.
fix
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
The string `msl_patch_default` can have been read
partially uninitialized or initialized multiple
time and read uncomplete during multithreaded
compilation.
This should fix the GPU tests randomly failing on mac.
While this would never fail when blender runs from the UI (since
UI shaders are init in single threaded manner and always compile
before EEVEE shaders), this race condition could happen when running
EEVEE through background rendering or running tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/131580
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
Move the Gamma Correction pass of blur nodes into its own algorithm to
avoid code duplication and optimize pixel access, since gamma is now
applied for each pixel in the filter window. Gives a 15% improvement.
Pull Request: https://projects.blender.org/blender/blender/pulls/131480
