bartvdbraak/blender
1
0
Fork 4
Code Issues 4 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity
4b8434fabd
blender/intern/cycles/bvh/bvh.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

140 lines
3.8 KiB
C++
Raw Normal View History

Cycles: use SPDX license headers * Replace license text in headers with SPDX identifiers. * Remove specific license info from outdated readme.txt, instead leave details to the source files. * Add list of SPDX license identifiers used, and corresponding license texts. * Update copyright dates while we're at it. Ref D14069, T95597
2022-02-11 12:53:21 +00:00
/* SPDX-License-Identifier: Apache-2.0
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
* Adapted from code copyright 2009-2010 NVIDIA Corporation
Cycles: use SPDX license headers * Replace license text in headers with SPDX identifiers. * Remove specific license info from outdated readme.txt, instead leave details to the source files. * Add list of SPDX license identifiers used, and corresponding license texts. * Update copyright dates while we're at it. Ref D14069, T95597
2022-02-11 12:53:21 +00:00
* Modifications Copyright 2011-2022 Blender Foundation. */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Split BVH implementations into separate files
2017-04-13 08:55:46 +00:00
#include "bvh/bvh.h"
#include "bvh/bvh2.h"
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 12:19:19 +00:00
#include "bvh/embree.h"
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
#include "bvh/hiprt.h"
Cycles: Metal host-side code This patch adds the Metal host-side code: - Add all core host-side Metal backend files (device_impl, queue, etc) - Add MetalRT BVH setup files - Integrate with Cycles device enumeration code - Revive `path_source_replace_includes` in util/path (required for MSL compilation) This patch also includes a couple of small kernel-side fixes: - Add an implementation of `lgammaf` for Metal [Nemes, Gergő (2010), "New asymptotic expansion for the Gamma function", Archiv der Mathematik](https://users.renyi.hu/~gergonemes/) - include "work_stealing.h" inside the Metal context class because it accesses state now Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13423
2021-12-07 15:11:35 +00:00
#include "bvh/metal.h"
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 12:19:19 +00:00
#include "bvh/multi.h"
#include "bvh/optix.h"
Cycles: Added Embree as BVH option for CPU renders. Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag. Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly. There, Embree is off by default too and must be enabled with the WITH_EMBREE flag. Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint. TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache). Differential Revision: https://developer.blender.org/D3682
2018-11-07 11:58:12 +00:00
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 12:19:19 +00:00
#include "util/log.h"
#include "util/progress.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
CCL_NAMESPACE_BEGIN
Cycles: Replace use_qbvh boolean flag with an enum-based property This was we can introduce other types of BVH, for example, wider ones, without causing too much mess around boolean flags. Thoughs: - Ideally device info should probably return bitflag of what BVH types it supports. It is possible to implement based on simple logic in device/ and mesh.cpp, rest of the changes will stay the same. - Not happy with workarounds in util_debug and duplicated enum in kernel. Maybe enbum should be stores in kernel, but then it's kind of weird to include kernel types from utils. Soudns some cyclkic dependency. Reviewers: brecht, maxim_d33 Reviewed By: brecht Differential Revision: https://developer.blender.org/D3011
2018-01-19 09:59:58 +00:00
/* BVH Parameters. */
const char *bvh_layout_name(BVHLayout layout)
{
switch (layout) {
case BVH_LAYOUT_NONE:
return "NONE";
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-10 13:18:25 +00:00
case BVH_LAYOUT_BVH2:
return "BVH2";
Cycles: Added Embree as BVH option for CPU renders. Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag. Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly. There, Embree is off by default too and must be enabled with the WITH_EMBREE flag. Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint. TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache). Differential Revision: https://developer.blender.org/D3682
2018-11-07 11:58:12 +00:00
case BVH_LAYOUT_EMBREE:
return "EMBREE";
Cycles: add Optix device backend This uses hardware-accelerated raytracing on NVIDIA RTX graphics cards. It is still currently experimental. Most features are supported, but a few are still missing like baking, branched path tracing and using CPU memory. https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles#NVIDIA_RTX For building with Optix support, the Optix SDK must be installed. See here for build instructions: https://wiki.blender.org/wiki/Building_Blender/CUDA Differential Revision: https://developer.blender.org/D5363
2019-09-12 12:50:06 +00:00
case BVH_LAYOUT_OPTIX:
return "OPTIX";
Cycles: MetalRT support (kernel side) This patch adds MetalRT support to Cycles kernel code. It is mostly additive in nature or confined to Metal-specific code, however there are a few areas where this interacts with other code: - MetalRT closely follows the Optix implementation, and in some cases (notably handling of transforms) it makes sense to extend Optix special-casing to MetalRT. For these generalisations we now have `__KERNEL_GPU_RAYTRACING__` instead of `__KERNEL_OPTIX__`. - MetalRT doesn't support primitive offsetting (as with `primitiveIndexOffset` in Optix), so we define and populate a new kernel texture, `__object_prim_offset`, containing per-object primitive / curve-segment offsets. This is referenced and applied in MetalRT intersection handlers. - Two new BVH layout enum values have been added: `BVH_LAYOUT_METAL` and `BVH_LAYOUT_MULTI_METAL_EMBREE` for XPU mode). Some host-side enum case handling has been updated where it is trivial to do so. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13353
2021-11-29 15:06:22 +00:00
case BVH_LAYOUT_METAL:
return "METAL";
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
case BVH_LAYOUT_HIPRT:
return "HIPRT";
Cycles: fix multi-device rendering with oneAPI and Hardware Raytracing Only Embree CPU BVH was built in the multi-device case. However, one Embree GPU BVH is needed per GPU, so we now reuse the same logic as in the other backends. Pull Request: https://projects.blender.org/blender/blender/pulls/107992
2023-05-16 21:26:19 +00:00
case BVH_LAYOUT_EMBREEGPU:
return "EMBREEGPU";
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-10 13:18:25 +00:00
case BVH_LAYOUT_MULTI_OPTIX:
Fix T94022: Both options GPU/CPU checked under preferences cause viewport render crash. (ARM/Metal) This fixes crash T94022 when selecting live viewport render with both GPU & CPU devices selected. It is caused by incorrect `KernelBVHLayout` assignment. Similar to `BVH_LAYOUT_MULTI_OPTIX` for Optix, this patch adds a `BVH_LAYOUT_MULTI_METAL` to correctly redirect to the correct Metal BVH layout type. Reviewed By: brecht Differential Revision: https://developer.blender.org/D13561
2021-12-13 22:20:16 +00:00
case BVH_LAYOUT_MULTI_METAL:
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
case BVH_LAYOUT_MULTI_HIPRT:
Cycles: fix multi-device rendering with oneAPI and Hardware Raytracing Only Embree CPU BVH was built in the multi-device case. However, one Embree GPU BVH is needed per GPU, so we now reuse the same logic as in the other backends. Pull Request: https://projects.blender.org/blender/blender/pulls/107992
2023-05-16 21:26:19 +00:00
case BVH_LAYOUT_MULTI_EMBREEGPU:
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-10 13:18:25 +00:00
case BVH_LAYOUT_MULTI_OPTIX_EMBREE:
Cycles: MetalRT support (kernel side) This patch adds MetalRT support to Cycles kernel code. It is mostly additive in nature or confined to Metal-specific code, however there are a few areas where this interacts with other code: - MetalRT closely follows the Optix implementation, and in some cases (notably handling of transforms) it makes sense to extend Optix special-casing to MetalRT. For these generalisations we now have `__KERNEL_GPU_RAYTRACING__` instead of `__KERNEL_OPTIX__`. - MetalRT doesn't support primitive offsetting (as with `primitiveIndexOffset` in Optix), so we define and populate a new kernel texture, `__object_prim_offset`, containing per-object primitive / curve-segment offsets. This is referenced and applied in MetalRT intersection handlers. - Two new BVH layout enum values have been added: `BVH_LAYOUT_METAL` and `BVH_LAYOUT_MULTI_METAL_EMBREE` for XPU mode). Some host-side enum case handling has been updated where it is trivial to do so. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13353
2021-11-29 15:06:22 +00:00
case BVH_LAYOUT_MULTI_METAL_EMBREE:
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
case BVH_LAYOUT_MULTI_HIPRT_EMBREE:
Cycles: fix multi-device rendering with oneAPI and Hardware Raytracing Only Embree CPU BVH was built in the multi-device case. However, one Embree GPU BVH is needed per GPU, so we now reuse the same logic as in the other backends. Pull Request: https://projects.blender.org/blender/blender/pulls/107992
2023-05-16 21:26:19 +00:00
case BVH_LAYOUT_MULTI_EMBREEGPU_EMBREE:
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-10 13:18:25 +00:00
return "MULTI";
Cycles: Replace use_qbvh boolean flag with an enum-based property This was we can introduce other types of BVH, for example, wider ones, without causing too much mess around boolean flags. Thoughs: - Ideally device info should probably return bitflag of what BVH types it supports. It is possible to implement based on simple logic in device/ and mesh.cpp, rest of the changes will stay the same. - Not happy with workarounds in util_debug and duplicated enum in kernel. Maybe enbum should be stores in kernel, but then it's kind of weird to include kernel types from utils. Soudns some cyclkic dependency. Reviewers: brecht, maxim_d33 Reviewed By: brecht Differential Revision: https://developer.blender.org/D3011
2018-01-19 09:59:58 +00:00
case BVH_LAYOUT_ALL:
return "ALL";
}
LOG(DFATAL) << "Unsupported BVH layout was passed.";
return "";
}
BVHLayout BVHParams::best_bvh_layout(BVHLayout requested_layout, BVHLayoutMask supported_layouts)
{
const BVHLayoutMask requested_layout_mask = (BVHLayoutMask)requested_layout;
/* Check whether requested layout is supported, if so -- no need to do
* any extra computation.
*/
if (supported_layouts & requested_layout_mask) {
return requested_layout;
}
/* Some bit magic to get widest supported BVH layout. */
/* This is a mask of supported BVH layouts which are narrower than the
* requested one.
*/
Cycles: refactor of BVH building to prepare for Optix Ref D5363
2019-08-26 15:29:06 +00:00
BVHLayoutMask allowed_layouts_mask = (supported_layouts & (requested_layout_mask - 1));
/* If the requested layout is not supported, choose from the supported layouts instead. */
if (allowed_layouts_mask == 0) {
allowed_layouts_mask = supported_layouts;
}
Cycles: Replace use_qbvh boolean flag with an enum-based property This was we can introduce other types of BVH, for example, wider ones, without causing too much mess around boolean flags. Thoughs: - Ideally device info should probably return bitflag of what BVH types it supports. It is possible to implement based on simple logic in device/ and mesh.cpp, rest of the changes will stay the same. - Not happy with workarounds in util_debug and duplicated enum in kernel. Maybe enbum should be stores in kernel, but then it's kind of weird to include kernel types from utils. Soudns some cyclkic dependency. Reviewers: brecht, maxim_d33 Reviewed By: brecht Differential Revision: https://developer.blender.org/D3011
2018-01-19 09:59:58 +00:00
/* We get widest from allowed ones and convert mask to actual layout. */
Cycles: refactor intrinsic functions implementation * Add processor independent fallbacks * Use uint32_t and uint64_t types * Remove unused functions * Better comments and less indentation Ref D8237, T78710
2021-02-14 14:34:23 +00:00
const BVHLayoutMask widest_allowed_layout_mask = __bsr((uint32_t)allowed_layouts_mask);
Cycles: Fix optimal BVH selection.
2018-01-22 21:52:09 +00:00
return (BVHLayout)(1 << widest_allowed_layout_mask);
Cycles: Replace use_qbvh boolean flag with an enum-based property This was we can introduce other types of BVH, for example, wider ones, without causing too much mess around boolean flags. Thoughs: - Ideally device info should probably return bitflag of what BVH types it supports. It is possible to implement based on simple logic in device/ and mesh.cpp, rest of the changes will stay the same. - Not happy with workarounds in util_debug and duplicated enum in kernel. Maybe enbum should be stores in kernel, but then it's kind of weird to include kernel types from utils. Soudns some cyclkic dependency. Reviewers: brecht, maxim_d33 Reviewed By: brecht Differential Revision: https://developer.blender.org/D3011
2018-01-19 09:59:58 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* BVH */
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 11:04:19 +00:00
BVH::BVH(const BVHParams &params_,
const vector<Geometry *> &geometry_,
const vector<Object *> &objects_)
: params(params_), geometry(geometry_), objects(objects_)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
}
Cycles: refactor of BVH building to prepare for Optix Ref D5363
2019-08-26 15:29:06 +00:00
BVH *BVH::create(const BVHParams &params,
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 11:04:19 +00:00
const vector<Geometry *> &geometry,
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 12:47:34 +00:00
const vector<Object *> &objects,
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-10 13:18:25 +00:00
Device *device)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
Cycles: Replace use_qbvh boolean flag with an enum-based property This was we can introduce other types of BVH, for example, wider ones, without causing too much mess around boolean flags. Thoughs: - Ideally device info should probably return bitflag of what BVH types it supports. It is possible to implement based on simple logic in device/ and mesh.cpp, rest of the changes will stay the same. - Not happy with workarounds in util_debug and duplicated enum in kernel. Maybe enbum should be stores in kernel, but then it's kind of weird to include kernel types from utils. Soudns some cyclkic dependency. Reviewers: brecht, maxim_d33 Reviewed By: brecht Differential Revision: https://developer.blender.org/D3011
2018-01-19 09:59:58 +00:00
switch (params.bvh_layout) {
case BVH_LAYOUT_BVH2:
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 11:04:19 +00:00
return new BVH2(params, geometry, objects);
Cycles: Added Embree as BVH option for CPU renders. Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag. Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly. There, Embree is off by default too and must be enabled with the WITH_EMBREE flag. Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint. TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache). Differential Revision: https://developer.blender.org/D3682
2018-11-07 11:58:12 +00:00
case BVH_LAYOUT_EMBREE:
Cycles: fix multi-device rendering with oneAPI and Hardware Raytracing Only Embree CPU BVH was built in the multi-device case. However, one Embree GPU BVH is needed per GPU, so we now reuse the same logic as in the other backends. Pull Request: https://projects.blender.org/blender/blender/pulls/107992
2023-05-16 21:26:19 +00:00
case BVH_LAYOUT_EMBREEGPU:
Cycles: Added Embree as BVH option for CPU renders. Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag. Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly. There, Embree is off by default too and must be enabled with the WITH_EMBREE flag. Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint. TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache). Differential Revision: https://developer.blender.org/D3682
2018-11-07 11:58:12 +00:00
#ifdef WITH_EMBREE
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-10 13:18:25 +00:00
return new BVHEmbree(params, geometry, objects);
Cycles: refactor of BVH building to prepare for Optix Ref D5363
2019-08-26 15:29:06 +00:00
#else
break;
Cycles: add Optix device backend This uses hardware-accelerated raytracing on NVIDIA RTX graphics cards. It is still currently experimental. Most features are supported, but a few are still missing like baking, branched path tracing and using CPU memory. https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles#NVIDIA_RTX For building with Optix support, the Optix SDK must be installed. See here for build instructions: https://wiki.blender.org/wiki/Building_Blender/CUDA Differential Revision: https://developer.blender.org/D5363
2019-09-12 12:50:06 +00:00
#endif
case BVH_LAYOUT_OPTIX:
#ifdef WITH_OPTIX
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-10 13:18:25 +00:00
return new BVHOptiX(params, geometry, objects, device);
Cycles: add Optix device backend This uses hardware-accelerated raytracing on NVIDIA RTX graphics cards. It is still currently experimental. Most features are supported, but a few are still missing like baking, branched path tracing and using CPU memory. https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles#NVIDIA_RTX For building with Optix support, the Optix SDK must be installed. See here for build instructions: https://wiki.blender.org/wiki/Building_Blender/CUDA Differential Revision: https://developer.blender.org/D5363
2019-09-12 12:50:06 +00:00
#else
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-10 13:18:25 +00:00
(void)device;
Cycles: add Optix device backend This uses hardware-accelerated raytracing on NVIDIA RTX graphics cards. It is still currently experimental. Most features are supported, but a few are still missing like baking, branched path tracing and using CPU memory. https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles#NVIDIA_RTX For building with Optix support, the Optix SDK must be installed. See here for build instructions: https://wiki.blender.org/wiki/Building_Blender/CUDA Differential Revision: https://developer.blender.org/D5363
2019-09-12 12:50:06 +00:00
break;
Cycles: Metal host-side code This patch adds the Metal host-side code: - Add all core host-side Metal backend files (device_impl, queue, etc) - Add MetalRT BVH setup files - Integrate with Cycles device enumeration code - Revive `path_source_replace_includes` in util/path (required for MSL compilation) This patch also includes a couple of small kernel-side fixes: - Add an implementation of `lgammaf` for Metal [Nemes, Gergő (2010), "New asymptotic expansion for the Gamma function", Archiv der Mathematik](https://users.renyi.hu/~gergonemes/) - include "work_stealing.h" inside the Metal context class because it accesses state now Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13423
2021-12-07 15:11:35 +00:00
#endif
case BVH_LAYOUT_METAL:
#ifdef WITH_METAL
return bvh_metal_create(params, geometry, objects, device);
#else
(void)device;
break;
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
#endif
case BVH_LAYOUT_HIPRT:
#ifdef WITH_HIPRT
return new BVHHIPRT(params, geometry, objects, device);
#else
(void)device;
break;
Cycles: Added Embree as BVH option for CPU renders. Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag. Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly. There, Embree is off by default too and must be enabled with the WITH_EMBREE flag. Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint. TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache). Differential Revision: https://developer.blender.org/D3682
2018-11-07 11:58:12 +00:00
#endif
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-10 13:18:25 +00:00
case BVH_LAYOUT_MULTI_OPTIX:
Fix T94022: Both options GPU/CPU checked under preferences cause viewport render crash. (ARM/Metal) This fixes crash T94022 when selecting live viewport render with both GPU & CPU devices selected. It is caused by incorrect `KernelBVHLayout` assignment. Similar to `BVH_LAYOUT_MULTI_OPTIX` for Optix, this patch adds a `BVH_LAYOUT_MULTI_METAL` to correctly redirect to the correct Metal BVH layout type. Reviewed By: brecht Differential Revision: https://developer.blender.org/D13561
2021-12-13 22:20:16 +00:00
case BVH_LAYOUT_MULTI_METAL:
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
case BVH_LAYOUT_MULTI_HIPRT:
Cycles: fix multi-device rendering with oneAPI and Hardware Raytracing Only Embree CPU BVH was built in the multi-device case. However, one Embree GPU BVH is needed per GPU, so we now reuse the same logic as in the other backends. Pull Request: https://projects.blender.org/blender/blender/pulls/107992
2023-05-16 21:26:19 +00:00
case BVH_LAYOUT_MULTI_EMBREEGPU:
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-10 13:18:25 +00:00
case BVH_LAYOUT_MULTI_OPTIX_EMBREE:
Cycles: MetalRT support (kernel side) This patch adds MetalRT support to Cycles kernel code. It is mostly additive in nature or confined to Metal-specific code, however there are a few areas where this interacts with other code: - MetalRT closely follows the Optix implementation, and in some cases (notably handling of transforms) it makes sense to extend Optix special-casing to MetalRT. For these generalisations we now have `__KERNEL_GPU_RAYTRACING__` instead of `__KERNEL_OPTIX__`. - MetalRT doesn't support primitive offsetting (as with `primitiveIndexOffset` in Optix), so we define and populate a new kernel texture, `__object_prim_offset`, containing per-object primitive / curve-segment offsets. This is referenced and applied in MetalRT intersection handlers. - Two new BVH layout enum values have been added: `BVH_LAYOUT_METAL` and `BVH_LAYOUT_MULTI_METAL_EMBREE` for XPU mode). Some host-side enum case handling has been updated where it is trivial to do so. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13353
2021-11-29 15:06:22 +00:00
case BVH_LAYOUT_MULTI_METAL_EMBREE:
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 17:05:30 +00:00
case BVH_LAYOUT_MULTI_HIPRT_EMBREE:
Cycles: fix multi-device rendering with oneAPI and Hardware Raytracing Only Embree CPU BVH was built in the multi-device case. However, one Embree GPU BVH is needed per GPU, so we now reuse the same logic as in the other backends. Pull Request: https://projects.blender.org/blender/blender/pulls/107992
2023-05-16 21:26:19 +00:00
case BVH_LAYOUT_MULTI_EMBREEGPU_EMBREE:
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-10 13:18:25 +00:00
return new BVHMulti(params, geometry, objects);
Cycles: Replace use_qbvh boolean flag with an enum-based property This was we can introduce other types of BVH, for example, wider ones, without causing too much mess around boolean flags. Thoughs: - Ideally device info should probably return bitflag of what BVH types it supports. It is possible to implement based on simple logic in device/ and mesh.cpp, rest of the changes will stay the same. - Not happy with workarounds in util_debug and duplicated enum in kernel. Maybe enbum should be stores in kernel, but then it's kind of weird to include kernel types from utils. Soudns some cyclkic dependency. Reviewers: brecht, maxim_d33 Reviewed By: brecht Differential Revision: https://developer.blender.org/D3011
2018-01-19 09:59:58 +00:00
case BVH_LAYOUT_NONE:
case BVH_LAYOUT_ALL:
break;
}
LOG(DFATAL) << "Requested unsupported BVH layout.";
return NULL;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
CCL_NAMESPACE_END
Reference in New Issue Copy Permalink