| Age | Commit message (Collapse) | Author |
|---|
|
Use to avoid accidental missing break statements,
use ATTR_FALLTHROUGH to suppress.
|
|
|
|
|
|
Render data is never guarded by image drawe lock.
|
|
This feature was adding extra complexity to task scheduling
which required yet extra variables to be worried about to be
modified in atomic manner, which resulted in following issues:
- More complex code to maintain, which increases risks of
something going wrong when we modify the code.
- Extra barriers and/or locks during task scheduling, which
causes extra threading overhead.
- Unable to use some other implementation (such as TBB) even for
the comparison tests.
Notes about other changes.
There are two places where we really had to use that limit.
One of them is the single threaded dependency graph. This will
now construct a single-threaded scheduler at evaluation time.
This shouldn't be a problem because it only happens when using
debugging command line arguments and the code simply don't
run in regular Blender operation.
The code seems a bit duplicated here across old and new
depsgraph, but think it's OK since the old depsgraph is already
gone in 2.8 branch and i don't see where else we might want
to use such a single-threaded scheduler.
When/if we'll want to do so, we can move it to a centralized
single-threaded scheduler in threads.c.
OpenGL render was a bit more tricky to port, but basically we
are using conditional variables to wait background thread to
do all the job.
|
|
|
|
|
|
|
|
The renderpasses for grease pencil are not necessary when render from
sequencer.
This fix solves the GPF but we need to rethink the complete render
process for grease pencil and integrate better in the render and
composition workflow.
Thanks to Dalai Felinto por helping in the debug and fixing of the
problem.
|
|
empty
If the opengl render with grease pencil is run from VSE with the current
frame outside visible frames, the render pass is wrong and the render
must be canceled because nothing to render. Related to #T49975
|
|
Solution as suggested by Sergey Sharybin. Initial debugging by
Antonio Vazquez.
|
|
|
|
|
|
Flagging of pool to cancel was done in the wrong place, making last
frames missing in the final video.
|
|
Apparently, the whole G.is_break is not used by OpenGL render, meaning
this flag will not be clear before running the operator. This was
causing missing file output after pressing Esc once for the rest of
Blender session.
|
|
Previously if the rendering is much faster than saving (for example,
when transcoding stuff via VSE) it was possible to have 100s of frames
in memory.
This isn't ideal because of limited amount of RAM, so need to have
some sort of limit. This is exactly what is implemented in this commit.
|
|
By the design of task scheduler it was possible that tasks from somewhere
in the middle of scheduled list will be handled first.
For example, one thread might be iterating over the scheduled list and
ignore tasks because there is other thread is working on task from the
same pool. However, if that other thread finishes task before iteration
is over current thread will pick up task from somewhere in in the middle
of the list.
This isn't a problem in general case, but for movie rendering we do need
to have strict order of frames.
|
|
|
|
Also do not attempt to write any already scheduled frames.
|
|
Own regression since recent optimization.
|
|
rB6f92604e539b2114763150fb1ace60d28e59a889
Crashes occured immediately when clicking on "OpenGL render image" because there was only a task pool created previously when it was an animation. Solved it by introducing a variable is_animation to the openglrender and omitting the task_pool call when it's no animation.
@sergey: Please check my changes, moved the pool_ok and the lock into the is_animation clause.
|
|
The idea is to have a dedicated thread which is responsive for all the
file writing to a separate thread, so slow disk will not slow down
OpenGL itself.
Gives really nice speedup around 1.5x when exporting barber shop layout
file to h264 video.
|
|
Was copying things in other way around and was not performing
proper color space conversion.
|
|
It was annoyingly slow to do roundtrip from byte OpenGL render to
float render result and back to byte image format (which is used
in 99% of cases for the OpenGL previews),
Now we use render result's rect32 to store render result which is
already supposed to be in the display space.
Gives about 30% speed improvement for OpenGL previews here.
|
|
|
|
|
|
Improve current Grease Pencil in order to get a better 2D animation tool.
More info in WIKI pages: https://wiki.blender.org/index.php/User:Antoniov
Reviewed By: Severin, aligorith, campbellbarton
Patch by @antoniov, with edits by @Severin.
Differential Revision: https://developer.blender.org/D2115
|
|
Regression in d5f1b9c22,
threading deadlock rendering a scene from the OpenGL preview.
|
|
Such configuration used to cause quite confusing situation when
stamp will use actual scene's statistics but metadata from strip
will be used for the saved file (basically, causing different
information stamped and saved as metadata).
Don't think it was desired behavior and it's something what
artists here in the studio wants to be fixed.
|
|
|
|
|
|
|
|
|
|
Own regression in recent speedup commit.
|
|
The idea is to avoid having roundtrip from byte to float and back to byte buffer
and use render result's byte buffer to store result of sequencer rendering.
This actually matches to what regular render pipeline is doing and this gives
around 2-3 times speedup of sequencer export on a simple scenes.
|
|
|
|
This brings back old (slower), higher quality method.
Useful since graphics cards often use a faster MSAA which only oversamples edges.
|
|
Reduce code-paths so improvements to 3D view render apply to sequencer too.
|
|
`size_t` is useful for memory sizes or offsets,
the number of views wont realistically exceed an int.
|
|
Differential Revision: https://developer.blender.org/D1549
|
|
OpenGL sequencer render now uses a single fbo for all rendering.
|
|
Replaces much slower manual accumulation buffer which simply did multiple renders.
Needs OpenGL3.2, otherwise multi-sample is disabled.
|
|
Report an error instead of crashing if a new window can't be created
(typically caused by bad drivers).
|
|
Was silently failing.
|
|
This reverts commit d64b1221c67846bb954855a19c8dd093b83adc8e.
While this prevents the crash, offscreen renders still aren't working right.
|
|
non-power-of-2 texture support. Note that all I did was pass
the correct width/height into glReadPixels; the result may not
be the same as if non2 textures were enabled.
|
|
Add option to render strip metadata to final result, bypassing current
scene metadata.
|
|
|
|
file, since we need the updated times and frames.
This was lost during stamp code refactoring. The refactoring moved the
stamp when render is initialized so we would be guaranteed to have
correct cameras even when saving render stills at a later time (and even
if cameras were changed). For regular render this would work since
render init takes care of stamp, but for openGL rendering we need to do
this manually.
Still not 100% correct, does not apply multiview cameras to metadata
|
|
Camera here is incorrect for multiview (as is in real multiview render)
but at least it works now.
|
