Commit Graph

858 Commits

Author SHA1 Message Date
c4f8aedbc2 Fix T84016: Cycles baking crash with OptiX after recent changes
This worked for CPU + GPU, but not GPU only.
2020-12-24 12:59:35 +01:00
b2edc716c1 Fix Cycles OptiX runtime compilation broken after shader raytracing
Need to pass the appropriate flags as we do for compilation as part of the
CMake build.
2020-12-22 15:08:59 +01:00
001f2c5d50 Cleanup: spelling 2020-12-15 12:34:25 +11:00
f762d37790 Cycles: enable OpenCL rendering on recent Intel GPUs
Based on testing by Intel, rendering on Iris GPUs and upcoming Xe GPUs
should work. This is enabled on Windows and Linux.

More testing is needed to verify correctness and performance in production
scenes, but our basic benchmark files seem to give correct results.
2020-12-11 17:37:54 +01:00
c6626a2f8a Cleanup: compiler warnings
If you mark one function as override in a class, all must be marked.
2020-12-11 17:37:31 +01:00
bfb6fce659 Cycles: Add CPU+GPU rendering support with OptiX
Adds support for building multiple BVH types in order to support using both CPU and OptiX
devices for rendering simultaneously. Primitive packing for Embree and OptiX is now
standalone, so it only needs to be run once and can be shared between the two. Additionally,
BVH building was made a device call, so that each device backend can decide how to
perform the building. The multi-device for instance creates a special multi-BVH that holds
references to several sub-BVHs, one for each sub-device.

Reviewed By: brecht, kevindietrich

Differential Revision: https://developer.blender.org/D9718
2020-12-11 13:24:29 +01:00
612b83bbd1 Cycles: Enable baking panel in OptiX and redirect those requests to CUDA for now
This enables support for baking when OptiX is active, but uses CUDA for that behind the scenes, since
the way baking is currently implemented does not work well with OptiX.

Reviewed By: brecht

Differential Revision: https://developer.blender.org/D9784
2020-12-08 16:06:39 +01:00
c10546f5e9 Cycles: Add support for shader raytracing in OptiX
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
2020-12-04 13:04:11 +01:00
31a620b942 Cycles API: encapsulate Node socket members
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
2020-11-04 13:03:33 +01:00
57d1aea64f Cycles: add support for BVH refit in OptiX
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
2020-11-03 18:05:29 +01:00
517ff40b12 Cycles: Implement tile stealing to improve CPU+GPU rendering performance
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
2020-10-31 01:57:39 +01:00
f75b09e7e6 Cycles: abort rendering when --cycles-device not found
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
2020-10-29 16:01:38 +01:00
30f626fe4c Revert "Cycles API: encapsulate Node socket members"
This reverts commit 527f8b32b3. It is causing
motion blur test failures and crashes in some renders, reverting until this is
fixed.
2020-10-27 11:40:42 +01:00
527f8b32b3 Cycles API: encapsulate Node socket members
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
2020-10-26 23:11:14 +01:00
841eaebfa4 Cycles: Add support for OptiX 7.2 SDK 2020-10-26 15:43:55 +01:00
3df90de6c2 Cycles: Add NanoVDB support for rendering volumes
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
2020-10-05 15:03:30 +02:00
Matt McClellan
1d985159ad Fix Cycles OpenCL failing when extension string is long
This can happen for Intel OpenCL, now support arbitrary string length.

Differential Revision: https://developer.blender.org/D9020
2020-10-05 14:04:06 +02:00
14b2a35c8b Cleanup: use parenthesis for if statements in macros 2020-09-19 16:28:17 +10:00
3dbb231ed2 Fix OpenCL render error in large scenes
In scenes such as Cosmos Laundromat, there were memory allocations bigger than
2GB which would overflow.

Problem and solution found by AMD, thanks!
2020-09-17 13:07:28 +02:00
9f12ea496a Fix T80477: Crash when rendering with Embree but denoising with OptiX
Commit 009971ba7a 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.
2020-09-15 14:58:19 +02:00
f04260d8c6 CMake: refresh building and external library handling of Cycles standalone
* Support precompiled libraries on Linux
* Add license headers
* Refactoring to deduplicate code

