Cycles: add RT HW support through Embree for oneAPI backend #106266

Closed
Xavier Hallade wants to merge 10 commits from xavierh/blender:cycles_embree4_gpu into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

I've tested it with Blender build system and it compiles fine on both Windows and Linux with existing dpcpp and ocloc dependencies (only exception: AoT on Linux requires compute-runtime 23.05.25593.18)
We'll certainly want to update them, but that's not immediately needed.

When attaching a debugger, you may see bad_alloc and page faults exceptions, these are by design and don't lead to crashes as they're handled by embree and level-zero runtimes to resp. build BVH while fitting in memory and migrating memory across GPU-CPU using Unified Shared Memory.

I've tested it with Blender build system and it compiles fine on both Windows and Linux with existing dpcpp and ocloc dependencies (only exception: AoT on Linux requires compute-runtime 23.05.25593.18) We'll certainly want to update them, but that's not immediately needed. When attaching a debugger, you may see bad_alloc and page faults exceptions, these are by design and don't lead to crashes as they're handled by embree and level-zero runtimes to resp. build BVH while fitting in memory and migrating memory across GPU-CPU using Unified Shared Memory.
Xavier Hallade added this to the 3.6 LTS milestone 2023-03-29 14:26:06 +02:00
Xavier Hallade added the
Module
Render & Cycles
label 2023-03-29 14:26:06 +02:00
Nikita Sirgienko was assigned by Xavier Hallade 2023-03-29 14:26:07 +02:00
Xavier Hallade self-assigned this 2023-03-29 14:26:07 +02:00

Is the BVH layout mask as a template parameter to many kernel functions needed? I can imagine that for debugging you may want to be able to test with BVH2, but given compile times and binary size, maybe a Blender build can have only BVH2 or Embree for oneAPI?

Is the BVH layout mask as a template parameter to many kernel functions needed? I can imagine that for debugging you may want to be able to test with BVH2, but given compile times and binary size, maybe a Blender build can have only BVH2 or Embree for oneAPI?
Author
Member

Yes.
Beyond debugging, there are cases for which intersection kernels still need to run without embree:

  • when raytrace and/or MNEE are used.
  • if user chooses it or if on hardware that doesn't support it.
    Luckily for compile time and size, the intersection kernels are the short/small ones.
Yes. Beyond debugging, there are cases for which intersection kernels still need to run without embree: - when raytrace and/or MNEE are used. - if user chooses it or if on hardware that doesn't support it. Luckily for compile time and size, the intersection kernels are the short/small ones.
Xavier Hallade force-pushed cycles_embree4_gpu from ddc02a8758 to b2fe4a03cc 2023-03-30 11:13:15 +02:00 Compare
Xavier Hallade force-pushed cycles_embree4_gpu from b2fe4a03cc to 685081230f 2023-03-30 13:10:13 +02:00 Compare

when raytrace and/or MNEE are used.

Why is this not working? Is there a plan or timeline for solving this?

if user chooses it or if on hardware that doesn't support it. Luckily for compile time and size, the intersection kernels are the short/small ones.

Don't we know if there is hardware support at compile time?

> when raytrace and/or MNEE are used. Why is this not working? Is there a plan or timeline for solving this? > if user chooses it or if on hardware that doesn't support it. Luckily for compile time and size, the intersection kernels are the short/small ones. Don't we know if there is hardware support at compile time?
Author
Member

The issues with embree+raytrace kernels and MNEE, we need to debug and get these fixed, so far it's hard to commit to a date.
If it worked reliably I agree we could avoid relying on templates, that's true hardware support can be known at compile time.

The issues with embree+raytrace kernels and MNEE, we need to debug and get these fixed, so far it's hard to commit to a date. If it worked reliably I agree we could avoid relying on templates, that's true hardware support can be known at compile time.
Xavier Hallade force-pushed cycles_embree4_gpu from 685081230f to 08189776d6 2023-03-30 17:23:03 +02:00 Compare
Xavier Hallade force-pushed cycles_embree4_gpu from f7c946afd4 to e306f58326 2023-03-31 18:15:12 +02:00 Compare
Brecht Van Lommel requested review from Brecht Van Lommel 2023-04-04 20:55:04 +02:00
Xavier Hallade force-pushed cycles_embree4_gpu from e306f58326 to 19a5361edb 2023-04-05 11:22:11 +02:00 Compare
Xavier Hallade added this to the Render & Cycles project 2023-04-05 12:19:31 +02:00
Xavier Hallade force-pushed cycles_embree4_gpu from 19a5361edb to ee8b65728d 2023-04-05 16:34:45 +02:00 Compare
Author
Member

