Big speed regression in the OpenCL kernel (between 50% and 6x slower) #49046

New Issue

mathieu menuet · 2016-08-08T15:22:47+02:00

mathieu menuet commented

2016-08-08 15:22:47 +02:00

System Information
RX480 Win7 with 16.7.3 and Linux with AMD GPU Pro 16.3

Blender Version
Broken: 2.77a and latest master
Worked: 2.76b

Short description of error
The OpenCL Kernel is much slower in current Blender versions than with 2.76b. Several tests from different users confirm the problem, see here: https:*blenderartists.org/forum/showthread.php?400121-AMD-RX-480-with-8-Gigs-of-Vram-at-229&p=3084598&viewfull=1#post3084598 and here: https:*blenderartists.org/forum/showthread.php?400121-AMD-RX-480-with-8-Gigs-of-Vram-at-229&p=3083556&viewfull=1#post3083556. Test without transparent shadows were 6x faster with 2.76b (4 minutes for koro scene compared to 24 minutes with 2.77a) and test with transparent shadows (experimental kernel in 2.76b) are 2x faster on 2.76b than on 2.77a.

Exact steps for others to reproduce the error
Open and render the official Cycles Benchmark files with 2.76b on experimental kernel and on 2.77a or latest buildbot with RX480 and above latest drivers on Linux or Windows. Compare the times. I don't have a RX480 myself , but I guess the only added feature (float textures) can not explain such a huge performance drop ?

**System Information** RX480 Win7 with 16.7.3 and Linux with AMD GPU Pro 16.3 **Blender Version** Broken: 2.77a and latest master Worked: 2.76b **Short description of error** The OpenCL Kernel is much slower in current Blender versions than with 2.76b. Several tests from different users confirm the problem, see here: https:*blenderartists.org/forum/showthread.php?400121-AMD-RX-480-with-8-Gigs-of-Vram-at-229&p=3084598&viewfull=1#post3084598 and here: https:*blenderartists.org/forum/showthread.php?400121-AMD-RX-480-with-8-Gigs-of-Vram-at-229&p=3083556&viewfull=1#post3083556. Test without transparent shadows were 6x faster with 2.76b (4 minutes for koro scene compared to 24 minutes with 2.77a) and test with transparent shadows (experimental kernel in 2.76b) are 2x faster on 2.76b than on 2.77a. **Exact steps for others to reproduce the error** Open and render the official Cycles Benchmark files with 2.76b on experimental kernel and on 2.77a or latest buildbot with RX480 and above latest drivers on Linux or Windows. Compare the times. I don't have a RX480 myself , but I guess the only added feature (float textures) can not explain such a huge performance drop ?

mathieu menuet commented

2016-08-08 15:22:47 +02:00

Changed status to: 'Open'

mathieu menuet commented

2016-08-08 15:22:47 +02:00

Added subscriber: @bliblubli

Brecht Van Lommel commented

2016-08-09 03:48:19 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2016-08-09 03:48:19 +02:00

With an AMD Radeon R9 380 and amdgpu-pro drivers on Linux I can confirm a 50% performance difference in the BMW scene from 2.76b to 2.77a.

Unfortunately due to this commit which helped simplify the code a lot : 9815f8a623. I'm pretty sure that slowdown did this not happen with earlier drivers I had installed.

For the Koro scene I can't find much performance difference between between the two Blender versions. As I understand it the 6x difference with Koro is when rendering with/without transparent shadows, giving a totally different render results, so not much point comparing that. But the post does report a 2x difference with the same settings.

For bug reports someone should really test the latest build from https://builder.blender.org/download/ though, a lot has changed since 2.77a.

Another thing that would be very helpful to test is modifying this one line in 2.77/scripts/addons/cycles/kernel/kernel_types.h from:

#  if defined(__SPLIT_KERNEL_AOS__)

to:

#  if !defined(__SPLIT_KERNEL_AOS__)

For me that change solves most of the BMW slowdown with 2.77a but not in the latest builds.

