Cycles render test: Failing oneAPI tests #125088

New Issue

Alaska · 2024-07-19T17:13:16+02:00

Alaska commented

2024-07-19 17:13:16 +02:00

System Information
Operating system: Windows-10-10.0.22631-SP0 64 Bits
Graphics card: Intel(R) Arc(TM) A750 Graphics Intel 4.6.0 - Build 32.0.101.5762
Blender version: 4.3.0 Alpha, branch: main, commit date: 2024-07-17 23:28, hash: 0b70a9edc56b

Short description of error
Blender has a collection of render tests that can be used to test for breaking changes. On the Cycles side this can also be used to verify that GPU render results generally align with the CPU.

I have noticed that a few tests are failing when running the render tests with oneAPI, one specific to Embree GPU, and the Cycles team would like these issues to be fixed when possible.

This task is to catalog failing render tests for developers to use as reference when fixing the issues.

Exact steps for others to reproduce the error

Build Blender locally with GPU support
In the CYCLES_TEST_DEVICE parameter in the cmake file for Blender, change it to ONEAPI-RT
Run Blenders tests. This can generally be done with make test from the Blender source code folder, but more information can be found here
The automated tests will report that some tests are failing, and direct you to a local web page to review them.

Note: After running make test at least once, you can switch to running ctest -R cycles -C release inside the Blender build folder (E.g. /blender-git/build_windows) to only run Cycles test for faster iterations.

Note: All file paths are provided relative to the render tests folder.
Locally this folder can be found at blender_repo_folder/tests/data/render/. This folder can also be found online in the render folder of the blender/blender-test-data repo.

List of failing tests:

Noise differences
- The tests listed here have differences in noise compared to the CPU render. Nothing appears obviously broken, and so fixing these are not high priority. These issues occur with Embree GPU on and off.
  - /light/all_light_types
  - /light_linking/light_link_distant_multi_tree
  - /light_linking/light_link_distant_tree
  - /light_linking/light_link_surface_in_volume
Incorrect rendering
- One test is rendering incorrectly when Embree GPU is enabled. Shadows of some semi-transparent objects show artifacts, making the shadow brighter or darker when compared to the CPU. A simplifed file that reproduces the issue can be found in #125093. Just open the file and decrease the transparent bounces to 1023 or lower.
  - /light_linking/shadow_link_transparency - Fixed by (d4ceade5ea)

