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
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
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
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
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
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.
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.
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
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
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
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
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.
This allows to use `assert()` directly inside shader source.
The current implementation is just replacing it with a printf
that gives some information about the location of the assert.
It is not that much more helpful than a printf with a condition.
What is useful is that they are disabled by default. So they
can be sprinkle around and only turned on during debugging.
Adding shader name inside the assert report is not trivial and
could be added later (the shader name is only known at compile
time which is too late for string parsing).
Adding which drawcall produced the assert isn't trivial either.
It would require flushing the printf buffer for each drawcall
which might force synchronization and remove bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/129728
This was caused by `drw_ResourceID` taking one vertex input
(at slot 15) which was then also used by material shaders.
Starting material shaders at 14 in this case avoid the overlap.
Note that this reduces the amount of supported attribute when
using the workarounds by one.
Adding a dummy storage buffer to the classification shader
seems to fix the issue on Qualcomm drivers (WoA).
The workaround is added to the force workaround option to
allow other platforms to test the fix.
Rel #122837
Pull Request: https://projects.blender.org/blender/blender/pulls/129857