With an AMD Radeon R9 380 and amdgpu-pro drivers on Linux I can confirm a 50% performance difference in the BMW scene from 2.76b to 2.77a. Unfortunately due to this commit which helped simplify the code a lot : 9815f8a623. I'm pretty sure that slowdown did this not happen with earlier drivers I had installed. For the Koro scene I can't find much performance difference between between the two Blender versions. As I understand it the 6x difference with Koro is when rendering with/without transparent shadows, giving a totally different render results, so not much point comparing that. But the post does report a 2x difference with the same settings. For bug reports someone should really test the latest build from https://builder.blender.org/download/ though, a lot has changed since 2.77a. Another thing that would be very helpful to test is modifying this one line in `2.77/scripts/addons/cycles/kernel/kernel_types.h` from: ``` # if defined(__SPLIT_KERNEL_AOS__) ``` to: ``` # if !defined(__SPLIT_KERNEL_AOS__) ``` For me that change solves most of the BMW slowdown with 2.77a but not in the latest builds.

mathieu menuet commented

2016-08-09 11:31:04 +02:00

Reported times are really impressive. I should get a RX480 in the coming days, will report as soon as possible.

Marius Eckardt commented

2016-08-09 18:11:48 +02:00

Added subscriber: @Alirion-2

Marius Eckardt commented

2016-08-09 18:11:48 +02:00

RX480 Sapphire Stock 1266 Mhz / Ubuntu/Liquorix - Driver: amdgpu-pro 16.3

Quick test with BMWv2 (20^2):
2.77a Orig: 1.15
2.77a with AOS Change: 1.02
2.76b: 1.00
2.77.3 (b53eca1): 1.42 (and Resulting in a completelly black render - last version i checked was "a27acef" and resulted in a fine render. )

RX480 Sapphire Stock 1266 Mhz / Ubuntu/Liquorix - Driver: amdgpu-pro 16.3 Quick test with BMWv2 (20^2): 2.77a Orig: 1.15 2.77a with AOS Change: 1.02 2.76b: 1.00 2.77.3 (b53eca1): 1.42 (and Resulting in a completelly black render - last version i checked was "a27acef" and resulted in a fine render. )

soulfire commented

2016-08-09 22:44:43 +02:00

Added subscriber: @TomG

Sergey Sharybin commented

2016-08-12 15:28:46 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2016-08-12 15:28:46 +02:00

@brecht, was running tests on Windows 10, Radeon Pro 2 (Fiji) and latest driver 16.8.1. Latest master is still significantly slower than 2.76 (6min vs 8min). This applies to both AOS and SOA. And you're right, there was no visible performance difference when the patch you're mentioning was applied.

mathieu menuet commented

2016-08-12 15:47:02 +02:00

first results with RX480 on 2.76b, 2.77a and latest master bac1279 on the BMW Benchmark from here https://download.blender.org/demo/test/cycles_benchmark_20160228.zip (so with 2^32 spp) without the kernel compile time of course:

Linux with AMD GPU PRO 16.30:
- 2.77a without fix: 4min32
- 2.77a with fix: 3min40
- bac1279 with fix: 7min01 (more than 2x slower )
- 2.76b: 3min 25
Win7 with 16.8.1:
- bac1279 : 6min50
- 2.76b : 3min 57

first results with RX480 on 2.76b, 2.77a and latest master bac1279 on the BMW Benchmark from here https://download.blender.org/demo/test/cycles_benchmark_20160228.zip (so with 2^32 spp) without the kernel compile time of course: - Linux with AMD GPU PRO 16.30: - 2.77a without fix: 4min32 - 2.77a with fix: 3min40 - bac1279 with fix: 7min01 (more than 2x slower ) - 2.76b: 3min 25 - Win7 with 16.8.1: - bac1279 : 6min50 - 2.76b : 3min 57

mathieu menuet commented

2016-08-12 22:39:48 +02:00

Results for the Barcelona scene (RX480, same as above):

38min41 on win7 with bac1279
38min30 on Linux with bac1279
16:51 on Linux with 2.76b (2.3x faster)
16:32 on Linux with 2.77a and fix (2.33x faster, maybe due to some new optimisations?)

Results for the Barcelona scene (RX480, same as above): - 38min41 on win7 with bac1279 - 38min30 on Linux with bac1279 - 16:51 on Linux with 2.76b (2.3x faster) - 16:32 on Linux with 2.77a and fix (2.33x faster, maybe due to some new optimisations?)

mathieu menuet commented

2016-08-12 22:44:41 +02:00

