THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(75,25-100): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[that-ben]

Been away for a year or two. Today, I decided to update 2 apps I made using three.js r87 tough they are still perfectly working (very fluid performance with absolutely no warning in the console). After updating to r116 and adjusting some of the old code for compatibility, I now get some of the following in the console whenever the camera aims low (-Y) and performance is very choppy tough that may be unrelated, perhaps missing a few more compatibility code changes; Haven't read the hundreds of pages of migration notes yet...

THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(75,25-100): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

The thing is: I use exactly zero pow() function in my code and there is no pow() function in any of the shaders either! I am not using post-processing at all. Any idea what is causing this? From what I read, this bug appears in a lot of three.js projects since around fall 2019. I've also read it potentially received fixes for nVidia GPU but not AMD. Is that true?

Important detail to note is that the SAME CODE (zero modification to it) works flawlessly, zero warning and silky smooth performance in r110 and r111. I confirm that this bug started with r112 and it seems like all revisions up to (and including) r116 are affected.

Three.js version

• [ ] Dev
• [x] r116
• [x] r115
• [x] r114
• [x] r113
• [x] r112
• [ ] r111
• [ ] r110
• [ ] ...

Browser

• [ ] All of them
• [ ] Chrome
• [x] Firefox
• [ ] Internet Explorer

OS

• [ ] All of them
• [x] Windows
• [ ] macOS
• [ ] Linux
• [ ] Android
• [ ] iOS

Hardware Requirements (graphics card, VR Device, ...)

AMD Radeon R9 270x

[mrdoob]

This is a warning that browsers are considering hiding: https://bugs.chromium.org/p/chromium/issues/detail?id=765576

[that-ben]

OK but is there a reason it started with r112? Is that related to a new functionality that appeared in r112? Because the huge lag spikes only exist in revisions where the X3571 warning also exists.

[mrdoob]

Sorry, I missed the last paragraph. Are you saying that the performance regression started in the same revision that started displaying X3571 warnings?

[that-ben]

Yes that is exactly what I meant. Both the X3571 warning and lag spikes are in the same revisions tied together. It is silky smooth and no warning at all in the console in r110 and r111. Then the bug and performance degradation started in r112 all the way up to even today's revision (r116). It runs but it has very constant lag spikes every second. This does not occur at all in r110 and r111. It only happens in r112 to r116.

[mrdoob]

Any chance you can upload the project with both versions so we can inspect them?

[mrdoob]

Can you share it privately by email?

[that-ben]

OK, I have made a very minimalist test case based on my original code. I think it could even be stripped more, but I'm ready to send it to you as is. The bug happens only once after 3 seconds with this minimalist test case. You can comment line 6 and uncomment line 7 to swap between r116 (bad) or r111 (good). There is no camera control, no fullscreen mode because I tried to make it as small as possible to isolate the problem.

https://wetransfer.com/downloads/87bee3909c52739e573bbd7cc2f052fe20200502202553/d48f034f6d7f677a77feb16feaefc54f20200502202604/648a03

This needs to be called via HTTP:// not as FILE:// so you will have to put it on a WAMP server or something.

[DefinitelyMaybe]

would be interested to hear how this turns out. perhaps re-open the issue?

[that-ben]

A week later, bamp?

[Mugen87]

I've checked this issue on my iMac and the app runs smooth with both three.js versions. However, the mentioned warning is a DirectX warning and hence it's not surprising that I'm unable to reproduce.

According to https://bugs.chromium.org/p/chromium/issues/detail?id=765576#c26, the warning will sooner or later disappear. You might want to wait a couple of days (or until the Chromium issue is marked as resolved) and then test with Chrome Canary again.

[that-ben]

I will. Thanks. Should I also wait until three.js r117 or r118 comes out or does that not matter at all?

[Mugen87]

No, that does not matter. For now, just keep an eye on the Chromium bug.

BTW: If you star the issue, you will receive a mail when it gets updated.

[mrdoob]

https://bugs.chromium.org/p/chromium/issues/detail?id=765576 seems to have been fixed. I think it should land in Chrome 84?

[that-ben]

Well, that's good news. But what about Firefox :P

[Mugen87]

https://bugs.chromium.org/p/chromium/issues/detail?id=765576 seems to have been fixed.

Wow, that was quick!

But what about Firefox :P

It's a fix in ANGLE so this will also be fixed in Firefox.

[archerl84]

I still see this warning in Firefox and Chrome - http://prntscr.com/t2o5kp

[that-ben]

Yes, 77.0.1 (64-bit)

[Mugen87]

I guess it will take one or two more month (maybe even longer) until this patch lands in production.

[that-ben]

In the meantime, for anybody coming here in regards to making this work under Firefox, remember that THREE.JS version r111 does not invoke this bug and still is great to use (that's what I currently use) as a compromise.

[Mugen87]

As long as the browser console is closed, the additional logged warnings should not affect the functionality or performance of a three.js app. I think you can safely ignore them...

[that-ben]

Oh it does and the constant lag spikes are painful. From SOLID 60fps in r111 (capped; probably more) to 9fps in r116

[Mugen87]

Do you see this performance regression with the official three.js examples, too? The problem in your app might be caused by something different...

[that-ben]

You do know (see main post) that it does that on every THREE.JS revision as far back as r112 ? THAT MUCH changed between r111 and r112 that would invoke the X3571 notice and catastrophically drop framerate from solid 60fps (capped!) to 9fps? Keep in mind that all I do is comment the r111 three.js file inclusion and uncomment the r112 three.js one. There is zero code change, it's the same app.

PS: Please specify a good target THREE.JS example for testing. I'll download the code do the tests and report back here.

[Mugen87]

Sorry, I did not want to say you are making something wrong in your app. But things in the renderer have changed in the last releases and maybe a missing migration task is responsible for the performance issue.

Do you see a difference in performance with this example:

r111: webgl_animation_skinning_blending r117: webgl_animation_skinning_blending

[that-ben]

Oh wow, even r111 throws multiple X3571 in your example link! But performance wise, it's so tiny of an app that both run at a solid 60fps, but it's so small... I have a 600$ graphics card and a 4ghz 8-core CPU with 32GB of RAM, so I'm not surprised that both examples (r111 and r117) run at full fps. My app is much, much more demanding than this THREE.JS example.

[mrdoob]

Can you share a link to your app?

[that-ben]

You mean other than the test case I linked above on May, 2nd?

[mrdoob]

[that-ben]

@Mugen87 Perhaps you could re-upload the ZIP for @mrdoob since you downloaded and tested it 2 months ago? I don't have it anymore, sorry. I thought you would download it within a month. Either way, I'll re-test once Firefox update comes in. Perhaps performance will be normal then.

[Mugen87]

Sorry, I've already deleted the files...

[Space4ARDev]

My project are running on Microsoft Edge 44.17763.1.0. I have been struggling about the message: THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(67,25-83): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them It makes to confuse for user and developer. What way to fix?

[mrdoob]

My project are running on Microsoft Edge 44.17763.1.0.

The current version of Microsoft Edge is 84.0.522.40.