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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Filipe Laíns (FFY00)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

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

Closed by  Sven-Hendrik Haase (Svenstaro)
Sunday, 14 June 2020, 22:26 GMT
Reason for closing:  Fixed
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 26 May 2020, 00:00 GMT
Nope, the problem is that this picks a better instruction set based on my own processor. I've got to teach openimagedenoise to not use my instruction set.
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 26 May 2020, 00:03 GMT
Actually, can you rebuild openimagedenoise and see if that then works for you? Also, what's your CPU?
Comment by Filipe Laíns (FFY00) - Tuesday, 26 May 2020, 00:08 GMT
I don't think that's what's hapenning. openimagedenoise is setting SSE4.1 manually, see [1].

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
Comment by Frank Carlyle McLaughlin (frankspace) - Tuesday, 26 May 2020, 00:47 GMT
My CPU is an AMD Phenom II X4 975. It is, indeed, somewhat old.

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.
Comment by Frank Carlyle McLaughlin (frankspace) - Tuesday, 26 May 2020, 00:51 GMT
It just occurred to me that I also have access to a notebook computer with an AMD Ryzen 7 Pro 3700U CPU. I checked, and blender with openimagedenoise-1.2.0-2 works fine on that machine.
Comment by Filipe Laíns (FFY00) - Tuesday, 26 May 2020, 00:51 GMT
That tracks.

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.
Comment by Filipe Laíns (FFY00) - Tuesday, 26 May 2020, 00:54 GMT
> It just occurred to me that I also have access to a notebook computer with an AMD Ryzen 7 Pro 3700U CPU. I checked, and blender with openimagedenoise-1.2.0-2 works fine on that machine.

Yes, because is has SSE4.1, while your other computer does not. If you run lscpu, sse4_1 should show up.
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 26 May 2020, 00:59 GMT
A split package would be good. I did this for tensorflow and pytorch as well.
Comment by Frank Carlyle McLaughlin (frankspace) - Monday, 01 June 2020, 02:44 GMT
I opened a bug report upstream, which may be of some interest:

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.
Comment by JackRedstonia (JackRedstonia) - Thursday, 04 June 2020, 11:28 GMT
Is there a reason why we are compiling Blender for this package instead of repackaging the official binaries?
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 05 June 2020, 02:24 GMT
Yes, because it's Arch policy to not use pre-compiled binaries when we can help it.
Comment by Tyler Foo (ghfujianbin) - Friday, 05 June 2020, 08:58 GMT
This issue still persists with Blender 2.83. I can open blender just fine. But if I try to use Intel's denoising when compositing, I just get a silhouette of my render. No diffuse color. No nothing. I have an AMD R5 2600 btw. Precompiled Blender downloaded from their official site works fine.
Comment by JackRedstonia (JackRedstonia) - Friday, 05 June 2020, 16:53 GMT
For things like Blender I think it is best to just repackage the official binaries, instead of trying to figure out how to compile it from scratch with no guarantee that everything will work as intended. This bug is a demonstration of why I think so.
Comment by Filipe Laíns (FFY00) - Friday, 05 June 2020, 16:59 GMT
That is against the guidelines and will not happen. There are several reasons for this, the main being that we have absolutely no control over the official binaries: we cannot change building/linking flags, we cannot patch security vulnerabilities, there is no guarantee against what system libraries the official binaries were built against, etc.
Comment by Arun (arun321) - Sunday, 07 June 2020, 08:13 GMT
Denoising worked fine on 2.82.a-3 but it stopped after updating to 2.83.
Comment by Eli Schwartz (eschwartz) - Tuesday, 09 June 2020, 17:01 GMT
If you want the official blender binaries, you can download them from the blender website, or see if they have an appimage or flatpak or something. You are also encouraged to upload a "blender-bin" package to the AUR, which integrates this into pacman.

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.
Comment by Giancarlo Razzolini (grazzolini) - Thursday, 11 June 2020, 21:43 GMT
*cough* *cough* nuget *cough* *cough*. Also, please, don't delete comments.
Comment by JackRedstonia (JackRedstonia) - Friday, 12 June 2020, 15:11 GMT
FFY00's explanation was perfect, eschwartz's aggression was uncalled for and is not helpful at all to be honest.
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.
Comment by Frank Carlyle McLaughlin (frankspace) - Friday, 12 June 2020, 15:29 GMT
If it's of any value (and obviates the need for a blender-bin package), I did create an openimagedenoise-bin package on AUR. I intend to delete it once this issue is resolved, but in the meantime, does installing that resolve the denoising issue with Blender? I haven't tested whether denoising actually works with it, just whether I can use Blender at all.
Comment by JackRedstonia (JackRedstonia) - Friday, 12 June 2020, 15:38 GMT
openimagedenoise-bin indeed does seem to solve the denoising issue.
Comment by Eli Schwartz (eschwartz) - Friday, 12 June 2020, 17:16 GMT
@grazzolini,

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.
Comment by Eli Schwartz (eschwartz) - Friday, 12 June 2020, 17:18 GMT
  • Field changed: Summary ([blender] 17:2.82.a-6 fails to open with openimagedenoise 1.2.0 → [openimagedenoise] 1.2.0 -- blender fails to open)
I assume given the problem is with openimagedenoise that the /usr/bin/denoise problem fails the same way...

An openimagedenoise-bin package sounds like a much more scoped solution than blender-bin, and works around the problem more thoroughly. :p
Comment by Filipe Laíns (FFY00) - Friday, 12 June 2020, 19:24 GMT
Just pushed openimagedenoise 1.2.0-3 which should fix the issue, please confirm :)
Comment by Frank Carlyle McLaughlin (frankspace) - Friday, 12 June 2020, 19:52 GMT
Confirming that Blender now works as expected for me with Arch's openimagedenoise-1.2.0-3. So the problem is fixed as far as anything I need to do. Thank you very much!

(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.)
Comment by IMBJR (IMBJR) - Friday, 12 June 2020, 20:35 GMT
I'm not 100% sure I should raise a new bug issue, but I will report here that Blender 2.83 still gives me a black image when I try to use the denoise compositing node, with openimagedenoise @ 1.2.0-3.

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.
Comment by Filipe Laíns (FFY00) - Friday, 12 June 2020, 20:37 GMT
Raise it in the blender bugtracker again, https://github.com/OpenImageDenoise/oidn/issues/76 is not the cause.
Comment by IMBJR (IMBJR) - Friday, 12 June 2020, 22:15 GMT
I was about to do just that, after erroneously raising one here, however ...

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.
Comment by JackRedstonia (JackRedstonia) - Saturday, 13 June 2020, 03:44 GMT
I can also confirm that openimagedenoise 1.2.0-3 still gives me a black image.
Comment by Frank Carlyle McLaughlin (frankspace) - Sunday, 14 June 2020, 02:47 GMT
Does the Arch packaged version of Blender also give you a black image with the openimagedenoise-bin package on AUR?
Comment by JackRedstonia (JackRedstonia) - Sunday, 14 June 2020, 06:16 GMT
No, it does not, at least on my machine.
Comment by IMBJR (IMBJR) - Sunday, 14 June 2020, 10:09 GMT
I can also confirm that the openimagedenoise-bin package on AUR gives the correct results.
Comment by Sven-Hendrik Haase (Svenstaro) - Sunday, 14 June 2020, 22:26 GMT
The original crash is fixed and the black image is, too.

Loading...