Cycles: Update Acceleration Structure UI Visibility #113077

Open
Alaska wants to merge 8 commits from Alaska/blender:fix-incorrect-bvh-settings into blender-v4.0-release

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

Update the visibility of the Acceleration Structure (AS) UI so the UI
better aligns with the options you can actually adjust.

Here's what changed:

  • All AS options are now hidden when using OptiX, HIPRT and MetalRT.
  • Embree options are shown instead of BVH2 options when using
    Embree GPU.
  • BVH2 options are now shown when using BVH2 on the CPU with
    debug settings.
  • BVH2 options are now shown when using CPU + GPU and Cycles
    is built without Embree.
  • Warnings about not using Embree on the CPU have been updated
    and now show up whenever BVH2 will be used on the CPU when it
    could be using Embree.

As a side effect of some of the refactoring done, other settings will
now show up when they should (E.G. OSL and Path Guiding settings will
now show up if you've selected GPU Compute as your device, but only
selected your CPU in the user preferences)

Update the visibility of the Acceleration Structure (AS) UI so the UI better aligns with the options you can actually adjust. Here's what changed: - All AS options are now hidden when using OptiX, HIPRT and MetalRT. - Embree options are shown instead of BVH2 options when using Embree GPU. - BVH2 options are now shown when using BVH2 on the CPU with debug settings. - BVH2 options are now shown when using CPU + GPU and Cycles is built without Embree. - Warnings about not using Embree on the CPU have been updated and now show up whenever BVH2 will be used on the CPU when it could be using Embree. As a side effect of some of the refactoring done, other settings will now show up when they should (E.G. OSL and Path Guiding settings will now show up if you've selected GPU Compute as your device, but only selected your CPU in the user preferences)
Alaska added the
Module
Render & Cycles
label 2023-09-30 09:29:07 +02:00
Alaska added 1 commit 2023-09-30 09:29:21 +02:00
Alaska requested review from Brecht Van Lommel 2023-09-30 09:29:47 +02:00
Alaska requested review from Sergey Sharybin 2023-09-30 09:29:54 +02:00
Alaska added 1 commit 2023-09-30 10:24:45 +02:00
Author
Member

This pull request should probably be backported to 3.6, and a modified version should be backported to 3.3 (3.3 lacks HIPRT and oneAPI Embree).

