This commit makes remove_table skip the freeing if the offset is
already set to invalid - or, if it wasn't, set it to invalid after freeing.
That's what the current code was already doing in the Manager classes,
this change allows them to just call remove without the additional code.
Also, two potential memory leaks where new tables were always allocated
without freeing the old ones are fixed.
Reviewers: sergey, dingto, brecht
Differential Revision: https://developer.blender.org/D1974
Swap the for-loops in the RenderBuffer reset code to follow the convention
of looping over y in the outer loop.
The improved cache performance won't really be noticable here, but it's nicer
if it follows the usual style.
* When Baking wasn't used we got an error.
* On top of Volume Nodes (NODES_FEATURE_VOLUME), we now also check if we need volume sampling code,
so we can disable that as well and save some further compilation time.
If the CUDA Toolkit is installed and the user is on Linux,
adaptive, feature based CUDA runtime compile is now possible to enable via:
* Environment flag CYCLES_CUDA_ADAPTIVE_COMPILE or
* Debug menu (Debug value 256) in the Cycles UI.
This commit simplifies the code for the image arrays. Instead of having 2 arrays for float and byte textures,
we now use an array here. This simplifies the code (avoids code duplication), and makes it possible to easily extend it
with float1 and half-float types in the future.
Only tested with CPU yet, plus some cleanup / code de-duplication is still possible here.
Reviewers: #cycles, sergey
Reviewed By: #cycles, sergey
Subscribers: jesterking, sergey
Differential Revision: https://developer.blender.org/D1969
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_n are not defined on this architecture
for some reason, however those functions are available.
Adding a workaround for newly used __sync_fetch_and_and() function.
Couple of issues here:
- Was a bug in heap memory allocation when run out
of allowed stack memory.
- Debug MSVC was failing because it uses separate
allocator for some sort of internal proxy thing,
which seems to be unable to be using stack memory
because allocator is being created in non-persistent
stack location.
Issue was that before writing to disk grids are clipped against the
density field's tree to optimize for memory/disk space, which in the
case of simulations with no density field results in all grids having
empty trees.
For now avoid clipping against empty grids, but perhaps in the future it
can be interresting to have some UI parameters to let the user choose
the grid used for clipping.
This mainly touches extern libraries and few debug-only places in intern.
Some summary:
- External libraries are not strict at all about missing declarations,
so we can rather safely remove such warning together with other strict
flags.
- Bullet has some static functions which are not used.
Those were commented out.
- Carve now has some unused debug-only functions commented out as well.
While we're on the way of getting rid of Carve, it makes sense to make
things a bit cleaner for the time being.
- In LZMA we have some parts disabled which gives some set but unused
variables which is rather correct.
- Elbeem had quite some variables set and never used because their usage
is inside of debug-only code which is commented out.
Note about patching upstream libraries: surely one might say that we
have to make local patchset against this, but own experience says it
only gives extra work trying to merge such tweaks to a new upstream
version and usually it's just faster to re-apply such fixes again after
bundling new upstream library.
Mainly makes logging less verbose when doing progressive sampling in viewport.
Such kind of verbosity is not really possible to be filtered out with `grep`
so let's reshuffle few lines of code.
Simple idea, use threads when dealing with "Copying Transformations to device"
scene update step. Only do it if there's enough objects in the scene.
Hopefully only brings less synchronization time and doesn't break anything.
From tests on my desktop this brings down transform update time from 58sec to
11sec on victor_cpu.blend scene from out benchmark.
This is an attempt to gracefully handle out-of-memory events
and stop rendering with an error message instead of a crash.
It uses bad_alloc exception, and usually i'm not really fond
of exceptions, but for such limited use for errors from which
we can't recover it should be fine.
Ideally we'll need to stop full Cycles Session, so viewport
render and persistent images frees all the memory, but that
we can support later, since it'll mainly related on telling
Blender what to do.
General rules are:
- Use as less exception handles as possible, try to find a
most geenric pace where to handle those.
For example, ccl::Session.
- Threads needs own handling, exception trap from one thread
will not catch exceptions from other threads.
That's why BVH build needs own thing.
Reviewers: brecht, juicyfruit, dingto, lukasstockner97
Differential Revision: https://developer.blender.org/D1898
This mimics behavior of default allocators in STL and allows all the routines
to catch out-of-memory exceptions and hopefully recover from that situation/
This commits implements threaded sorting of references when looking for
object spatial split. It mainly useful when doing initial binning, which
happens from main thread.
Gives nice speedup of BVH build for Bunny.blend: 36sec vs. 55sec for
the Rabbit mesh BVH build.
On more complex scenes the speedup is probably minimal, but still nice
to have more instant rendering for simplier scenes.
Some further tests with production scenes would be interesting.
Reviewers: juicyfruit, dingto, lukasstockner97, brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D1928
- Fix wrong current sample reported in the log
- Also includes fix for progressive refine log
- Explicitly print to the stdout that resumable render is enabled
- Print error message and abort when passing wrong values for the
resumable render. Never waste someone's compute power for wrong
render!
Fixes T48185: Cycles resumable num chunks breaks sample counter
This is to prevent situations such as when the camera gets very close to a mesh
and causes it to be tessellated into an excessive amount of micropolygons. In
REYES this is known as the eye-splits problem.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D1922