@brecht I've split the work in smaller commits so it's easier to review.
We'll try to avoid the template parameter by using a specialization constant instead, that sounds doable.

@brecht I've split the work in smaller commits so it's easier to review. We'll try to avoid the template parameter by using a specialization constant instead, that sounds doable.
Xavier Hallade force-pushed cycles_embree4_gpu from ee8b65728d to b004ef9ec3 2023-04-05 23:21:09 +02:00 Compare
Xavier Hallade force-pushed cycles_embree4_gpu from 5036acf41c to b36060b92b 2023-04-06 18:12:35 +02:00 Compare
Xavier Hallade force-pushed cycles_embree4_gpu from b36060b92b to c9bc679552 2023-04-06 18:30:17 +02:00 Compare
Xavier Hallade force-pushed cycles_embree4_gpu from c9bc679552 to 8cc183a57c 2023-04-06 22:08:03 +02:00 Compare
Xavier Hallade force-pushed cycles_embree4_gpu from 8cc183a57c to 9ec8febdb2 2023-04-07 13:33:44 +02:00 Compare
Xavier Hallade changed title from WIP: Cycles: add RT HW support through Embree for oneAPI backend to Cycles: add RT HW support through Embree for oneAPI backend 2023-04-07 13:36:06 +02:00
Xavier Hallade requested review from Ray molenkamp 2023-04-07 17:49:10 +02:00
Xavier Hallade requested review from Sergey Sharybin 2023-04-07 17:49:18 +02:00
Xavier Hallade force-pushed cycles_embree4_gpu from a690344593 to 0c9038af74 2023-04-12 18:24:19 +02:00 Compare
Author
Member

In terms of library dependencies, with the latest version of the patchset which benefits from JIT-only compilation of the kernels using embree, AoT on Linux (and everything else) work fine even without the compute-runtime and dpcpp upgrades.
It still makes sense to upgrade all at once though so dpcpp is finally from a release that's not a nightly :) and compute-runtime let do AoT with Embree in case we need it back.

In terms of library dependencies, with the latest version of the patchset which benefits from JIT-only compilation of the kernels using embree, AoT on Linux (and everything else) work fine even without the compute-runtime and dpcpp upgrades. It still makes sense to upgrade all at once though so dpcpp is finally from a release that's not a nightly :) and compute-runtime let do AoT with Embree in case we need it back.
Member

has some limited time for testing tonight, this feels oddly familiar, think we may have fixed this in the combined diff at one point but dpcpp will try to use lld to link which isn't build currently. needs this fix to get embree past it's cmake configure phase.

