The issue here is that originally, the step count for the geometry's
motion and the object transform's motion were tied together, so a
single variable is used to store that step count.
However, when using the velocity attribute, it's possible for the step
counts to differ, which will lead to an incorrect interpolated object
transform in the kernel.
Pull Request: https://projects.blender.org/blender/blender/pulls/133788
That version has a bunch of API changes, so by dropping support for older
versions we can remove old compatibility code.
Also, that version is required for OptiX support, so building a fully-featured
Cycles wasn't possible with older OSL anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/133746
Regardless of what mem info reports. We can't move this to the host, so
might as well try because the free memory might not be a reliable predictor
of success.
Pull Request: https://projects.blender.org/blender/blender/pulls/132912
With host mapped memory these can be shared, and we can't get back the
original host pointer unless we make a copy which is inefficient.
Also add asserts to verify this doesn't happen.
Pull Request: https://projects.blender.org/blender/blender/pulls/132912
This was not thread safe. And it's better to do them one by one to avoid
moving more than is needed, when another thread already freed up enough.
Thanks to Jorn Visser for investigating and finding this problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/132912
If one of the devices already used host happed memory but another not,
it would previously realloc both.
Thanks to Jorn Visser for investigating and finding this problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/132912
Should be a bit more efficient, and it fixes host memory fallback bugs,
where host memory was incorrectly freed during re-copy. For the case
where memory should get reallocated on the host, a new mem_move_to_host
was added.
Thanks to Jorn Visser for investigating and finding this problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/132912
The issue here is that motion_steps handling is a bit complex, and the
parallel synchronization of geometry does not play well with it.
The obvious result of this was a crash related to the main thread
checking attributes while the geometry sync was changing them, but
there was also another race condition that could result in ending up
with the wrong motion_steps.
Specific changes:
- Change place where `motion_steps` is set to avoid concurrent access
- Change the default `motion_steps` to zero, since they won't be
explicitly set if there's no motion now
- Don't skip `motion_steps` copy in `sync_X` since it's no longer set
in `sync_object` and we need to transfer the value in case it was set
to 3 by the velocity code since that's no longer the default
Pull Request: https://projects.blender.org/blender/blender/pulls/133669
OSL has OSL::ShaderGlobals, which contains all the state for OSL shader
execution. The renderer fills it out and hands a pointer to OSL, and any
callbacks (e.g. for querying attributes) get the pointer back.
In order to store renderer-specific data in it, there's a few opaque pointers
in the struct, but using those has led to a mess of reinterpret_cast<> and
pointer indirection in order to carry all the data around.
However, there is a way to do this nicer: Good old C-style struct inheritance.
In short: Unless you're doing pointer arithmetic, you can just add additional
data at the end of a base struct, and the rest of the code won't care.
In this case, this means that we can have our own ShaderGlobals struct and
add more Cycles-specific data at the end. Additionally, we can replace the
generic opaque void pointers with ones of the correct type, which saves us
from needing to cast them back.
Since we have a copy of ShaderGlobals for GPU OSL anyways, it's just a matter
of refactoring the code a bit to make use of that.
The advantages of this are:
- Avoids casts all over the place, just needs one cast to turn our
ShaderGlobals into the "base" type that OSL expects and one to turn the
pointer that OSL gives us on callbacks back into our "derived" type.
- Removes indirection, all the relevant stuff (sd, kg, state) is now
directly in the ShaderGlobals
- Removes some OSL-specific state from ShaderData, which helps to keep
memory usage down
Pull Request: https://projects.blender.org/blender/blender/pulls/133689
The oren_nayar_diffuse_bsdf closure in OSL had two issues:
- It broke when used with roughness of zero
- It only used the provided albedo for energy compensation, so it still
required the user to multiply with the albedo
Therefore, this handles the zero roughness corner case and includes
the albedo in the closure weight.
This makes no difference when using the closure through the Diffuse
or Principled BSDF nodes, only for custom OSL shaders.
Pull Request: https://projects.blender.org/blender/blender/pulls/133597
* Some libraries like Alembic and OpenColorIO for a long time removed
header dependencies on Boost.
* No need to have BOOST_LIBRARIES anymore, only BOOST_PYTHON_LIBRARIES
is a direct dependency through USD headers.
* OpenVDB is no longer a static library, no need to link its dependencies.
Pull Request: https://projects.blender.org/blender/blender/pulls/133424
Extract Boykov-Kolmogorov max flow algorithm from boost::graph. As part
of work towards removing Boost as a Blender dependency.
Together with #133347 this removes the last direct Blender dependency
on Boost.
Pull Request: https://projects.blender.org/blender/blender/pulls/132142
Without boost::locale, there seems no particular reason to modify the
global locale, we can just translate strings ourselves.
Other locale facets like numeric and time are also left unchanged
from the default, which is the "C" locale. This appears to match
previous Blender behavior with boost::locale. That protects against
bugs where formatting floats for I/O unexpectedly depends on the
system language.
Pull Request: https://projects.blender.org/blender/blender/pulls/133347
In a previous commit (1), adjustments to light tree traversal were made
to try and skip distant lights when deciding which light to sample
while within a world volume.
The skip wasn't implemented properly, and as a result distant lights
were still included in the light tree traversal in that sitaution.
And due to the way the skip was implemented, there were some
unintialized variables used in the processing of the distant lights
importance which caused artifacts on some platforms.
This commit fixes this issue by reverting the skip of distant lights
in that situation.
(1) blender/blender@6fbc958e89
Pull Request: https://projects.blender.org/blender/blender/pulls/132344
It is possible that the valid range computed from `theta` and the range
visible to the current pixel do not overlap. In this case the hair
section has no contribution.
Pull Request: https://projects.blender.org/blender/blender/pulls/133337
In Cycles, the subsurface scattering shader will switch to a
diffuse shader under a few different conditions to improve performance
and reduce noise.
This commit removes the "switch back to diffuse if the scattering
radius is less than a quarter of a pixel" optimization because in some
scenes, this can result in noticable lines as the shader transitions
between subsurface scattering and diffuse.
Pull Request: https://projects.blender.org/blender/blender/pulls/133245
Happens after f79cae2c59. Seems that Metal pre-processing could not
figure out that the inclusion is guarded behind `#ifdef`, so the
included file is expanded here and never again afterwards.
The pre-processing should be fixed, but for now just always include the file.
Pull Request: https://projects.blender.org/blender/blender/pulls/133336