To sum up results: 2.77a with fix is just slightly slower than 2.76b. Latest master is between 100% and 130% (2 and 2.3x) slower than 2.76b (with experimental kernel for transparent shadows)/2.77a ( supported kernel with Brecht's fix) with the RX 480 and latest drivers on Linux and windows.

mathieu menuet commented

2016-08-13 15:09:17 +02:00

The Barcelona scene is even faster on 2.77a with fix than on 2.76b. both are around 2.3 time faster than current master.

16:32 on Linux with 2.77a and fix (2.33x faster, maybe due to some new optimizations?)
By the way, without transparent shadows, it even reaches 8min23 which is again about a 2x speedup. On CPU, disabling transparent shadows in all materials only gives a 1.2x speedup. So there is maybe some room to improve the transparent shadows code on GPU.

The Barcelona scene is even faster on 2.77a with fix than on 2.76b. both are around 2.3 time faster than current master. - 16:32 on Linux with 2.77a and fix (2.33x faster, maybe due to some new optimizations?) - By the way, without transparent shadows, it even reaches 8min23 which is again about a 2x speedup. On CPU, disabling transparent shadows in all materials only gives a 1.2x speedup. So there is maybe some room to improve the transparent shadows code on GPU.

mathieu menuet commented

2016-08-13 20:16:28 +02:00

Just a note. During test, I measured the power draw as requested by some users. It happens that Cycles only draws 89W extra power while rendering compared to idle with the RX480 under windows. LuxMark 3.1 draws 142W extra power, which is the max. for this card including the 10W used at idle (152W all inclusive).
So it seems the last generation is somehow heavily underused in 2.77a with fix (tested with Barcelona and BMW).

Just a note. During test, I measured the power draw as requested by some users. It happens that Cycles only draws 89W extra power while rendering compared to idle with the RX480 under windows. LuxMark 3.1 draws 142W extra power, which is the max. for this card including the 10W used at idle (152W all inclusive). So it seems the last generation is somehow heavily underused in 2.77a with fix (tested with Barcelona and BMW).

Brecht Van Lommel commented

2016-08-14 02:44:43 +02:00

I've bisected it to 0b68c68006. For CUDA the impact was small but apparently not for AMD OpenCL, where we can't ask to uninline the function.

Before that commit, with AOS storage, performance is still close to 2.76b for me.

I've bisected it to 0b68c68006. For CUDA the impact was small but apparently not for AMD OpenCL, where we can't ask to uninline the function. Before that commit, with AOS storage, performance is still close to 2.76b for me.

Brecht Van Lommel commented

2016-08-14 02:56:24 +02:00

Added subscriber: @MaiLavelle

Brecht Van Lommel commented

2016-08-14 02:56:24 +02:00

cc @maiself. We should only enable this code if OpenSubdiv is actually used in the scene, through the DeviceRequestedFeatures mechanism. Ideally we can find a way to avoid this slowdown also when using OpenSubdiv, but for 2.78 disabling the code for OpenCL (and the adaptive CUDA kernel) if unused would be safest.

Beyond that we could consider switching to AOS storage everywhere. At least with R9 380 and RX480 the SOA storage does not seem like it's helpful (regardless of the 9815f8a623 cleanup), and in fact AOS seems slightly faster with those newer cards. I would love to get rid of ccl_fetch(). But maybe there's still cards where it is important, any idea about that @Sergey?

cc @maiself. We should only enable this code if OpenSubdiv is actually used in the scene, through the `DeviceRequestedFeatures` mechanism. Ideally we can find a way to avoid this slowdown also when using OpenSubdiv, but for 2.78 disabling the code for OpenCL (and the adaptive CUDA kernel) if unused would be safest. Beyond that we could consider switching to AOS storage everywhere. At least with R9 380 and RX480 the SOA storage does not seem like it's helpful (regardless of the 9815f8a623 cleanup), and in fact AOS seems slightly faster with those newer cards. I would *love* to get rid of `ccl_fetch()`. But maybe there's still cards where it is important, any idea about that @Sergey?

mathieu menuet commented

2016-08-14 19:30:39 +02:00

Thank you Brecht for finding the right commit. Trying to disable OpenSubDiv in cycles with this line in cmakelists.txt:

option(WITH_CYCLES_OPENSUBDIV		"Build Cycles with OpenSubdiv support" OFF)

doesn't give any speed improvement. Is there another way to disable it?

Thank you Brecht for finding the right commit. Trying to disable OpenSubDiv in cycles with this line in cmakelists.txt: ``` option(WITH_CYCLES_OPENSUBDIV "Build Cycles with OpenSubdiv support" OFF) ``` doesn't give any speed improvement. Is there another way to disable it?

Mai Lavelle commented

2016-08-14 19:48:57 +02:00

@bliblubli, currently you can't disable it in kernel, which is where the problem is. I'll be looking into this later today.

Sergey Sharybin commented

2016-08-15 10:15:27 +02:00

@brecht, hard to tell nowadays without running full tests on all the hardware we've got -- the driver changes a lot and old working optimizations might not be working as good as they used to and vice versa.

So guess we have to make some special build with AOS/SOA toggle and call users to test on latest 16.8 drivers.

That being said, on a Fiji card i didn't see measurable difference in performance AFAIR.

Couple of side notes:

We would need to move to CUDA split eventually, so need to study what works better on that architecture.
Some interesting research from Intel [1]
https://software.intel.com/sites/default/files/article/392271/aos-to-soa-optimizations-using-iterative-closest-point-mini-app.pdf

@brecht, hard to tell nowadays without running full tests on all the hardware we've got -- the driver changes a lot and old working optimizations might not be working as good as they used to and vice versa. So guess we have to make some special build with AOS/SOA toggle and call users to test on latest 16.8 drivers. That being said, on a Fiji card i didn't see measurable difference in performance AFAIR. Couple of side notes: - We would need to move to CUDA split eventually, so need to study what works better on that architecture. - Some interesting research from Intel [1] - [x] https://software.intel.com/sites/default/files/article/392271/aos-to-soa-optimizations-using-iterative-closest-point-mini-app.pdf

Brecht Van Lommel commented

2016-08-15 20:21:42 +02:00

The OpenSubdiv part of the regression was fixed in 76b6c77f2c.

I think we could enable AoS in master and ask users if they see performance regression compared to 2.76b / 2.77a? Not sure it's worth making a special build.

The BMW render time difference from #48876#382582 might be explained by the AoS/SoA changes as well.

I wonder if AMD ProRender and NVidia Optix use SoA for their equivalent data structures. If not we probably shouldn't be making it complicated for ourselves. With C++ we can have sg->P() syntax which would be a lot nicer, but OpenCL C++ is still a long way from being ready to use.

The OpenSubdiv part of the regression was fixed in 76b6c77f2c. I think we could enable AoS in master and ask users if they see performance regression compared to 2.76b / 2.77a? Not sure it's worth making a special build. The BMW render time difference from #48876#382582 might be explained by the AoS/SoA changes as well. I wonder if AMD ProRender and NVidia Optix use SoA for their equivalent data structures. If not we probably shouldn't be making it complicated for ourselves. With C++ we can have `sg->P()` syntax which would be a lot nicer, but OpenCL C++ is still a long way from being ready to use.

Sergey Sharybin commented

2016-08-15 21:23:08 +02:00

Do you want to go AoS official at BCon3? Did you see render time difference? For me render time was quite the same, so it's almost not really worth changes now, can happen after release.

Brecht Van Lommel commented

2016-08-15 22:12:10 +02:00

For me changing to AoS renders about 20% faster in the benchmark scenes, and fixes the performance regression we had going from 2.76b to 2.77a. @bliblubli reports similar numbers. So in that sense it's a bugfix for bcon3, and it's also a pretty safe change as far as correctness is concerned.

But it is of course possible that this causes a performance regression on some (older?) cards, but probably not more than the 20% we save on (newer?) cards? So to me it seems reasonable to make this change now.

For me changing to AoS renders about 20% faster in the benchmark scenes, and fixes the performance regression we had going from 2.76b to 2.77a. @bliblubli reports similar numbers. So in that sense it's a bugfix for bcon3, and it's also a pretty safe change as far as correctness is concerned. But it is of course possible that this causes a performance regression on some (older?) cards, but probably not more than the 20% we save on (newer?) cards? So to me it seems reasonable to make this change now.

mathieu menuet commented

2016-08-15 22:53:41 +02:00

First results on Linux with new commit from Mai Lavelle on RX480 with GPU Pro 16.30:

Fishy Cat: Much faster :) Probably due to the new Hair BVH, impressive results Sergey, nearly 3x faster than 2.76b :D
- before commit 27min34
- with SOA: 10min40
- with AOS (patch proposed by Brecht applied): 8min 52
- 2.76b: 26:29
BMW: good improvement, but still 28%slower
- before commit 7min01
- with SOA: 5min30
- with AOS: 4min27
- 2.76b: 3min25