Includes work by Ray Molenkamp and Grische for precompiled libraries.

Ref D8769
2020-09-04 17:10:50 +02:00
3e3e42cbcb Cycles: Cleanup, mark overridden virtual methods as such
Solves strict Clang warnings reported on Linux.
2020-09-04 12:37:25 +02:00
Stefan Werner
009971ba7a Cycles: Separate Embree device for each CPU Device.
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
2020-09-01 21:00:55 +02:00
2bb60db94a Merge branch 'blender-v2.90-release' 2020-08-28 14:00:51 +02:00
d3f2037966 Fix T80149: Cycles OpenCL baking broken after changes to uses tiles for baking
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
2020-08-28 12:53:50 +02:00
Imre Palik
afbc727da2 Cycles: Fix missing dependencies in libcycles_device
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
2020-08-24 11:45:47 +02:00
aa1e4baa22 Cycles : add a Volume Geometry Node
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
2020-08-19 15:47:09 +02:00
c82166ffcd Cycles: move some Scene related methods out of Session
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
2020-08-18 11:50:37 +02:00
d64e171c4b Cycles: Enable OptiX on first generation Maxwell GPUs again 2020-07-27 16:11:00 +02:00
c64b12c0b8 Fix OptiX being shown as available on first generation Maxwell GPUs
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.
2020-07-24 15:36:09 +02:00
a9644c812f Cycles: Use pre-compiled PTX kernel for older generation when no matching 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
2020-07-20 19:25:27 +02:00
5338b36fcc Cleanup: spelling 2020-07-14 15:19:52 +10:00
6e74a8b69f Fix T78881: Cycles OpenImageDenoise not using albedo and normal correctly
Properly normalize buffers now. Also expose option to not use albedo and normal
just like OptiX.
2020-07-13 19:38:49 +02:00
651db1b26f Cleanup: spelling 2020-07-11 15:32:59 +10:00
3dc0178390 Fix T78662: Cycles baking fails if denoising is enabled, after recent changes
This is not supported yet.
2020-07-10 20:08:46 +02:00
6fbacd6048 Fix build error building without OpenImageDenoise 2020-07-10 19:56:53 +02:00
6eeb32706a Cycles: support OpenImageDenoise in final renders
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.
2020-07-10 17:10:05 +02:00
93791381fe Cleanup: reduce hardcoded numbers in denoising neighbor tiles code 2020-07-10 17:10:05 +02:00
737bd549b6 Cycles: Add support for native OptiX curve primitive
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
2020-07-07 15:39:02 +02:00
1562c9f031 Fix OptiX viewport denoising not working when rendering scene (without 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).
2020-07-06 17:33:04 +02:00
792cb8bdc7 Fix T77984: Cycles OpenCL error rendering empty scene 2020-07-01 20:01:25 +02:00
2d8c59ccb9 Fix T77095: fix Cycles performance regression with AMD RX cards
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).
2020-06-30 12:01:40 +02:00
fb68a30af6 Fix crash compiling Cycles OpenCL, after recent TBB changes 2020-06-26 17:44:24 +02:00
fd5c185beb Cleanup: spelling 2020-06-25 23:14:36 +10:00
b4e1571d0b Cleanup: compiler warnings 2020-06-24 17:25:44 +02:00
669befdfbe Cycles: add Intel OpenImageDenoise support for viewport denoising
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
2020-06-24 15:17:36 +02:00
0a3bde6300 Cycles: add denoising settings to the render properties
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
2020-06-24 15:17:36 +02:00
207338bb58 Cycles: port curve-ray intersection from Embree for use in Cycles GPU
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
2020-06-22 13:28:01 +02:00
d1ef5146d7 Cycles: remove SIMD BVH optimizations, to be replaced by Embree
Ref T73778

Depends on D8011

Maniphest Tasks: T73778

Differential Revision: https://developer.blender.org/D8012
2020-06-22 13:28:01 +02:00
e50f1ddc65 Cycles: use TBB for task pools and task scheduler
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
2020-06-22 13:27:37 +02:00