FS#66779 - [openimagedenoise] 1.2.0 -- blender fails to open
Attached to Project:
Community Packages
Opened by Frank Carlyle McLaughlin (frankspace) - Monday, 25 May 2020, 17:36 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Sunday, 14 June 2020, 22:26 GMT
Opened by Frank Carlyle McLaughlin (frankspace) - Monday, 25 May 2020, 17:36 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Sunday, 14 June 2020, 22:26 GMT
|
Details
Description: blender 17:2.82.a-6 fails to open with
openimagedenoise 1.2.0
Steps to reproduce: Attempting to launch blender with openimagedenoise-1.2.0-2 installed fails with "illegal instruction (core dumped)". The only error in my log is: "traps: blender[20929] trap invalid opcode ip:7fe8fec9091d sp:7fffa5478rb0 error:0 in libOpenImageDenoise.so.1.2.0[7fe8fec80000+320000]" Downgrading to openimagedenoise-1.1.0-1 resolves the problem and blender can be used normally. My presumption is that blender needs to be rebuilt against the latest openimagedenoise. |
This task depends upon
Since the performance hit is *very* significant, we might want to make build a non-SIMD and SSE4.1 variant, like I do for srslte and liquid-dsp.
[1] https://github.com/OpenImageDenoise/oidn/blob/ef3e9c739ec508173a1db96bbc84c2d4e1327b53/cmake/oidn_platform.cmake#L69
I rebuilt openimagedenoise-1.2.0-2 in a clean chroot. It compiled fine. However, upon installation, blender still fails in the same way. Once again, downgrading back to openimagedenoise-1.1.0-1 resolves the problem.
The culpirt commit: https://github.com/OpenImageDenoise/oidn/commit/7d4f9d8a4c851b651ba5ceea98cef131f35c27ba
Sven, let me know if you're fine with having a split package or if you rather just rip out SSE4.1 entirely.
Yes, because is has SSE4.1, while your other computer does not. If you run lscpu, sse4_1 should show up.
https://github.com/OpenImageDenoise/oidn/issues/76
Of note, upstream does not agree with the assessment of SSE4.1 being manually forced, and installing the official binaries instead of trying to compile them works perfectly with blender.
If you want to use a linux distribution official repository such as [community], it will build from source. It will NOT be a -bin package, as those are exclusive to the AUR.
This is not up for discussion. Stop this line of thought immediately. Any and all attempts to argue otherwise will be ignored and deleted, because you don't understand the fundamental point of a linux distribution.
That aside, is active work going on to fix this issue? If not, I will try to figure out how to write a PKGBUILD for a blender-bin package.
Having integration with the rest of the system is quite important for me, who uses Blender very frequently.
I don't believe in the broken windows principle. If nuget is going against the normal packaging policies here, then surely it should be fixed too. Though I see it is a Windows executable repackaged for mono, so it's possible it simply doesn't compile on Linux operating systems to begin with.
An openimagedenoise-bin package sounds like a much more scoped solution than blender-bin, and works around the problem more thoroughly. :p
(Therefore, once JackRedstonia also confirms that denoising works as expected, I'll go ahead and delete the -bin package, unless someone knows of a good reason why it should be left up.)
An issue was raised on the blender bugtracker (https://developer.blender.org/T77372) but was closed, perhaps on the assumption that this openimagedenoise issue (https://github.com/OpenImageDenoise/oidn/issues/76) was the cause.
According to https://archive.blender.org/development/report-a-bug/ :
We can only support the Blender binaries as have been distributed on blender.org. First thing to test is therefore always if official releases have the error.
So I did, and the official binary does not have the issue. This appears to be a problem with the Arch packaged version of blender.