three-gpu-pathtracer: All examples crash on Nvidia RTX 2080 Ti
Describe the bug
Any example just renders one frame, or mostly none at all, then freezes the browser for a 5-8 seconds, after which the WebGL context is lost.
Expected behavior
It shouldn’t crash 😄
Screenshots and Repro Model
The following WebGL error appears in the console. It’s similar for all examples.
three.module.js:18826 THREE.WebGLProgram: Program Info Log: C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(1289,1-6): warning X4000: use of potentially uninitialized variable (dyn_index_vec3_int)
error X8000: D3D11 Internal Compiler Error: Invalid Bytecode: Index Dimension 1 out of range (4263 specified, max allowed is 31) for operand #2 of opcode #4322 (counts are 1-based). Aborting.
error X8000: D3D11 Internal Compiler Error: Invalid Bytecode: Can't continue validation - aborting.
Warning: D3D shader compilation failed with default flags. (ps_5_0)
Retrying with skip validation
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(1289,1-6): warning X4000: use of potentially uninitialized variable (dyn_index_vec3_int)
error X8000: D3D11 Internal Compiler Error: Invalid Bytecode: Index Dimension 1 out of range (4263 specified, max allowed is 31) for operand #2 of opcode #4322 (counts are 1-based). Aborting.
error X8000: D3D11 Internal Compiler Error: Invalid Bytecode: Can't continue validation - aborting.
Warning: D3D shader compilation failed with skip validation flags. (ps_5_0)
Retrying with skip optimization
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(3420,10-36): warning X3577: value cannot be NaN, isnan() may not be necessary. /Gis may force isnan() to be performed
C:\fakepath(1289,1-6): warning X4000: use of potentially uninitialized variable (dyn_index_vec3_int)
C:\fakepath(1933,1): warning X4000: use of potentially uninitialized variable (f_intersectsRectangle)
C:\fakepath(1934,1): warning X4000: use of potentially uninitialized variable (f_intersectsRectangle)
C:\fakepath(1935,1): warning X4000: use of potentially uninitialized variable (f_intersectsRectangle)
C:\fakepath(1951,1): warning X4000: use of potentially uninitialized variable (f_intersectsCircle)
C:\fakepath(1952,1): warning X4000: use of potentially uninitialized variable (f_intersectsCircle)
C:\fakepath(2492,1): warning X4000: use of potentially uninitialized variable (f_envMapDirectionPdf)
C:\fakepath(2032,1): warning X4000: use of potentially uninitialized variable (f_ggxDistribution)
C:\fakepath(2143,1): warning X4000: use of potentially uninitialized variable (f_evalIridescence)
C:\fakepath(2270,1): warning X4000: use of potentially uninitialized variable (f_transmissionEval__SurfaceRec)
C:\fakepath(2032,1): warning X4000: use of potentially uninitialized variable (f_ggxDistribution)
C:\fakepath(1289,1-6): warning X4000: use of potentially uninitialized variable (dyn_index_vec3_int)
C:\fakepath(2032,1): warning X4000: use of potentially uninitialized variable (f_ggxDistribution)
C:\fakepath(2143,1): warning X4000: use of potentially uninitialized variable (f_evalIridescence)
C:\fakepath(2270,1): warning X4000: use of potentially uninitialized variable (f_transmissionEval__SurfaceRec)
C:\fakepath(2032,1): warning X4000: use of potentially uninitialized variable (f_ggxDistribution)
C:\fakepath(2492,1): warning X4000: use of potentially uninitialized variable (f_envMapDirectionPdf)
C:\fakepath(1289,1-6): warning X4000: use of potentially uninitialized variable (dyn_index_vec3_int)
C:\fakepath(2032,1): warning X4000: use of potentially uninitialized variable (f_ggxDistribution)
C:\fakepath(2143,1): warning X4000: use of potentially uninitialized variable (f_evalIridescence)
C:\fakepath(2270,1): warning X4000: use of potentially uninitialized variable (f_transmissionEval__SurfaceRec)
C:\fakepath(2032,1): warning X4000: use of potentially uninitialized variable (f_ggxDistribution)
After which (sorry, had to take a screenshot since the browser is unresponsive, so couldn’t copy-paste text):
Platform:
- Device: Desktop
- OS: Windows 11
- GPU: Nvidia RTX 2080 Ti
- Browser: Brave Version 1.46.140 Chromium: 108.0.5359.99 (Official Build) (64-bit)
- Three.js version: N/A (live examples from this repo)
- Library version: N/A (live examples from this repo)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (9 by maintainers)
The original issue is addressed - and the compilation delay is due to an already-reported Chrome issue so I’m going to close this for the moment.
I took some timing on my Windows 10 (Intel i7-7700k 4.20Ghz, RTX 2070 Super) machine with both the default D3D11 ANGLE backend and the OpenGL backend by changing the
chrome://flags#use-angleflag. These are the times it takes to run three.js’renderer.compileon a mesh with the path tracing shader. The shader was modified by adding an unused function between page refreshes to avoid cached shader usage after refresh. I suppose it might be expected but you can see nearly an order of magnitude improvement using the OpenGL backend compared to the default and it feels much better to use.Looking at the write up for the flag:
It would be nice to know how severely the the OpenGL backend can bloat memory and battery usage and whether it’s improved over the years.
ANGLE invokes Microsoft’s fxc shader compiler to compile the HLSL generated by ANGLE’s shader translator, which ingests GLSL. I suspect the huge slowdown is in fxc, which has known pathologies in shader compilation time in some situations.
A “Javascript and rendering” type trace from
about:tracingin Chrome would indicate more clearly whether the time’s spent in ANGLE or in fxc.Can you extract the path tracer’s shaders into separate text files, ideally with the translated HLSL gathered from the
WEBGL_debug_shadersextension? We can also try invoking fxc from the command line to see if it’s taking a long time on certain shaders.I can confirm the workaround has fixed the issue. Like @optimus007 said, it takes about 20-30 seconds for the initial render. After which, it runs smoothly.
@optimus007 Great, thanks!
The 20-30 second delay is concerning. I’m wondering if it’s due to the ANGLE shader conversion. @kenrussell any thoughts here? It takes significantly longer on windows than it does on my mac laptop, for example.
Yes it’s running! ,
one warning (screenshot) and It takes a good 20-30 seconds before the first path trace render frame is visible (just like v0.0.7), then it’s smooth
This should be fixed with a workaround from https://github.com/gkjohnson/three-gpu-pathtracer/pull/350, now. Can you give it a try?
reported in chrome (no feedback) and in bugs.chromium reply there with any additional context if required as I’m not familiar with this topic
They are both likely using the same ANGLE backend. I would appreciate it if someone can report it to chrome or some browser vendor so they can provide more insight on what good next steps are.