Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interactive training - OpenGL issue #66

Closed
Leotinoooo opened this issue Nov 3, 2022 · 4 comments
Closed

Interactive training - OpenGL issue #66

Leotinoooo opened this issue Nov 3, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@Leotinoooo
Copy link

Hello,

Thanks for the great work!
I ran into an issue that is actually very similar to #13. But this issue was closed, and it seems that some other people still have the same problem. Because I'm running on WSL2 (see below), and the previous one was closed, I opened a second issue.

Setup

I'm using WSL2 with Ubuntu 20.04 on my machine, with an RTX 3080 (Driver version 511.65, CUDA version 11.6).

Method

  • I used your Dockerfile to build the Wisp Docker image.
  • I'm running the container by forwarding the DISPLAY environment variable and using VcxSrv as my X server.
  • I confirmed that interactive windows could be rendered, using the glxgears demo from mesa-utils.

Issue

Running the interactive training leads to this issue:

Traceback (most recent call last):
  File "/wisp/app/main_interactive.py", line 12, in <module>
    setup_cuda_context()     # Must be called before any torch operations take place
  File "/wisp/app/cuda_guard.py", line 29, in setup_cuda_context
    window = app.Window(width=10, height=10, title='dummy', visible=False)
  File "/opt/conda/lib/python3.9/site-packages/glumpy/app/__init__.py", line 188, in __new__
    window = __backend__.Window(*args, **kwargs)
  File "/opt/conda/lib/python3.9/site-packages/glumpy/app/window/backends/backend_glfw_imgui.py", line 248, in __init__
    self.imguiRenderer = GlfwRenderer(self._native_window, attach_callbacks=False)
  File "/opt/conda/lib/python3.9/site-packages/imgui/integrations/glfw.py", line 13, in __init__
    super(GlfwRenderer, self).__init__()
  File "/opt/conda/lib/python3.9/site-packages/imgui/integrations/opengl.py", line 60, in __init__
    super(ProgrammablePipelineRenderer, self).__init__()
  File "/opt/conda/lib/python3.9/site-packages/imgui/integrations/base.py", line 17, in __init__
    self._create_device_objects()
  File "/opt/conda/lib/python3.9/site-packages/imgui/integrations/opengl.py", line 108, in _create_device_objects
    self._attrib_location_tex = gl.glGetUniformLocation(self._shader_handle, "Texture")
  File "src/latebind.pyx", line 51, in OpenGL_accelerate.latebind.Curry.__call__
  File "/opt/conda/lib/python3.9/site-packages/OpenGL/GL/VERSION/GL_2_0.py", line 430, in glGetUniformLocation
    return baseOperation( program, name )
  File "/opt/conda/lib/python3.9/site-packages/OpenGL/platform/baseplatform.py", line 415, in __call__
    return self( *args, **named )
  File "src/errorchecker.pyx", line 58, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError
OpenGL.error.GLError: GLError(
        err = 1282,
        baseOperation = glGetUniformLocation,
        cArguments = (1, b'Texture\x00'),
        result = -1
)

Even simpler, running app-simple.py from the glumpy example, with the additional line app.use("glfw_imgui") reaches the same OpenGL error. Maybe I should directly open an issue on the glumpy repository, but other kaolin-wisp users might face the same issue.
If you have time to provide some help on this, it would be awesome!

@tovacinni
Copy link
Collaborator

Hi thanks for your interest in wisp!

I don't have a super good idea what might be happening, but I've faced this same issue before on an (unrelated glumpy app I made) on OSX. Specifically, app.use("glfw") seems to work for me but not app.use("glfw_imgui") so there is some discrepancy between those two... and also seems like a glumpy issue.

If you do open an issue on the glumpy repo, it would be awesome if you can link the issue here so anyone looking for the issue with wisp can find it :D

@tovacinni tovacinni added the bug Something isn't working label Nov 3, 2022
@Leotinoooo
Copy link
Author

@tovacinni Thanks for your answer! I'm running additional tests on my side and I will open an issue on the glumpy repo, I'll link it here.

@orperel
Copy link
Collaborator

orperel commented Jan 17, 2023

Closing for now, seems as glumpy provided a solution

@orperel orperel closed this as completed Jan 17, 2023
@orperel
Copy link
Collaborator

orperel commented Feb 6, 2023

As of #117 wisp sets the default GL version to 3.3, and it's also configurable via WispState's renderer.gl_version field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants