The following commits were supposed to add anti-alias and help with OSL
baking:
7b16fda3799d5b7167ef7ffe533d654810f44e36
1b92dfa96160f8151972d73337d5a927d8b89297
However they introduced other issues (artifacts mostly), see T43550 .
Leaving the code ifdef'ed for now.
This attribute missed derivatives calculation.
Not totally sure what's the proper approach for algebraic derivative
calculation, so calculating them by definition. This isn't fastest
way to do it in this case and could be replaced with some smarter magic
in the wireframe calculation loop.
At least currently implemented approach is better than nothing.
It was complaining about explicit __constant to __private memory conversion,
which is now worked around using implicit conversion.
It's not a real fix i'm afraid and i'm still failing to build OpenCL kernel
with latest Linux drivers, but maybe it'll let someone else to investigate
what causes compiler to run out of memory?
Issue was caused by the changes in 7b16fda which changed the initial
state for rng. This commit makes it so the same initial hash is used
(which solves the regression without distorting AA-looking image.
It also makes it so OpenCL compiler is happy about this code (before
this change it'll complain about trying to cast private variable to
global one).
Ideally we should get rid of those temporary vectors anyway, but
it's not so trivial because of the alignment. For untl then we'll
just have a bit worse solution. This part of code is not the root
of the issue of memory spikes for now anyway.
But since we're getting rid of temporary memory earlier actual spike
is a bit smaller as now. For example in franck_sheep file it's now
5489.69MB vs. previously 5599.90MB.
Simple change: just get rid of intermediate data a bit earlier, before
final pixels array is being allocated. This gives around 30% of memory
save during light update (this is about 60meg in the frank sheep file
i'm using here).
This isn't really visible by artists a lot, because actual spike happens
on BVH construction. But it doesn't mean we shouldn't be accurate with
memory usage in other areas.
OpenCL doesn't let you to get address of vector components, which
is kinda annoying. On the other hand, maybe now compiler will have
more chances to optimize something out.
Title pretty says it all actually. Can only briefly mention that we're
indeed entering that state when after applying some WIP patches having
much fuller statistics about memory usage would help giving exact memory
benefit.
This flag is global for all the sessions and never changes. so it doesn't
really make sense to pass it around to all sessions and synchronization
routines.
Switched to a static member of BlenderSession now, but it's probably more
logical to introduce some sort of BlenderGlobals. Doesn't currently worth
a hassle for a single boolean flag tho.
It could have happened with really long rays and small steps.
Step size will be adjusted to the clamped number of steps in order
to preserve render result compatibility as much as possible.
We should probably reformulate this a bit, so it will give the
same looking results without step tweaks. But this new behavior
should already be much better that it was before.
The workaround for generated texture coordinates is to be done before
calculating number of elements for attribute, otherwise counter wouldn't
include those attributes.
The idea behind the change is to pre-allocate attribute arrays in advance,
which avoids re-allocation of arrays later for each of meshes being handled.
This reduces peak memory used by Cycles database from 1.3G to 0.9G for
victor.blend from Gooseberry.
It doesn't mean every file will benefit from this change since peak memory
usage is happening in the different places of the rendering code.
Also, unfortunately, attributes export might not cause the peak of render
preparation stage. That said, it's actually object_to_mesh() which causes
the memory to peak in the same test file. So we really need to optimize that
part first in order to get visible results for artists. But in any case it's
now quite easy to track hotspots in Cycles itself which is good.
It's actually a bad level call, but it's inside ifdef block and disabled by
default and only intended to be used for development purposes.
Main idea of this change is to combine statistics coming from Cycles and
Blender during scene synchronization step, to see if further changes are
actually reducing memory footprint.
The method is called vector::free_memory(). Use with care since it'll invalidate
all the pointers to vector memory, all iterators and so on.
Currently unused, but might become handy when clearing unused data.