diff --git a/build_files/build_environment/cmake/dpcpp.cmake b/build_files/build_environment/cmake/dpcpp.cmake
index d6ceeb948a0..272a360fc67 100644
--- a/build_files/build_environment/cmake/dpcpp.cmake
+++ b/build_files/build_environment/cmake/dpcpp.cmake
@@ -52,7 +52,7 @@ set(DPCPP_EXTRA_ARGS
   -DXPTI_SOURCE_DIR=${DPCPP_SOURCE_ROOT}/xpti
   -DLLVM_EXTERNAL_XPTIFW_SOURCE_DIR=${DPCPP_SOURCE_ROOT}/xptifw
   -DLLVM_EXTERNAL_LIBDEVICE_SOURCE_DIR=${DPCPP_SOURCE_ROOT}/libdevice
-  -DLLVM_ENABLE_PROJECTS=clang^^sycl^^llvm-spirv^^opencl^^libdevice^^xpti^^xptifw
+  -DLLVM_ENABLE_PROJECTS=clang^^sycl^^llvm-spirv^^opencl^^libdevice^^xpti^^xptifw^^lld
   -DLIBCLC_TARGETS_TO_BUILD=
   -DLIBCLC_GENERATE_REMANGLED_VARIANTS=OFF
   -DSYCL_BUILD_PI_HIP_PLATFORM=AMD
has some limited time for testing tonight, this feels oddly familiar, think we may have fixed this in the combined diff at one point but dpcpp will try to use lld to link which isn't build currently. needs this fix to get embree past it's cmake configure phase. ``` diff --git a/build_files/build_environment/cmake/dpcpp.cmake b/build_files/build_environment/cmake/dpcpp.cmake index d6ceeb948a0..272a360fc67 100644 --- a/build_files/build_environment/cmake/dpcpp.cmake +++ b/build_files/build_environment/cmake/dpcpp.cmake @@ -52,7 +52,7 @@ set(DPCPP_EXTRA_ARGS -DXPTI_SOURCE_DIR=${DPCPP_SOURCE_ROOT}/xpti -DLLVM_EXTERNAL_XPTIFW_SOURCE_DIR=${DPCPP_SOURCE_ROOT}/xptifw -DLLVM_EXTERNAL_LIBDEVICE_SOURCE_DIR=${DPCPP_SOURCE_ROOT}/libdevice - -DLLVM_ENABLE_PROJECTS=clang^^sycl^^llvm-spirv^^opencl^^libdevice^^xpti^^xptifw + -DLLVM_ENABLE_PROJECTS=clang^^sycl^^llvm-spirv^^opencl^^libdevice^^xpti^^xptifw^^lld -DLIBCLC_TARGETS_TO_BUILD= -DLIBCLC_GENERATE_REMANGLED_VARIANTS=OFF -DSYCL_BUILD_PI_HIP_PLATFORM=AMD ```
Author
Member

@LazyDodo it's in the "Cycles: build Embree 4 with GPU support" commit already, did you nuke dpcpp build cache?

@LazyDodo it's in the "Cycles: build Embree 4 with GPU support" commit already, did you nuke dpcpp build cache?
Xavier Hallade force-pushed cycles_embree4_gpu from 0c9038af74 to 31b38c963e 2023-04-14 08:53:42 +02:00 Compare
Member

@LazyDodo it's in the "Cycles: build Embree 4 with GPU support" commit already

LLVM_EXTERNAL_PROJECTS is, LLVM_ENABLE_PROJECTS isn't.

> @LazyDodo it's in the "Cycles: build Embree 4 with GPU support" commit already `LLVM_EXTERNAL_PROJECTS` is, `LLVM_ENABLE_PROJECTS` isn't.
Xavier Hallade force-pushed cycles_embree4_gpu from 31b38c963e to 8831fa967d 2023-04-14 15:02:28 +02:00 Compare
Author
Member

you're correct, my bad, I've added this one as well now in 61cebb06c6

you're correct, my bad, I've added this one as well now in https://projects.blender.org/blender/blender/commit/61cebb06c6c2a517b100fb1ca469c7b8161e14b5
Author
Member

@blender-bot build
(with current svn libs, so embree 3 and no HW support)

@blender-bot build (with current svn libs, so embree 3 and no HW support)
Member

The dpcpp folder has ballooned from 200M to 529M on windows, which seems a bit much, I'll take a look at this my self, just wanted it documented. Needs to be investigated before landing.

The dpcpp folder has ballooned from 200M to 529M on windows, which seems a bit much, I'll take a look at this my self, just wanted it documented. Needs to be investigated before landing.
Sergey Sharybin reviewed 2023-04-17 15:26:58 +02:00
@ -24,0 +43,4 @@
# define IF_NOT_USING_EMBREE
#endif
#define __BVH2__

We should not define __BVH2__ for OptiX and MetalRT (currently seems it is defined for all types of devices).

We should not define `__BVH2__` for OptiX and MetalRT (currently seems it is defined for all types of devices).

@xavierh, I as I see there is a BVH2 definion above:

#if defined(__EMBREE__)
#  include "kernel/device/cpu/bvh.h"
#  define __BVH2__
#elif defined(__METALRT__)
#  include "kernel/device/metal/bvh.h"
#elif defined(__KERNEL_OPTIX__)
#  include "kernel/device/optix/bvh.h"
#else
#  define __BVH2__
#endif

So do we really need __BVH2__ redefined again?

@xavierh, I as I see there is a __BVH2__ definion above: ```` #if defined(__EMBREE__) # include "kernel/device/cpu/bvh.h" # define __BVH2__ #elif defined(__METALRT__) # include "kernel/device/metal/bvh.h" #elif defined(__KERNEL_OPTIX__) # include "kernel/device/optix/bvh.h" #else # define __BVH2__ #endif ```` So do we really need `__BVH2__` redefined again?
Author
Member

good catch - that redefinition was definitely a mistake and it had no purpose, I've removed it.

good catch - that redefinition was definitely a mistake and it had no purpose, I've removed it.
xavierh marked this conversation as resolved
Xavier Hallade added 1 commit 2023-04-17 16:10:54 +02:00
Brecht Van Lommel requested changes 2023-04-17 19:31:40 +02:00
Brecht Van Lommel left a comment
Owner

Some of the code kernel code gets messy, but I don't have simple suggestions to improve it. Probably best to try refactoring things afterwards, and keep the changes in this PR more limited.

Some of the code kernel code gets messy, but I don't have simple suggestions to improve it. Probably best to try refactoring things afterwards, and keep the changes in this PR more limited.
@ -281,6 +281,9 @@ endif()
if(WITH_CYCLES_EMBREE)
add_definitions(-DWITH_EMBREE)
if(EMBREE_SYCL_SUPPORT)

if(WITH_CYCLES_DEVICE_ONEAPI AND EMBREE_SYCL_SUPPORT)

`if(WITH_CYCLES_DEVICE_ONEAPI AND EMBREE_SYCL_SUPPORT)`
@ -1545,2 +1545,4 @@
)
use_oneapirt: BoolProperty(
name="Embree on GPU (Experimental)",

Users don't need to know what Embree is. Can you juse name this "Hardware Ray Tracing"?

Users don't need to know what Embree is. Can you juse name this "Hardware Ray Tracing"?
@ -1546,1 +1546,4 @@
use_oneapirt: BoolProperty(
name="Embree on GPU (Experimental)",
description="Embree GPU execution will allow to use HW RT for ray tracing on Intel GPUs, which will provide better performance. However this support is experimental and some scenes may render incorrectly",

HW RT for ray tracing -> hardware ray tracing

However this support is experimental and some scenes may render incorrectly

Is this true? If it's experimental it should not be enabled by default.

HW RT for ray tracing -> hardware ray tracing > However this support is experimental and some scenes may render incorrectly Is this true? If it's experimental it should not be enabled by default.
Author
Member

It's close to not being experimental anymore, we can keep it off and switch it on during bcon2.

It's close to not being experimental anymore, we can keep it off and switch it on during bcon2.
@ -101,2 +101,3 @@
rtc_device(NULL),
build_quality(RTC_BUILD_QUALITY_REFIT)
build_quality(RTC_BUILD_QUALITY_REFIT),
is_curve_support_required(false)

Can KERNEL_FEATURE_HAIR be used instead of adding this? It's what OptiX and Metal use.

Can `KERNEL_FEATURE_HAIR` be used instead of adding this? It's what OptiX and Metal use.
@ -80,3 +80,3 @@
bool has_peer_memory; /* GPU has P2P access to memory of another GPU. */
bool has_gpu_queue; /* Device supports GPU queue. */
bool use_metalrt; /* Use MetalRT to accelerate ray queries (Metal only). */
bool use_hwrt; /* Use hardware ray tracing to accelerate ray queries in a backend. */

use_hardware_raytracing to avoid obscure abbreviation.

`use_hardware_raytracing` to avoid obscure abbreviation.
@ -112,6 +113,12 @@ static void device_iterator_cb(const char *id, const char *name, int num, void *
/* NOTE(@nsirgien): Seems not possible to know from SYCL/oneAPI or Level0. */
info.display_device = false;
# if WITH_EMBREE && WITH_EMBREE_GPU

#ifdef WITH_EMBREE_GPU is enough

`#ifdef WITH_EMBREE_GPU` is enough
@ -34,1 +44,3 @@
bool is_finished_ok = create_queue(device_queue_, info.num);
if (use_hwrt)
VLOG_INFO
<< "oneAPI will try to use Hardware Raytracing capabilities for intersection acceleration";

Hardware Raytracing -> hardware ray tracing

Hardware Raytracing -> hardware ray tracing
@ -35,0 +55,4 @@
# ifdef WITH_EMBREE_GPU
use_hwrt = use_hwrt && (embree_device != nullptr);
# else
use_hwrt = false;

Can you move this before oneAPI will try to use Hardware Raytracing capabilities for intersection acceleration? So we can definitely say if it is used or not.

Can you move this before `oneAPI will try to use Hardware Raytracing capabilities for intersection acceleration`? So we can definitely say if it is used or not.
Author
Member

done, I've moved the string to after this block since it also checks for embree_device init.

done, I've moved the string to after this block since it also checks for embree_device init.
xavierh marked this conversation as resolved
@ -84,2 +115,3 @@
{
return BVH_LAYOUT_BVH2;
/* MNEE and Raytrace kernels currently don't work correctly with HWRT. */
if ((kernel_features & KERNEL_FEATURE_MNEE || kernel_features & KERNEL_FEATURE_NODE_RAYTRACE)) {

Simpler:

return !(kernel_features & (KERNEL_FEATURE_MNEE | KERNEL_FEATURE_NODE_RAYTRACE));
Simpler: ``` return !(kernel_features & (KERNEL_FEATURE_MNEE | KERNEL_FEATURE_NODE_RAYTRACE)); ```
@ -88,0 +141,4 @@
if (bvh->params.top_level) {
embree_scene = bvh_embree->scene;
}
/* NOTE(sirgienko) We need to have an accumulative logic here, because Embree supports

This should no longer be needed if KERNEL_FEATURE_HAIR is used.

This should no longer be needed if `KERNEL_FEATURE_HAIR` is used.
xavierh marked this conversation as resolved
@ -103,1 +170,3 @@
is_finished_ok = oneapi_load_kernels(device_queue_, (const unsigned int)requested_features);
if (use_hwrt && !can_use_hwrt_for_features(requested_features)) {
VLOG_INFO << "Requested features don't work properly together with Hardware Raytracing yet "
"in oneAPI backend. Hardware Raytracing is now disabled.";

Hardware ray tracing disabled, not supported yet by oneAPI for requested features

> Hardware ray tracing disabled, not supported yet by oneAPI for requested features
@ -450,0 +534,4 @@
/* These declarations are missing from embree headers when compiling from a compiler that doesn't
* support SYCL. */
extern "C" RTCDevice rtcNewSYCLDevice(sycl::context context, const char *config);
extern "C" bool rtcIsSYCLDeviceSupported(const sycl::device sycl_device);

Can you move this to the top of the file, outside the namespace also? So the function declarations are not mixed with other code.

Can you move this to the top of the file, outside the namespace also? So the function declarations are not mixed with other code.
@ -24,0 +36,4 @@
if (kernel_handler.get_specialization_constant<oneapi_embree_features>() != \
RTC_FEATURE_FLAG_NONE)
# define IF_NOT_USING_EMBREE \
if (kernel_handler.get_specialization_constant<oneapi_embree_features>() == \

Maybe use if constexpr here to be really sure?

Maybe use `if constexpr` here to be really sure?
Author
Member

the host compiler at least cannot consider it constexpr.

the host compiler at least cannot consider it constexpr.
xavierh marked this conversation as resolved
@ -8,0 +11,4 @@
# define __KERNEL_GPU_RAYTRACING__
#endif
#ifndef RTC_SYCL_KERNEL

What is this for, it doesn't seem to be used by our own code? If it's needed, can you add a comment explaining what this is?

What is this for, it doesn't seem to be used by our own code? If it's needed, can you add a comment explaining what this is?
Author
Member

it was at some point in Embree but it's gone, I'll remove it.

it was at some point in Embree but it's gone, I'll remove it.
@ -146,0 +164,4 @@
return false;
if ((requested_features & KERNEL_FEATURE_VOLUME) == 0 &&
kernel_name.find("oneapi_kernel_integrator_intersect_volume_stack") != std::string::npos)
return false;

Can you use kernel_name.find(device_kernel_as_string(DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_RAYTRACE)) and similar instead?

Can you use `kernel_name.find(device_kernel_as_string(DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_RAYTRACE))` and similar instead?
@ -146,0 +178,4 @@
if (kernel_name.find("oneapi_kernel_integrator_shade_surface_raytrace") != std::string::npos)
return false;
if (kernel_name.find("oneapi_kernel_integrator_shade_surface_mnee") != std::string::npos)
return false;

Can make this more generic:

for (int i = 0; i < (int)DEVICE_KERNEL_NUM; i++) {
  DeviceKernel kernel = (DeviceKernel)i;
  if (device_kernel_has_intersection(kernel)) {
    if (kernel_name.find(device_kernel_as_string(kernel)) != std::string::npos) {
      return !(kernel == DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_RAYTRACE ||
                         DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_MNEE);
    }
  }
}
Can make this more generic: ``` for (int i = 0; i < (int)DEVICE_KERNEL_NUM; i++) { DeviceKernel kernel = (DeviceKernel)i; if (device_kernel_has_intersection(kernel)) { if (kernel_name.find(device_kernel_as_string(kernel)) != std::string::npos) { return !(kernel == DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_RAYTRACE || DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_MNEE); } } } ```
@ -146,0 +183,4 @@
return false;
}
bool oneapi_kernel_does_rt(::DeviceKernel device_kernel)

Replace by device_kernel_has_intersection which does the same thing.

Replace by `device_kernel_has_intersection` which does the same thing.
Xavier Hallade added 2 commits 2023-04-18 08:36:01 +02:00
Xavier Hallade requested review from Brecht Van Lommel 2023-04-18 08:37:08 +02:00
Xavier Hallade reviewed 2023-04-18 08:41:57 +02:00
Xavier Hallade left a comment
Author
Member

Thanks for the review brecht, I've addressed all your points in d11a69fa2f

edit: nothing happens when I click on "resolve conversation"

Thanks for the review brecht, I've addressed all your points in https://projects.blender.org/blender/blender/commit/d11a69fa2f2a3bc1e3d966194eddc15abffcaf47 edit: nothing happens when I click on "resolve conversation"
Xavier Hallade added 1 commit 2023-04-18 09:48:32 +02:00
buildbot/vexp-code-patch-coordinator Build done. Details
05ab80175b
Cycles: address env var deprecation after dpcpp upgrade to 2022-12
ONEAPI_DEVICE_SELECTOR environment variable should be used instead of
SYCL_DEVICE_FILTER.
Brecht Van Lommel approved these changes 2023-04-18 15:58:23 +02:00
Brecht Van Lommel left a comment
Owner

Ok from my side assuming the build passes.

But wait until at least @LazyDodo approves since he was still looking into the libs file size.

Ok from my side assuming the build passes. But wait until at least @LazyDodo approves since he was still looking into the libs file size.

I did also notice resolve conversation does not work, will figure out where this broke in Gitea.

I did also notice resolve conversation does not work, will figure out where this broke in Gitea.
Ray molenkamp approved these changes 2023-04-18 18:57:22 +02:00
Ray molenkamp left a comment
Member

I looked into the libs, lld is being harvested while it's not needed and has like 6 copies each at 40M+, I can fix this during the building of the final libs, shouldn't prevent this diff from landing in it's current state.

I looked into the libs, lld is being harvested while it's not needed and has like 6 copies each at 40M+, I can fix this during the building of the final libs, shouldn't prevent this diff from landing in it's current state.

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR106266) when ready.
Author
Member

Thanks Brecht, Ray.
I've just landed it in a few separate commits:

  • 66b4e426cc : Cycles: build Embree 4 with GPU support
  • 5cdf0c9ee9 : Cycles: update compute-runtime to 23.05.25593.18
  • 887022257d : Cycles: update DPCPP to 2022-12 release
  • 3f8c995109 : Cycles: add hardware raytracing support to oneAPI device
  • 9821a2d397 : Cycles: pass kernel features to get_bvh_layout_mask
  • 70892e82ac : Cycles: oneAPI: use specialization constant to compile with/without Embree on GPU
Thanks Brecht, Ray. I've just landed it in a few separate commits: - 66b4e426cc : Cycles: build Embree 4 with GPU support - 5cdf0c9ee9 : Cycles: update compute-runtime to 23.05.25593.18 - 887022257d : Cycles: update DPCPP to 2022-12 release - 3f8c995109 : Cycles: add hardware raytracing support to oneAPI device - 9821a2d397 : Cycles: pass kernel features to get_bvh_layout_mask - 70892e82ac : Cycles: oneAPI: use specialization constant to compile with/without Embree on GPU
Xavier Hallade closed this pull request 2023-04-18 22:15:41 +02:00

This is not mentioned in the release notes yet. Can you edit them, or provide some text to put there?
https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles

This is not mentioned in the release notes yet. Can you edit them, or provide some text to put there? https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles
Author
Member

done! Thanks for the reminder.
Also a quick update: we can upgrade Embree to their next minor release that should be available between now and a couple of days. That will allow us to drop all the workarounds/patches including those we currently have for raytrace/MNEE kernels. These kernels will be able to use hardware raytracing too.

edit: Embree 4.1 release is available, I've opened the PR here: #107853

done! Thanks for the reminder. Also a quick update: we can upgrade Embree to their next minor release that should be available between now and a couple of days. That will allow us to drop all the workarounds/patches including those we currently have for raytrace/MNEE kernels. These kernels will be able to use hardware raytracing too. edit: Embree 4.1 release is available, I've opened the PR here: https://projects.blender.org/blender/blender/pulls/107853
Brecht Van Lommel removed this from the Render & Cycles project 2023-05-24 19:05:21 +02:00
All checks were successful
buildbot/vexp-code-patch-coordinator Build done.

Pull request closed

Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#106266
No description provided.