| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
There is not much sense to have a whole BLI file just to check SSE2 on CPUs...
So idea is to rename it to more generic "BLI_system", and add to it more system-related
utils, like e.g. an include helper for getpid(), which allows to hide unix/windows
internals from rest of the code...
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D439
|
|
Issue is likely caused by thread-unsafe nature of IMB_freeImBuf
which might lead to race condition in some circumstances.
Now made it thread-safe and from Sebastian's tests seems crash is
gone now, so hopefully the root of the issue is finally nailed down.
|
|
|
|
|
|
drop to 0
Issue was caused by the cache limitor which was removing 4k textures from the
memory when accessing other images.
This is pretty much awful situation and solved by making it so only image sequences
and movies ace cache-guarded.
Could be optimized further so images used by viewport are not being freed, but
that's much more tricky to do..
This is a nice candidature for 'a'.
|
|
.mka files were considered image files when adding to sequencer
using drag-n-drop.
|
|
|
|
|
|
Basically proxy colorspace didn't work well enough.
It is still a bit weird and mainly:
- Proxies for image sequences are built in the image color space.
- Proxies for movies are built in the movie color space.
This could be unified but would need some work in proxy build
to make it not just pipe frames from one FFmpeg context to
another but also apply OCIO on it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Was a regression since avg_frame_rate changes.
Didn't find reliable way to get stream duration which will
work with both FFmpeg and Libav so added some freaking black
magic to distinguish one from another.
|
|
don't use extension checking preference for low level loading functions,
otherwise a user preference may impact a script loading a file for example.
looked into making this an argument and passing it in, but theres no
real advantage and its simpler just to remove.
|
|
|
|
BLI_testextensie
also use attributes for BLI path functions
|
|
av_close_input_file()
|
|
r_frame_rate is a guessed number defined as "the least common multiple of
all framerates in the stream". It has been deprecated and removed in new
Libav releases.
Use avg_frame_rate instead, which is the average framerate of the
stream.
|
|
avcodec_encode_video() has been replaced with avcodec_encode_video2()
in new libavcodec versions.
|
|
CODEC_ID_* have been replaced with AV_CODEC_ID_* in new libavcodec
versions.
Update the code to use those new identifiers.
Added a compatibility code to ffmpeg_compat.h
|
|
* EXR layers with names like 'Z' without any pass name were not loaded at all
and would break the Combined pass as well.
* EXR pass names longer than 16 characters where writing past the end of the
array and getting invalid names.
|
|
- Made them receive number of channels rather than number of planes.
This matches to how ImBuf structure stored planes and channels.
- IMB_premultiply_rect_float() was called with channels passed instead
of planes already :S.
|
|
|
|
This code has been broken for a few years and no one noticed, it's also less
useful now that we support PSD image loading ourselves which was the original
motivation to have this.
|
|
Issue was caused by cache limitor removing viewer image buffer
from the memory during compositing. Now made it so all viewer
images are persistent in the memory.
This solves the crash mentioned above and also makes it so
render/compo results are never lost.
Further tweaks are possible, but pretty much happy now, at
least no stoppers for work are there.
|
|
|
|
|
|
Summary:
Issue was caused by the same tile being written twice to
the EXR file. This was happening because of partial update
of work-in-progress tiles was merging result to the final
render result in order to make color management pipeline
happy.
We need to avoid such a merges and keep memory usage as
low as possible when Save Buffers is enabled.
Now render pipeline will allocate special display buffer
in render layer which will contain combined pass in the
display space. This keeps memory usage as low as we can
do at this moment.
There's one weak thing which is changing color management
settings during rendering would lead to lossy conversion.
This is because render result's display buffer uses color
space from the time when rendering was invoked.
This is actually what was happening in previous release
already actually so not a big issue.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D162
|
|
It allows to schedule tasks of smaller size without having
threads overhead or extra worry about splitting tasks into
smaller pieces.
This simplifies code in color management which was manually
splitting task into smaller chunks to keep memory usage low.
Further optimization is possible by avoid malloc called from
threads, but that's how it used to work for ages already
and would be optimized as a separate patch.
|
|
This callback is used when cache limiter needs to remove
some cached objects when running out of limit.
From blender side it's used to keep painted images always
in memory.
This fixes issue when painted images were removing from
the memory after image cache rewrite.
|
|
It applies color management on a pixel in a way, based on number of
channels of this pixel.
Simplifies partial update code a bit.
|
|
It was only used by opengl render and in fact it needed just to
set DISPLAY_BUFFER_INVALID flag for the image buffer.
In theory it wouldn't make any change to opengl render speed
(because this change just moved rect_from_float from color
management code to image save code). And could not see any speed
changes on my laptop.
|
|
The issue wasn't new in fact, just partial buffer update
function was still broken. Not sure how those issues were
not noticed for so long.
Perhaps partial_buffer_update_rect() could be simplified,
but i've got some more upcoming changes here which might
run into conflicts if i'll do simplification now.
|
|
Summary:
Mainly addressed to solve old TODO with color managed fallback
to CPU mode when displaying render result during rendering.
That fallback was caused by the fact that partial image update
was always acquiring image buffer for composite output and was
only modifying display buffer directly.
This was a big issue for Cycles rendering which renders layers
one by one and wanted to display progress of each individual
layer. This lead to situations when display buffer was based on
what Cycles passes via RenderResult and didn't take layer/pass
from image editor header into account.
Now made it so image buffer which partial update is operating
with always corresponds to what is set in image editor header.
To make Cycles displaying progress of all the layers one by one
made it so image_rect_update switches image editor user to
newly rendering render layer. It happens only once when render
engine starts rendering next render layer, so should not be
annoying for navigation during rendering.
Additional change to render engines was done to make it so
they're able to merge composite output to final result
without marking tile as done. This is done via do_merge_result
argument to end_result() callback. This argument is optional
so should not break script compatibility.
Additional changes:
- Partial display update for Blender Internal now happens from
the same thread as tile rendering. This makes it so display
conversion (which could be pretty heavy actually) is done in
separate threads. Also gives better UI feedback when rendering
easy scene with small tiles.
- Avoid freeing/allocating byte buffer for render result
if it's owned by the image buffer. Only mark it as invalid
for color management.
Saves loads of buffer re-allocations in cases when having
several image editors opened with render result. This change
in conjunction with the rest of the patch gave around
50%-100% speedup of render time when displaying non-combined
pass during rendering on my laptop.
- Partial display buffer update was wrong for buffers with number
of channels different from 4.
- Remove unused window from RenderJob.
- Made image_buffer_rect_update static since it's only used
in single file.
Reviewers: brecht
Reviewed By: brecht
CC: dingto
Differential Revision: http://developer.blender.org/D98
|
|
Cache iterator might return unused keys as well.
Now unused keys are being removed before cleanup
and iteration.
|
|
limit
|
|
Before this it was a runtime check for number of displays/views
which is rather really annoying.
This simplifies code a bit and allows to do some more tricks
in other patches.
|
|
Cast dimensions to size_t before multiplication.
Also made add_ibuf_size survive cases when image
buffer allocation failed.
|
|
|
|
|
|
Summary:
Behaves very much the same as cache for Movie Clip datablock:
- Image now have `MovieCache *cache` field which replaced
legacy `ListBase ibufs`.
This allows image datablock to easily keep of image
buffers which are owned by itself. This field isn't
saved to the file and getting restored on undo steps.
However, cache limit is global for movies, sequences
and image datablocks now. So overall cached image buffers
size will not go above cache limit size in user
preferences.
- Image buffers which are marked as BITMAPDIRTY will never
be freed from the cache.
- Added utility function to iterate over image buffers
saved in movie cache.
- Movie cache cleanup check callback now have ImBuf argument
which can be used in a condition of cleanup.
- Added some utility functions which replaces legacy ibufs
iterations with image cache iteration which happens from
inside a lock.
- Fixed `image_mem_size()` which was only counting one of
the buffers if both float and byte buffer present.
Additional notes:
- `BKE_image_get_first_ibuf()` is rather stupid, but direct
access to ibufs->first was also the same stupid idea.
Would consider avoid this function is another project.
- There are some places which doesn't look threadsafe, but
they already were not so much threadsafe anyway before.
So think not a big deal with solving this later.
Finally solves infinite memory usage by image sequences! :)
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: sebastian_k
Differential Revision: http://developer.blender.org/D95
|
|
Summary:
Uses some magic pseudo-random which is actually a
texture coordinate hashing function.
TODOs:
- Dither noise is the same for all the frames.
- It's different from Floyd's dither we've been
using before.
- Currently CPU and GPU dithering used different
implementation. Ideally we need to use the same
dither in CPU.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: http://developer.blender.org/D58
|
