After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.
Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.
This fixes T88598.
Differential Revision: https://developer.blender.org/D11415
In 2.81 there was a change to increase the performance of viewport
animation rendering. This change would perform the color management on the
GPU if the only 8bit was needed. This saved CPU cycles and data
transfer.
The issue is that in the image editor or when saving the image the CM
will be reapplied. Although the speed is desired, exporting the actual
colors has more priority.
In the ticket there is an analysis that shows that shows that this fix
is the correct short term step to take. It would be better that the
render result is aware of the color space of its buffers so the applying
color management could be skipped when saving to disk or drawing in the
image editor.
The issue with this change is the performance penalty it has.
Reviewed By: Brecht van Lommel
Maniphest Tasks: T79999
Differential Revision: https://developer.blender.org/D10371
Caused by rB5b34d11b55e0.
Above commit restored the view matrices in ED_view3d_draw_offscreen
_before_ they can be stored in the ImBuff (see ED_view3d_draw_offscreen
/ texture_paint_image_from_view_exec).
Now make restoring the view matrices optional and dont do this in case
of reprojection, so the used matrices can still be saved in the ImBuff
later.
Reviewed By: campbellbarton
Maniphest Tasks: T85395
Differential Revision: https://developer.blender.org/D10331
This is was caused by incorrectly set preview_render_size in VSE
rendering context. Value was set to SEQ_PROXY_RENDER_SIZE_FULL, but
it should be SEQ_PROXY_RENDER_SIZE_SCENE as scene render size is
being used.
This is same fix as 0d7036b40e, but I did not checked openGL
render pipeline.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9562
Replace BKE_sequencer wirh SEQ_render or SEQ_proxy prefixes.
In cases where function is very generic, only SEQ prefix is used.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9439
- BKE_bezt_subdivide_handles -> BKE_fcurve_bezt_subdivide_handles
- binarysearch_bezt_index -> BKE_fcurve_bezt_binarysearch_index
These functions are specific to F-Curves and don't make sense for other
uses of BezTriple (curve-object data for e.g.)
Also:
- Move detailed doxygen comment above code, following code-style.
- Mark bezt_add_to_cfra_elem unused.
During viewport render animation the gpu textures weren't tagged as
invalid. As the image uv editor now draws the gpu texture only the first
was shown as it wasn't refreshed with the actual image data.
This replace `GPU_clear()` by `GPU_clear_color()` and `GPU_clear_depth()`.
Since we always set the clear value before clearing, it is unecessary
to track the clear color state.
Moreover, it makes it clearer what we clear the framebuffer to.
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
This patch enables TBB as the default task scheduler. TBB stands for Threading Building Blocks and is developed by Intel. The library contains several threading patters. This patch maps blenders BLI_task_* function to their counterpart. After this patch we can add more patterns. A promising one is TBB:graph that can be used for depsgraph, draw manager and compositor.
Performance changes depends on the actual hardware. It was tested on different hardwares from laptops to workstations and we didn't detected any downgrade of the performance.
* Linux Xeon E5-2699 v4 got FPS boost from 12 to 17 using Spring's 04_010_A.anim.blend.
* AMD Ryzen Threadripper 2990WX 32-Core Animation playback goes from 9.5-10.5 FPS to 13.0-14.0 FPS on Agent 327 , 10_03_B.anim.blend.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D7475
This data block will be the container for simulation node trees.
It will be used for the new particle node system (T73324).
The new data block has the type `ID_SIM`.
It is not visible to users and other developers by default yet.
To enable it, activate the cmake option `WITH_NEW_SIMULATION_TYPE`.
New simulation data blocks can be created by running `bpy.data.simulations.new("name")`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7225
Tasks: move priority from task to task pool {rBf7c18df4f599fe39ffc914e645e504fcdbee8636}
Tasks: split task.c into task_pool.cc and task_iterator.c {rB4ada1d267749931ca934a74b14a82479bcaa92e0}
Differential Revision: https://developer.blender.org/D7385
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
Both the MS headers and blender headers define the HKEY
which gives all kind of inclusion order issues.
This diff renames all *KEY constants to EVT_*KEY to resolve
this conflict.
Reviewed By: brecht , dfelinto
Differential Revision: http://developer.blender.org/D7164
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
Motivation the functions get 3 different kind of flag parameters (ImBuf,
DrawType, OffscreenRendering) the naming of the flags were not clear,
leading to mistakes and unnecessary time spend debugging.
Using a struct here allows to change given parameters to the callbacks
without having to edit all callbacks functions, which is always noisy
and time consuming.
The Viewport Render Keyframes operator didn't include keyframes from
grease pencil animation or from mesh shape key animation (see T72861).
To find all related datablocks that could be considered as part of the
selected object, `BKE_library_foreach_ID_link(..., IDWALK_RECURSE)` is
used. To prevent relations like constraint targets from being visited,
the recursion is stopped when it finds a different object.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D6558
This feature makes it possible to do a viewport render (a.k.a.
playblast) by only rendering those frames on which the selected objects
have a keyframe.
The frames to render are stored in a `BLI_bitmap`, which has a bit for
each frame set to 0 (skip) or 1 (render). An alternative approach would
be to construct a set of all keyframes to render, but that would make
both constructing the list and looking up frames in the list more
complex.
The only thing this feature does is skip OpenGL rendering of a frame. As
a result, 'skipped' frames are still included in the output, but just
use the render result of the last-rendered frame. This is exactly what's
described in T72229.
Differential Revision: https://developer.blender.org/D6443
Reviewed By: zeddb
Design task: T72229
The tooltip was static, so it was the same for viewport-rendering the
current frame and for the entire animation. It is now different for
those two.
The structure of `screen_opengl_render_description()` is such that it
allows for adding a new description for a soon-to-come feature (T72229).
Multisample buffers were used for smooth line drawing. As we now have
an algorithm that doesn't need the multisample buffers we can remove
them.
The user preference for viewport multi_sampling is replaced by single
toggle overlay `use_overlay_smooth_wire`. By default this setting is
enabled as the new drawing is really quick (<1ms) and uses zero hacks.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6367
When using Render Viewport Animation the meta data
was only stamped when a float buffer was used. In recent changes it was
possible to use a char buffer for the result.
This commit will also support stamping of metadata using a char buffer.
When doing viewport rendering the color management happens on the CPU.
This has overhead in downloading a float texture from the gpu and
performing color management on the CPU.
Based on the scene fileformat bit depth the result will be rendered to
a byte texture where the colormanagement happens on the GPU or a float
texture where the colormanagement happens on the CPU.
This is only done during `Viewport Render Animation` in other
cases a float texture is being used.
Baseline (HD render of wanderer.blend workbench engine no samples) 15.688038 s
After changes: 9.412880s
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6195
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
When exporting annotations using `bpy.ops.render.opengl` the annotations
where only correct in the first frame. In the second frame the
annotations was shifted by half the resolution.
This change will reset the GPU matrices when the annotations are
rendered.
