Age | Commit message (Collapse) | Author |
|
Support for the AO and bevel shader nodes requires calling "optixTrace" from within the shading
VM, which is only allowed from inlined functions to the raygen program or callables. This patch
therefore converts the shading VM to use direct callables to make it work. To prevent performance
regressions a separate kernel module is compiled and used for this purpose.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9733
|
|
This encapsulates Node socket members behind a set of specific methods;
as such it is no longer possible to directly access Node class members
from exporters and parts of Cycles.
The methods are defined via the NODE_SOCKET_API macros in `graph/
node.h`, and are for getting or setting a specific socket's value, as
well as querying or modifying the state of its update flag.
The setters will check whether the value has changed and tag the socket
as modified appropriately. This will let us know how a Node has changed
and what to update, which is the first concrete step toward a more
granular scene update system.
Since the setters will tag the Node sockets as modified when passed
different data, this patch also removes the various modified methods
on Nodes in favor of Node::is_modified which checks the sockets'
update flags status.
Reviewed By: brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D8544
|
|
This avoids recomputing the BVH for geometries that do not have changes in topology but whose vertices are modified (like a simple character animation), and gives up to 40% speedup for BVH building.
This is only available for viewport renders at the moment.
Reviewed By: pmoursnv, brecht
Differential Revision: https://developer.blender.org/D9353
|
|
While Cycles already supports using both CPU and GPU at the same time, there
currently is a large problem with it: Since the CPU grabs one tile per thread,
at the end of the render the GPU runs out of new work but the CPU still needs
quite some time to finish its current times.
Having smaller tiles helps somewhat, but especially OpenCL rendering tends to
lose performance with smaller tiles.
Therefore, this commit adds support for tile stealing: When a GPU device runs
out of new tiles, it can signal the CPU to release one of its tiles.
This way, at the end of the render, the GPU quickly finishes the remaining
tiles instead of having to wait for the CPU.
Thanks to AMD for sponsoring this work!
Differential Revision: https://developer.blender.org/D9324
|
|
Rather than just printing a message and falling back to the CPU. For render
farms it's better to avoid a potentially slow render on the CPU if the intent
was to render on the GPU.
Ref T82193, D9086
|
|
This reverts commit 527f8b32b32187f754e5b176db6377736f9cb8ff. It is causing
motion blur test failures and crashes in some renders, reverting until this is
fixed.
|
|
This encapsulates Node socket members behind a set of specific methods;
as such it is no longer possible to directly access Node class members
from exporters and parts of Cycles.
The methods are defined via the NODE_SOCKET_API macros in `graph/
node.h`, and are for getting or setting a specific socket's value, as
well as querying or modifying the state of its update flag.
The setters will check whether the value has changed and tag the socket
as modified appropriately. This will let us know how a Node has changed
and what to update, which is the first concrete step toward a more
granular scene update system.
Since the setters will tag the Node sockets as modified when passed
different data, this patch also removes the various `modified` methods
on Nodes in favor of `Node::is_modified` which checks the sockets'
update flags status.
Reviewed By: brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D8544
|
|
|
|
NanoVDB is a platform-independent sparse volume data structure that makes it possible to
use OpenVDB volumes on the GPU. This patch uses it for volume rendering in Cycles,
replacing the previous usage of dense 3D textures.
Since it has a big impact on memory usage and performance and changes the OpenVDB
branch used for the rest of Blender as well, this is not enabled by default yet, which will
happen only after 2.82 was branched off. To enable it, build both dependencies and Blender
itself with the "WITH_NANOVDB" CMake option.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8794
|
|
This can happen for Intel OpenCL, now support arbitrary string length.
Differential Revision: https://developer.blender.org/D9020
|
|
|
|
In scenes such as Cosmos Laundromat, there were memory allocations bigger than
2GB which would overflow.
Problem and solution found by AMD, thanks!
|
|
Commit 009971ba7adc9603b90e9bf99b6b6d53eeae6c3a changed it so Cycles creates a separate
Embree device for each Cycles device, but missed the multi-device case. A multi-device with
Embree BVH can occur when CPU rendering is used with OptiX denoising and BVH creation then
failed to get a valid pointer to the Embree device, which crashed. This fixes that by providing the
correct device pointer in the multi-device case as well.
|
|
* Support precompiled libraries on Linux
* Add license headers
* Refactoring to deduplicate code
Includes work by Ray Molenkamp and Grische for precompiled libraries.
Ref D8769
|
|
Solves strict Clang warnings reported on Linux.
|
|
Before, Cycles was using a shared Embree device across all instances.
This could result in crashes when viewport rendering and material
preview were using Cycles simultaneously.
Fixes issue T80042
Maniphest Tasks: T80042
Differential Revision: https://developer.blender.org/D8772
|
|
|
|
We forgot to update this code as part of D3108. I'd like to include this in 2.90,
it's entirely broken now so can't really get any worse.
Differential Revision: https://developer.blender.org/D8738
|
|
The code uses OpenGL functionality, so is to be linked against
OpenGL libraries.
This makes it easier to integrate with cycles using CMake.
Differential Revision: https://developer.blender.org/D8371
|
|
This splits the volume related data (properties for rendering and attributes) of the Mesh node
into a new `Volume` node type.
This `Volume` node derives from the `Mesh` class since we generate a mesh for the bounds of the
volume, as such we can safely work on `Volumes` as if they were `Meshes`, e.g. for BVH creation.
However such code should still check for the geometry type of the object to be `MESH` or `VOLUME`
which may be bug prone if this is forgotten.
This is part of T79131.
Reviewed By: brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8538
|
|
This moves `Session::get_requested_device_features`,
`Session::load_kernels`, and `Session::update_scene` out of `Session`
and into `Scene`, as mentioned in D8544.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8590
|
|
|
|
The OptiX kernels are compiled for target "compute_sm_52", which is only available on second
generation Maxwell GPUs, so disable support for older ones.
|
|
one is found
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
|
|
|
|
Properly normalize buffers now. Also expose option to not use albedo and normal
just like OptiX.
|
|
|
|
This is not supported yet.
|
|
|
|
Performance is not great currently due to the API not seeming to support
efficient denoising of multiple tiles at the same time. So in many cases
only one or a few threads will actually be denoising at the same time.
In renders with many samples this is not a big problem, but for faster
renders it's a signficant overhead.
We should try to optimize this still, possibly by batching denoising of
a bigger neighborhood of multiple tiles at once.
|
|
|
|
This patch adds support for the curve primitive from OptiX to Cycles. It's currently hidden
behind a debug option, since there can be some slight rendering differences still (because no
backface culling is performed and something seems off with endcaps). The curve primitive
was added with the OptiX 7.1 SDK and requires a r450 driver or newer, so this also updates
the codebase to be able to build with the new SDK.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8223
|
|
OptiX) that uses unsupported features
Denoising devices do not need to load the full feature set of kernels, so only activate the denoising
feature for them (so that it is possible to use features that are supported by the render devices, but
not the denoising devices).
|
|
|
|
Apply the workaround only for known problematic drivers. The latest pro driver
appears to work correctly, hopefully the regular driver will as well once it
is updated to the same OpenCL driver version (3075.13).
|
|
|
|
|
|
|
|
Compared to Optix denoise, this is usually slower since there is no GPU
acceleration. Some optimizations may still be possible, in avoid copies
to the GPU and/or denoising less often.
The main thing is that this adds viewport denoising support for computers
without an NVIDIA GPU (as long as the CPU supports SSE 4.1, which is nearly
all of them).
Ref T76259
|
|
Enabling render and viewport denoising is now both done from the render
properties. View layers still can individually be enabled/disabled for
denoising and have their own denoising parameters.
Note that the denoising engine also affects how denoising data passes are
output even if no denoising happens on the render itself, to make the passes
compatible with the engine.
This includes internal refactoring for how denoising parameters are passed
along, trying to avoid code duplication and unclear naming.
Ref T76259
|
|
This keeps render results compatible for combined CPU + GPU rendering.
Peformance and quality primitives is quite different than before. There
are now two options:
* Rounded Ribbon: render hair as flat ribbon with (fake) rounded normals, for
fast rendering. Hair curves are subdivided with a fixed number of user
specified subdivisions.
This gives relatively good results, especially when used with the Principled
Hair BSDF and hair viewed from a typical distance. There are artifacts when
viewed closed up, though this was also the case with all previous primitives
(but different ones).
* 3D Curve: render hair as 3D curve, for accurate results when viewing hair
close up. This automatically subdivides the curve until it is smooth.
This gives higher quality than any of the previous primitives, but does come
at a performance cost and is somewhat slower than our previous Thick curves.
The main problem here is performance. For CPU and OpenCL rendering performance
seems usually quite close or better for similar quality results.
However for CUDA and Optix, performance of 3D curve intersection is problematic,
with e.g. 1.45x longer render time in Koro (though there is no equivalent quality
and rounded ribbons seem fine for that scene). Any help or ideas to optimize this
are welcome.
Ref T73778
Depends on D8012
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8013
|
|
Ref T73778
Depends on D8011
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8012
|
|
No significant performance improvement is expected, but it means we have a
single thread pool throughout Blender. And it should make adding more
parallellization in the future easier.
After previous refactoring commits this is basically a drop-in replacement.
One difference is that the task pool had a mechanism for scheduling tasks to
the front of the queue to minimize memory usage. TBB has a smarter algorithm
to balance depth-first and breadth-first scheduling of tasks and we assume that
removes the need to manually provide hints to the scheduler.
Fixes T77533
|
|
|
|
|
|
|
|
|
|
|
|
This patch makes the infamous "Cancel" error in the viewport a thing of the past. Instead it
now shows a more useful error message and streamlines the error handling process in CUDA.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8008
|
|
It would be good to use override for all member functions, but doing it for
only somes generates compiler warning.
|