since CD4toA 3.0.3 the autobump option can result in decreasing CPU & GPU utilisatzion by over 75%

[skx555]

Hi there - the Scene File to reproduce this behavior

I tested it in CD4toA 3.0.3 / CD4toA 3.0.3.1 / CD4toA 3.0.4

The scene has three cameras. The activated autobump state triggers a correlation between the distance to the object and the percentage of the CPU utilisatzion. Changing the displacement height also alters that behavior.


R21 CD4toA 3.0.2.1 Cam B - 11 sec
R21 CD4toA 3.0.4 Cam B - 39 sec

R21 CD4toA 3.0.2.1 Cam C - 30 sec
R21 CD4toA 3.0.4 Cam C - 8min 39 sec

Scene File

[peter.horvath6V6K3]

I'm not able to reproduce it on my machine, CPU utilization is 100% in C4DtoA 3.0.4. Could you show us the log file for both 3.0.2.1 and 3.0.4, with verbosity level set to debug? Instructions how to setup the log: https://docs.arnoldrenderer.com/display/A5AFCUG/Log

[peter.horvath6V6K3]

I'm also noticing that you are using the OCIO color manager in the scene. Can you check if using the builtin color manager instead makes any difference?

[skx555]

All the Log Files for Cam 1 - 3, C4DtoA 3.0.2.1 vs 3.0.4, in ACES & built in color manager

Log_Files.zip

[skx555]

Switching to the built in color manager in C4DtoA 3.0.4 did indeed result in again full CPU utilization for my specific scene on all cam/distances.

Thank you for having a look!

[peter.horvath6V6K3]

From the log it seems texture access is responsible for the huge overhead. I see that the Max cache size is set to 0. Could you try setting it to the default 2048?

[skx555]

Scene with OCIO/ACES & cam c and Max cache size set to 2048

C4DtoA 3.0.2.1 - 0:31
C4DtoA 3.0.4 - 0:55

Texture_Size_Max_Logfiles.zip

[thiago.ize]

That's odd, the log is now reporting that the cache size is 2048MB, like you said, but that this is still causing you to re-read 63.9GB of textures even though you really only needed a 71.5MB cache in order to store all this data:

00:00:55  1588MB         |   Options:  max_memory_MB=2048.0 max_open_files=1536 autotile=64
<snip>
00:00:55  1588MB         |     Total pixel data size of all images referenced : 71.5 MB
<snip>
00:00:55  1588MB         |     redundant reads: 8374127 tiles, 63.9 GB
00:00:55  1588MB         |     Peak cache memory : 20.9 MB

[thiago.ize]

The older c4dtoa on the other hand performed as expected, with essentially no redundant reads and everything fitting in the cache, so of course it was nice and fast:

00:00:31  1377MB         |   Options:  max_memory_MB=2048.0 max_open_files=1536 autotile=64
<snip>
00:00:31  1377MB         |     Total pixel data size of all images referenced : 58.7 MB
<snip>
00:00:31  1377MB         |     redundant reads: 1 tiles, 8 KB
00:00:31  1377MB         |     Peak cache memory : 13.3 MB

Could you try exporting the scene to an .ass file and rendering with the kick tool that comes with c4dtoa?

[skx555]

I rendered the scene with C4DtoA 3.0.4 / Cam C via kick command line and set the verbose level to 6



00:00:53 285MB | redundant reads: 0 tiles, 0 B
00:00:53 285MB | Peak cache memory : 20.9 MB

Kick_Log_Verbose_Level_6.txt

[thiago.ize]

OK, I think I know what is going on. There are actually two unrelated problems.

1. The texture cache being 10MB will for sure kill performance. We can see that in this log file you supplied, where it took 8m43s and of that 8m10s was accessing textures:

00:08:43  1477MB         | top session self-times by category 
00:08:43  1480MB         |  AiTextureHandleAccess                                              8:10.82 (93.85%)
<snip>
00:08:43  1480MB         |   Options:  max_memory_MB=10.0 <snip>

When the texture lookups were under 10MB, performance was fine, but once it went over we can get this huge performance hit. In a future release of Arnold we'd like to fix this by preventing users from setting the cache to be this low.

2. c4dtoa 3.0.4 has a change with regards to color management that resulted in the opacity being sent to arnold going from <1 1 1>, so completely opaque, to now being <1.00000072 1.00000143 0.999999821>, which in the blue channel is now just barely not opaque. This should have been the same, but computers can't do math perfectly and so this bit of numerical precision error was introduced. We'll try to make Arnold more tolerant to this type of precision error as well so that you hopefully won't get this slowdown.

So to summarize, the precision error made arnold do more work and shade more geometry. This gave a moderate slowdown. The shading of more geometry meant more texture reads which caused the 10MB cache to be exceeded and that gave the huge slowdown.

[skx555]

@Thiago Ize

• 1263Ruf
• 226Beiträge
• 0Gefolgt
• 1Follower
• 8/17Beigetreten

(replying here due character limitations with the reply function)

I see, thank you for all the love you guys put in to Arnold!

I was under the impression that a value of zero sets the cache size to unrestricted, may bad!

I will provide another Scene/Logs where I compare the GPU render times of C4DtoA 3.0.2.1 VS. C4DtoA 3.0.4 in ACES & Built In Color Manager. This is the actually scene where I recognized the jumped in render time after C4DtoA 3.0.3 from 13 minutes to 21 minutes.

I just want to point out that at least in my case, render times did increase with ACES compared to the Built In color manager. Is this increase an expected tax on render times for deeper/better color precision?

Can this numerical precision error be avoided by specific nodes / render setting /clamping etc. ?



00:13:41 GPU Portrait C4DtoA3.0.2.1 ACES autobump_off
00:13:26 GPU Portrait C4DtoA3.0.2.1 ACES autobump_on
00:08:44 GPU Portrait C4DtoA3.0.2.1 Built_In_Colormanager autobump_off
00:09:22 GPU Portrait C4DtoA3.0.2.1 Built_In_Colormanager autobump_on


00:14:46 GPU Portrait C4DtoA3.0.4 ACES autobump_off
00:21:03 GPU Portrait C4DtoA3.0.4 ACES autobump_on
00:08:10 GPU Portrait C4DtoA3.0.4 Built_In_Colormanager autobump_off
00:08:39 GPU Portrait C4DtoA3.0.4 Built_In_Colormanager autobump_on

GPU_Portrait_Scene_Log.zip

[thiago.ize]

The logs show more rays being traced with the ACES, so that is probably why it's slower. My guess is that this might be the same precision bug I mentioned earlier.

A workaround and also way to verify this while you wait for the fixed arnold build is to export your ACES scene to .ass, then open the .ass file in a text editor and delete all the lines where opacity is barely not 1, they'll look sort of like:

opacity 1.00000072 1.00000143 0.999999821

so that the default opacity 1 1 1 gets used instead. You can then render your scene with kick and see if it's fast again.

[peter.horvath6V6K3]

The precision error mentioned above is now fixed in C4DtoA 3.0.4.1, so you should get the performance with the OCIO color manager as before.