**System Information** Operating system: Windows-10-10.0.22631-SP0 64 Bits Graphics card: Intel(R) Arc(TM) A750 Graphics Intel 4.6.0 - Build 32.0.101.5762 Blender version: 4.3.0 Alpha, branch: main, commit date: 2024-07-17 23:28, hash: `0b70a9edc56b` **Short description of error** Blender has a collection of render tests that can be used to test for breaking changes. On the Cycles side this can also be used to verify that GPU render results generally align with the CPU. I have noticed that a few tests are failing when running the render tests with oneAPI, one specific to Embree GPU, and the Cycles team would like these issues to be fixed when possible. This task is to catalog failing render tests for developers to use as reference when fixing the issues. **Exact steps for others to reproduce the error** 1. Build [Blender locally](https://developer.blender.org/docs/handbook/building_blender/) with [GPU support](https://developer.blender.org/docs/handbook/building_blender/cycles_gpu_binaries/) 2. In the `CYCLES_TEST_DEVICE` parameter in the cmake file for Blender, change it to `ONEAPI-RT` 3. Run Blenders tests. This can generally be done with `make test` from the Blender source code folder, but more information can be found [here](https://developer.blender.org/docs/handbook/testing/setup/) 4. The automated tests will report that some tests are failing, and direct you to a local web page to review them. Note: After running `make test` at least once, you can switch to running `ctest -R cycles -C release` inside the Blender build folder (E.g. `/blender-git/build_windows`) to only run Cycles test for faster iterations. --- Note: All file paths are provided relative to the render tests folder. Locally this folder can be found at `blender_repo_folder/tests/data/render/`. This folder can also be found online in the `render` folder of the [blender/blender-test-data](https://projects.blender.org/blender/blender-test-data) repo. List of failing tests: - Noise differences - The tests listed here have differences in noise compared to the CPU render. Nothing appears obviously broken, and so fixing these are not high priority. These issues occur with Embree GPU on and off. - [ ] `/light/all_light_types` - [ ] `/light_linking/light_link_distant_multi_tree` - [ ] `/light_linking/light_link_distant_tree` - [ ] `/light_linking/light_link_surface_in_volume` - Incorrect rendering - One test is rendering incorrectly when Embree GPU is enabled. Shadows of some semi-transparent objects show artifacts, making the shadow brighter or darker when compared to the CPU. A simplifed file that reproduces the issue can be found in #125093. Just open the file and decrease the transparent bounces to 1023 or lower. - [x] `/light_linking/shadow_link_transparency` - Fixed by (d4ceade5eadea48aaab8e2bbf462ba996dab5fa6)

Alaska added the

labels 2024-07-19 17:13:17 +02:00

Alaska added this to the Render & Cycles project 2024-07-19 17:13:17 +02:00

Alaska commented

2024-07-19 17:13:37 +02:00

CC @xavierh so you know about these issues.

👍 2

Nikita Sirgienko was assigned by Xavier Hallade

2024-07-19 17:37:59 +02:00

Xavier Hallade self-assigned this 2024-07-19 17:38:07 +02:00

Alaska referenced this issue

2024-07-19 17:49:35 +02:00

oneAPI Embree GPU, transparent shadows will render opaque if transparent bounces is 1024 #125093

Alaska referenced this issue

2024-08-03 06:21:16 +02:00

Fix: Cycles BVH2 and Embree missing some transparent shadow bounces #125739

Alaska commented

2024-08-03 06:22:01 +02:00

The incorrect rendering in /light_linking/shadow_link_transparency seems to be fixed by !125739

The incorrect rendering in `/light_linking/shadow_link_transparency` seems to be fixed by !125739

Alaska referenced this issue

2024-08-03 11:31:37 +02:00

Fix: Cycles BVH2 and Embree missing some transparent shadow bounces #125739

Alaska commented

2024-09-25 16:25:46 +02:00

In a recent Cycles meeting there was this note:

Cycles render test: Failing oneAPI tests 125088 3

Nikita will check if increasing samples properly converges

I ran my own tests with all_light_types, light_link_distant_multi_tree, and light_link_distant_tree and the CPU and GPU seem to converge when increasing the sample count.

I didn't test light_link_surface_in_volume.

In a recent [Cycles meeting](https://devtalk.blender.org/t/2024-09-17-render-cycles-meeting/36668) there was this note: > - Cycles render test: Failing oneAPI tests 125088 3 > - Nikita will check if increasing samples properly converges I ran my own tests with `all_light_types`, `light_link_distant_multi_tree`, and `light_link_distant_tree` and the CPU and GPU seem to converge when increasing the sample count. I didn't test `light_link_surface_in_volume`.

all_light_types.png

390 KiB

light_link_distant_multi_tree.png

370 KiB

light_link_distant_tree.png

403 KiB

Nikita Sirgienko commented

2024-09-25 16:40:04 +02:00

@Alaska , This is interesting – because I conducted a similar experiment with the "light link distant multi tree" test, and for me, the CPU and Intel GPU generated images didn't converge even at a doubled resolution (256x256 pixels, 100% Resolution scale) and with 100 Samples (see the ctest report below).
But maybe resolution increase were a bad idea, let me review your data and retest on my side.

@Alaska , This is interesting – because I conducted a similar experiment with the "light link distant multi tree" test, and for me, the CPU and Intel GPU generated images didn't converge even at a doubled resolution (256x256 pixels, 100% Resolution scale) and with 100 Samples (see the ctest report below). But maybe resolution increase were a bad idea, let me review your data and retest on my side. <img width="928" alt="image" src="attachments/e5eb42bd-44a6-4589-8fb2-49043822f846">

image.png

1.1 MiB

Alaska commented

2024-09-25 16:49:34 +02:00

Ah, my results are a bit mis-leading. I forgot that Cycles render tests show 16x the absolute difference of the images. While I was showing 1x the difference.

If I apply the same 16x scale to my 128 samples per pixel test, my results are very similar to yours.
But as the sample count continues to increase (E.g. to 2048 samples per pixel), the difference between CPU and GPU decreases to a point where you can't really tell.

Ah, my results are a bit mis-leading. I forgot that Cycles render tests show 16x the absolute difference of the images. While I was showing 1x the difference. If I apply the same 16x scale to my 128 samples per pixel test, my results are very similar to yours. But as the sample count continues to increase (E.g. to 2048 samples per pixel), the difference between CPU and GPU decreases to a point where you can't really tell.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles render test: Failing oneAPI tests #125088