As Brecht said and same as previous results, 20% better with AOS on latest master after commit to fix OSD in OpenCL.

First results on Linux with new commit from Mai Lavelle on RX480 with GPU Pro 16.30: - Fishy Cat: Much faster :) Probably due to the new Hair BVH, impressive results Sergey, nearly 3x faster than 2.76b :D - before commit 27min34 - with SOA: 10min40 - with AOS (patch proposed by Brecht applied): 8min 52 - 2.76b: 26:29 - BMW: good improvement, but still 28%slower - before commit 7min01 - with SOA: 5min30 - with AOS: 4min27 - 2.76b: 3min25 As Brecht said and same as previous results, 20% better with AOS on latest master after commit to fix OSD in OpenCL.

mathieu menuet commented

2016-08-15 22:56:06 +02:00

Did some test on Barcelona and BMW on a R9 280X (old architecture) on 2.77a: with and without AOS make no significant difference (1%, in the error threshold)

mathieu menuet commented

2016-08-15 23:10:59 +02:00

Results on Barcelona with RX480 and new commit: much faster than before commit but still slower

before commit: 38min30
after and with AOS: 17min58
2.77a with AOS: 16min41

Results on Barcelona with RX480 and new commit: much faster than before commit but still slower - before commit: 38min30 - after and with AOS: 17min58 - 2.77a with AOS: 16min41

soulfire commented

2016-08-15 23:47:08 +02:00

Blender build 15.8.2016 crashes immediately when GPU starts rendering.
Also, crashes in viewport rendering mode.
(AMD 7870, every Cycles scene,latest drivers)
Where can I find console log file so that I can report what happened?

Blender build 15.8.2016 crashes immediately when GPU starts rendering. Also, crashes in viewport rendering mode. (AMD 7870, every Cycles scene,latest drivers) Where can I find console log file so that I can report what happened?

mathieu menuet commented

2016-08-16 08:49:05 +02:00

@TomG Start blender from the command line and report in another ticket.
If you modified the kernel_types.h with above mentioned modifications, say it there.
Best would be to try with and without this modification to see if the crash is due to it. (see first post from Brecht in this thread.)

Note: I had a system lock trying to render the Goosberry scene, most certainly due to a driver problem under Linux. It works under Windows.

@TomG Start blender from the command line and report in another ticket. If you modified the kernel_types.h with above mentioned modifications, say it there. Best would be to try with and without this modification to see if the crash is due to it. (see first post from Brecht in this thread.) Note: I had a system lock trying to render the Goosberry scene, most certainly due to a driver problem under Linux. It works under Windows.

soulfire commented

2016-08-16 10:10:04 +02:00

This comment was removed by @TomG

*This comment was removed by @TomG*

soulfire commented

2016-08-16 11:06:33 +02:00

I'm not using modification. I'm running Win10 64.
I found blender -b file.blend-f 01 that this renders within comand line.
I saved screens from console

EDIT> FIXED IN TODAYS BUILD

I'm not using modification. I'm running Win10 64. I found blender *-b file.blend*-f 01 that this renders within comand line. I saved screens from console ![crash1.JPG](https://archive.blender.org/developer/F337691/crash1.JPG) ![crash2.JPG](https://archive.blender.org/developer/F337696/crash2.JPG) EDIT> FIXED IN TODAYS BUILD

mathieu menuet commented

2016-08-17 20:51:52 +02:00

Classroom test: 10,6% slower
2.76b: 13:10
master with AOS and Mai's commit: 14:35

Classroom test: 10,6% slower 2.76b: 13:10 master with AOS and Mai's commit: 14:35

mathieu menuet commented

2016-08-20 16:48:24 +02:00

@brecht the change to kernel_types.h you mentioned in your first answer here resolves a big part of the regression for newer cards and has no negative effect on older ones. So it maybe good to have it as default? For test purpose, a check-box can be added to the debug panel if started with --debug-value 256 to get the SOA version. It would allow to get comparable results when people post benchmark times on BA.

Brecht Van Lommel commented

2016-08-20 18:02:33 +02:00

I think it's safe to make this change still, if @Sergey agrees I'll commit it. Not sure it helps much to have this as a debug option.

mathieu menuet commented

2016-08-20 21:22:08 +02:00

@brecht should I open a design task for the project cycles listing the current speed problems and missing features in the OpenCL kernel? As a dev should start to work on the split kernel paid by AMD, it could be great to have a listing of the current shortcomings. Otherwise I can post speed problem further here.

Brecht Van Lommel commented

2016-08-21 00:01:26 +02:00

It's best to create a wiki page under:
https://wiki.blender.org/index.php/Dev:Source/Render/Cycles

Tasks here should be individual tasks that can be finished and closed.

It's best to create a wiki page under: https://wiki.blender.org/index.php/Dev:Source/Render/Cycles Tasks here should be individual tasks that can be finished and closed.

Sergey Sharybin commented

2016-08-23 12:50:19 +02:00

@brecht, if you're around to deal with possible negative effects go ahead.

mathieu menuet commented

2016-08-23 20:24:43 +02:00

In #49046#387149, @brecht wrote:
It's best to create a wiki page under:
https://wiki.blender.org/index.php/Dev:Source/Render/Cycles

Tasks here should be individual tasks that can be finished and closed.

@brecht I asked for a wiki account, but still no answer yet.

> In #49046#387149, @brecht wrote: > It's best to create a wiki page under: > https://wiki.blender.org/index.php/Dev:Source/Render/Cycles > > Tasks here should be individual tasks that can be finished and closed. @brecht I asked for a wiki account, but still no answer yet.

Brecht Van Lommel commented

2016-08-24 02:18:01 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2016-08-24 02:18:01 +02:00

Brecht Van Lommel self-assigned this 2016-08-24 02:18:01 +02:00

Brecht Van Lommel commented

2016-08-24 02:18:01 +02:00

Ok, I've committed the SoA to AoS change now.

I'll consider this task resolved for now. We can keep investigating OpenCL performance, but there's been a lot of changes and some performance variation is expected. Optimizing that is more regular development than bugfixing.

@bliblubli, if you mail me at brecht@blender.org with the account name and email address you want to use I can create the wiki account.

Ok, I've committed the SoA to AoS change now. I'll consider this task resolved for now. We can keep investigating OpenCL performance, but there's been a lot of changes and some performance variation is expected. Optimizing that is more regular development than bugfixing. @bliblubli, if you mail me at brecht@blender.org with the account name and email address you want to use I can create the wiki account.

mathieu menuet commented

2016-08-31 14:19:42 +02:00

Further investigating the speed regressions, benchmark revealed following: SoA is faster when transparent shadows are deactivated in kernel_types.h. As 2.77a had only transparent shadows in the experimental kernel, it was fast. Now that transparent shadows are activated by default, it is slower.

So we could either make the "shadows" checkbox in the lightpath panel make the transparent shadows to selectively compile like the way it was with experimental kernel. At the moment, the checkbox disable transparent shadows, but the kernel is compiled with it anyway. The best would be to make it automatic and only compile if there is a transparent BSDF in a nodetree. It would allow to reactivate SoA and make further speed improvements with it. In some scene, disabling transparent shadows in kernel_types and with SoA I get up to 30% speedup which is great. At the moment, there is no way to disable Transparent shadows anymore, so it's a big speed regression for user not compiling themselves in many scenes (between 10 and 20% in my tests).

Further should be investigated why transparent shadows are so slow and why they are slower with SoA.

Further investigating the speed regressions, benchmark revealed following: SoA is faster when transparent shadows are deactivated in kernel_types.h. As 2.77a had only transparent shadows in the experimental kernel, it was fast. Now that transparent shadows are activated by default, it is slower. So we could either make the "shadows" checkbox in the lightpath panel make the transparent shadows to selectively compile like the way it was with experimental kernel. At the moment, the checkbox disable transparent shadows, but the kernel is compiled with it anyway. The best would be to make it automatic and only compile if there is a transparent BSDF in a nodetree. It would allow to reactivate SoA and make further speed improvements with it. In some scene, disabling transparent shadows in kernel_types and with SoA I get up to 30% speedup which is great. At the moment, there is no way to disable Transparent shadows anymore, so it's a big speed regression for user not compiling themselves in many scenes (between 10 and 20% in my tests). Further should be investigated why transparent shadows are so slow and why they are slower with SoA.

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

Big speed regression in the OpenCL kernel (between 50% and 6x slower) #49046