You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code below is basically from the Open3D offscreen rendering example. It just creates a renderer, renders a torus, and deletes the renderer. Now if this code is run in the debugger, in a debug build, and only then, then the first "iteration" of creating the renderer & scene, rendering the image, and deleting the scene and renderer, works. But when it comes to creating the renderer again (either the second iteration of the loop, or as in the code below, just deleting the renderer & scene and creating a new renderer & scene in a separate variable, then that second call to app.RenderToImage(...) crashes with the OpenGL error posted below.
I suspect this problem hasn't been discovered before because first most people don't delete and re-create a renderer, but second of all, the bug is hard to reproduce in relwithdebinfo and/or release mode. In release and relwithdebinfo mode, the code appears to run fine, in fact it runs fine for a few thousand iterations - and then at some point there's an Exception thrown at 0x00007FFBE09349C3 (Open3D.dll) in main.exe: 0xC0000005: Access violation writing location 0x0000022800000000 - but there isn't an OpenGL error visible in the terminal. I suspect this is because the GL/glew release libraries don't output stuff in release mode, while the debug ones do. It is also interesting that in release/relwithdebinfo modes, the below example always crashes after the same number of iterations (2040).
It feels to me what's going on is that Open3D or Filament don't leave the OpenGL pipeline in a clean state and/or don't properly clean up after themselves - something like that.
It is possible that this bug is related to #7129, but I'm not sure.
FEngine (64 bits) created at 0000021032E3B080 (threading is enabled)
FEngine resolved backend: OpenGL
Intel, Intel(R) Iris(R) Xe Graphics, 4.1.0 - Build 32.0.101.6078, 4.10 - Build 32.0.101.6078
OS version: 0
Renderer: Commands High watermark 7 KiB (0%), 224 commands, 32 bytes/command
Renderer: Commands High watermark 0 KiB (0%), 0 commands, 32 bytes/command
OpenGL error 0x502 (GL_INVALID_OPERATION) in "bool __cdecl filament::TimerQueryNative::queryResultAvailable(struct filament::OpenGLDriver::GLTimerQuery *)" at line 58
Expected behavior
The example should work - no OpenGL error or exception.
Open3D, Python and System information
- Operating system: Windows 11, Visual Studio 2022, MSVC 14.42
- Open3D version: 0.19 (from yesterday)
- System architecture: x64
- Is this a remote workstation?: no
- How did you install Open3D?: Prebuilt release zip for Windows from this GitHub releases section
- Compiler version (if built from source): MSVC 14.42
Additional information
No response
The text was updated successfully, but these errors were encountered:
Checklist
main
branch).Describe the issue
The code below is basically from the Open3D offscreen rendering example. It just creates a renderer, renders a torus, and deletes the renderer. Now if this code is run in the debugger, in a debug build, and only then, then the first "iteration" of creating the renderer & scene, rendering the image, and deleting the scene and renderer, works. But when it comes to creating the renderer again (either the second iteration of the loop, or as in the code below, just deleting the renderer & scene and creating a new renderer & scene in a separate variable, then that second call to
app.RenderToImage(...)
crashes with the OpenGL error posted below.I suspect this problem hasn't been discovered before because first most people don't delete and re-create a renderer, but second of all, the bug is hard to reproduce in relwithdebinfo and/or release mode. In release and relwithdebinfo mode, the code appears to run fine, in fact it runs fine for a few thousand iterations - and then at some point there's an
Exception thrown at 0x00007FFBE09349C3 (Open3D.dll) in main.exe: 0xC0000005: Access violation writing location 0x0000022800000000
- but there isn't an OpenGL error visible in the terminal. I suspect this is because the GL/glew release libraries don't output stuff in release mode, while the debug ones do. It is also interesting that in release/relwithdebinfo modes, the below example always crashes after the same number of iterations (2040).It feels to me what's going on is that Open3D or Filament don't leave the OpenGL pipeline in a clean state and/or don't properly clean up after themselves - something like that.
It is possible that this bug is related to #7129, but I'm not sure.
Steps to reproduce the bug
Error message
FEngine (64 bits) created at 0000021032E3B080 (threading is enabled)
FEngine resolved backend: OpenGL
Intel, Intel(R) Iris(R) Xe Graphics, 4.1.0 - Build 32.0.101.6078, 4.10 - Build 32.0.101.6078
OS version: 0
Renderer: Commands High watermark 7 KiB (0%), 224 commands, 32 bytes/command
Renderer: Commands High watermark 0 KiB (0%), 0 commands, 32 bytes/command
OpenGL error 0x502 (GL_INVALID_OPERATION) in "bool __cdecl filament::TimerQueryNative::queryResultAvailable(struct filament::OpenGLDriver::GLTimerQuery *)" at line 58
Expected behavior
The example should work - no OpenGL error or exception.
Open3D, Python and System information
Additional information
No response
The text was updated successfully, but these errors were encountered: