OIDN: RAM increases proportionally with each Denoise node used #69006

Closed
opened 2019-08-21 19:21:12 +02:00 by YAFU · 5 comments

System Information
Operating system: Linux-5.0.1-050001-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 960/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.40

Blender Version
Broken: version: 2.81 (sub 2), branch: master, commit date: 2019-08-20 18:26, hash: b6b01c48fa
Worked: (optional)

Hello
Apparently RAM increases proportionally with each Denoise node used in compositor:
Denoise RAM_1.blend
Denoise RAM_2.blend

Denoise RAM_1.blend - 2.2GiB
Denoise RAM_2.blend - 13GiB

We are not sure about whether this is an expected behavior or a bug:
https://blenderartists.org/t/big-denoise-test-intel-open-image-denoise-vs-others/1175114/46

**System Information** Operating system: Linux-5.0.1-050001-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GTX 960/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.40 **Blender Version** Broken: version: 2.81 (sub 2), branch: master, commit date: 2019-08-20 18:26, hash: `b6b01c48fa` Worked: (optional) Hello Apparently RAM increases proportionally with each Denoise node used in compositor: [Denoise RAM_1.blend](https://archive.blender.org/developer/F7682181/Denoise_RAM_1.blend) [Denoise RAM_2.blend](https://archive.blender.org/developer/F7682340/Denoise_RAM_2.blend) Denoise RAM_1.blend - 2.2GiB Denoise RAM_2.blend - 13GiB We are not sure about whether this is an expected behavior or a bug: https://blenderartists.org/t/big-denoise-test-intel-open-image-denoise-vs-others/1175114/46
Author

Added subscriber: @YAFU

Added subscriber: @YAFU
Stefan Werner was assigned by Brecht Van Lommel 2019-08-21 19:32:05 +02:00
Member

The compositor is running separate threads for independent nodes. In most constellations, that means that all denoising nodes run at the same time.

Since OIDN internally is multithreaded across all CPU cores, should we wrap it in a mutex to ensure only one denoising kernel runs at a time?

The compositor is running separate threads for independent nodes. In most constellations, that means that all denoising nodes run at the same time. Since OIDN internally is multithreaded across all CPU cores, should we wrap it in a mutex to ensure only one denoising kernel runs at a time?

Added subscriber: @brecht

Added subscriber: @brecht

Mutex sounds like a good solution to me.

Mutex sounds like a good solution to me.
Member

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Sign in to join this conversation.
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#69006
No description provided.