There are a few assumptions I make with this pull request:

  1. Embree Acceleration Structure options impact Embree GPU (I couldn't find anything that suggests otherwise, but I might be looking in the wrong place)
  2. Cycles can't be compiled with Embree GPU but without Embree CPU.
  3. When using a custom BVH + CPU when building Cycles without Embree, BVH2 will be used on the CPU (E.G. OptiX BHV on the GPU and BVH2 on the CPU). However this doesn't appear to be properly supported: #113081

I'm unsure what happens when a computer has multiple active GPUs of which only some are "Hardware RT" compatible.
For example, a computer with an RX 5700XT and RX 6700XT enabled. Only one of them supports HIPRT. Based on my understanding, this will trigger the use_hiprt section of the code below, resulting in the acceleration structure settings not being visible, even though some of settings are still useful for the RX 5700XT using BVH2 (Assuming the RX 5700XT even uses BVH2). Please correct me if I'm wrong.

def poll(cls, context):
   # GPU backend isn't using BVH2 or Embree
   gpu_uses_custom = use_optix(context) or use_hiprt(context) or use_metalrt(context)
   return use_multi_device(context) or not gpu_uses_custom
This pull request should probably be backported to 3.6, and a modified version should be backported to 3.3 (3.3 lacks HIPRT and oneAPI Embree). There are a few assumptions I make with this pull request: 1. Embree Acceleration Structure options impact Embree GPU (I couldn't find anything that suggests otherwise, but I might be looking in the wrong place) 2. Cycles can't be compiled with Embree GPU but without Embree CPU. 3. When using a custom BVH + CPU when building Cycles without Embree, BVH2 will be used on the CPU (E.G. OptiX BHV on the GPU and BVH2 on the CPU). However this doesn't appear to be properly supported: #113081 --- I'm unsure what happens when a computer has multiple active GPUs of which only some are "Hardware RT" compatible. For example, a computer with an RX 5700XT and RX 6700XT enabled. Only one of them supports HIPRT. Based on my understanding, this will trigger the `use_hiprt` section of the code below, resulting in the acceleration structure settings not being visible, even though some of settings are still useful for the RX 5700XT using BVH2 (Assuming the RX 5700XT even uses BVH2). Please correct me if I'm wrong. ``` def poll(cls, context): # GPU backend isn't using BVH2 or Embree gpu_uses_custom = use_optix(context) or use_hiprt(context) or use_metalrt(context) return use_multi_device(context) or not gpu_uses_custom ```
Alaska reviewed 2023-09-30 11:32:50 +02:00
Alaska added 1 commit 2023-09-30 11:45:28 +02:00
Alaska added 1 commit 2023-09-30 13:03:28 +02:00
Alaska added 1 commit 2023-09-30 16:09:39 +02:00
Alaska added 1 commit 2023-09-30 16:49:34 +02:00
Alaska added 1 commit 2023-10-01 14:27:37 +02:00
Too many things changed to properly describe what happened here.
Alaska reviewed 2023-10-01 14:58:03 +02:00

In the scenario you've described I don't think rendering will happen at all. The HWRT HIP capable device will report BVH_LAYOUT_HIPRT and the non-HWRT will report BVH_LAYOUT_BVH2. If my calculation is correct, the MultilDevice::get_bvh_layout_mask will return 0 in this case, which I don't think is ever supposed to happen. When I was working on the code there must have been at least one common BVH layout to fall-back to. So, Cycles will just crash?

In the scenario you've described I don't think rendering will happen at all. The HWRT HIP capable device will report `BVH_LAYOUT_HIPRT` and the non-HWRT will report `BVH_LAYOUT_BVH2`. If my calculation is correct, the `MultilDevice::get_bvh_layout_mask` will return 0 in this case, which I don't think is ever supposed to happen. When I was working on the code there must have been at least one common BVH layout to fall-back to. So, Cycles will just crash?
Alaska added 1 commit 2023-10-02 12:29:05 +02:00
The code comment was about how we didn't need to do a simple AND test.
But it's clearer to do the AND test, and performance shouldn't be a concern
Author
Member

I just wanted to update you on some information I found. Apparently HIP RT runs on all HIP supported devices in Cycles (Vega - RDNA3). So there's no concerns about a HIP RT + BHV2 combination on the AMD side. It's just that on older devices, standard compute is used to traverse the HIP RT BVH. Although there are bug reports for Blender that suggests HIP RT isn't supported on older devices (E.G. RX 5700XT in #108115).

HIP can run on Nvidia GPUs and AMD claims HIP RT runs on Nvidia GPUs, yet omits Nvidia from the list of supported devices https://gpuopen.com/hiprt/. So there may be the possibility for a HIPRT + BVH2 option there. But using HIP to offer Nvidia GPU support is not officially supported by the Blender foundation so I don't believe we should concern ourselves with that.

OneAPI can also be used for multiple vendors (E.G. Nvidia + AMD + Intel GPUs). And there are some Intel GPUs that don't have RT Cores. Based on what I could find online, it's very similar to the HIPRT situation. Some sources claim that Embree GPU runs on all GPUs that support SYCL through the various compilers, but hardware acceleration is only on Intel. While other sources only mention it working on Intel GPUs. Once again, I don't believe the Blender foundation supports oneAPI Intel devices that don't have ray tracing cores. Nor do they support building Cycles with Nvidia and AMD support through oneAPI. So we probably don't need to worry about it.

If all that is true, then the only case we do need to worry about is the GPU with custom BVH and CPU using BVH2 (which occurs when building Blender without Embree). I have already covered this case in ui.py, but this combination isn't actually supported for rendering, causing crashes or missing scenes.

I just wanted to update you on some information I found. Apparently HIP RT runs on all HIP supported devices in Cycles (Vega - RDNA3). So there's no concerns about a HIP RT + BHV2 combination on the AMD side. It's just that on older devices, standard compute is used to traverse the HIP RT BVH. Although there are bug reports for Blender that suggests HIP RT isn't supported on older devices (E.G. RX 5700XT in #108115). HIP can run on Nvidia GPUs and AMD claims HIP RT runs on Nvidia GPUs, yet omits Nvidia from the list of supported devices https://gpuopen.com/hiprt/. So there may be the possibility for a HIPRT + BVH2 option there. But using HIP to offer Nvidia GPU support is not officially supported by the Blender foundation so I don't believe we should concern ourselves with that. OneAPI can also be used for multiple vendors (E.G. Nvidia + AMD + Intel GPUs). And there are some Intel GPUs that don't have RT Cores. Based on what I could find online, it's very similar to the HIPRT situation. Some sources claim that Embree GPU runs on all GPUs that support SYCL through the various compilers, but hardware acceleration is only on Intel. While other sources only mention it working on Intel GPUs. Once again, I don't believe the Blender foundation supports oneAPI Intel devices that don't have ray tracing cores. Nor do they support building Cycles with Nvidia and AMD support through oneAPI. So we probably don't need to worry about it. If all that is true, then the only case we do need to worry about is the GPU with custom BVH and CPU using BVH2 (which occurs when building Blender without Embree). I have already covered this case in `ui.py`, but this combination isn't actually supported for rendering, causing crashes or missing scenes.
Author
Member

Pinging to get this reviewed before 4.0 releases.

I'm primarily interested in seeing if this should be merged into 4.0, or delayed to 4.1.

The reason I bring up delaying to 4.1 is that there are quite a few assumptions and unknowns due to my lack programming knowledge or lack of access to specific hardware configurations, that could make this commit provide "wrong" information in some situations. Examples of these include:

  1. I assume Embree GPU supports all the same Acceleration Structure build options as Embree CPU. I'm not 100% sure if it does.
  2. I don't know what BVH is used by some devices (E.G. What BVH does the RX 5700XT use when you have both a RX 5700XT and 7700XT in your computer, with HIPRT enabled. The RX 5700XT doesn't have ray accelerators, so I'm not sure if it uses the HIPRT BVH or BVH2)
  3. Similar things to the AMD HIPRT situation, but with Nvidia with OptiX (E.G. Combing GTX with RTX GPUs), Intel with oneAPI, and the various GPU configurations you can have on macOS with Metal (E.G. RX 570 inside a Mac, but a RX 6800XT in a external GPU enclosure. The RX 6800XT supports Metal RT while the RX 570 doesn't).
  4. Other things?

Note: If this is to be delayed to 4.1, then I will make pull requests for some changes I made in this one that will be useful else where (E.G. Show CPU only settings when "GPU Compute" is selected, but the only enabled "GPU" is a CPU)

Pinging to get this reviewed before 4.0 releases. I'm primarily interested in seeing if this should be merged into 4.0, or delayed to 4.1. The reason I bring up delaying to 4.1 is that there are quite a few assumptions and unknowns due to my lack programming knowledge or lack of access to specific hardware configurations, that could make this commit provide "wrong" information in some situations. Examples of these include: 1. I assume Embree GPU supports all the same Acceleration Structure build options as Embree CPU. I'm not 100% sure if it does. 2. I don't know what BVH is used by some devices (E.G. What BVH does the RX 5700XT use when you have both a RX 5700XT and 7700XT in your computer, with HIPRT enabled. The RX 5700XT doesn't have ray accelerators, so I'm not sure if it uses the HIPRT BVH or BVH2) 3. Similar things to the AMD HIPRT situation, but with Nvidia with OptiX (E.G. Combing GTX with RTX GPUs), Intel with oneAPI, and the various GPU configurations you can have on macOS with Metal (E.G. RX 570 inside a Mac, but a RX 6800XT in a external GPU enclosure. The RX 6800XT supports Metal RT while the RX 570 doesn't). 4. Other things? Note: If this is to be delayed to 4.1, then I will make pull requests for some changes I made in this one that will be useful else where (E.G. Show CPU only settings when "GPU Compute" is selected, but the only enabled "GPU" is a CPU)
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u fix-incorrect-bvh-settings:Alaska-fix-incorrect-bvh-settings
git checkout Alaska-fix-incorrect-bvh-settings
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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
No Assignees
2 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#113077
No description provided.