moderngl / glcontext Goto Github PK

The standalone EGL backend looks great for hardware-accelerated 3D rendering on headless Linux servers. For software rendering, it could be useful to have an osmesa backend which allows software rendering without an X server running.

Admittedly, headless software rendering from python isn't the most popular setup, but is useful for things like reinforcement learning environments such as https://gym.openai.com/envs/CarRacing-v0/ where you want to render pixels, but often on a remote linux machine, and sometimes without a GPU available (on that machine).

For reference, here's glfw's osmesa context: https://github.com/glfw/glfw/blob/master/src/osmesa_context.c

How do you guys feel about an osmesa backend?

I have a sneaking suspicion glcontext might have a different behavior when it comes to requesting an opengl verison. In moderngl 5 users normaly omitted this info. We pass 330 as default value. This version number is set in the context parameters.

Will there be any issues when a context version is created as 330 when the user wanted the highest context? Is there any difference between window and standalone in this area?

Currently the x11 crashes in share mode.

Fixing this is not a blocker for releasing glcontext 2.0 or moderngl 5.6.

This is the case on linux at least. libGL.so vs libGL.1.* are the common it seems.

Maybe we should try those two alternatives if no glversion was passed in?

Is there any example code showing how to use your glcontext package? I am unsure how to extend ctx.load ('glViewport') shown in your test.py file. How would I later invoke the glViewport () command? Do I have to preload all the opengl commands?

https://github.com/moderngl/glcontext/blob/master/glcontext/headless.cpp#L7

Having a GL2PS backend could open up interesting possibilities, for print, PDF and SVG output

http://geuz.org/gl2ps/

Gnu Octave and VTK are two existing bits of software that can use GL2PS.

Currently the sole purpose of glcontext is to provide a Python object with a load(name: str) -> int method.

The long term plan is to rename the load method to load_opengl_function for three main reasons:

• to be more verbose about its purpose.
• to be less error-prone when the loader is actually not a loader object but anything else with its own load method.
• the most simple OpenGL backend could be a Python Extension or the Window itself, however it is unlikely that any of those two would keep a common name like load for this purpose.

To achieve the renaming the following will happen:

1. glcontext will have both load_opengl_function and load implemented.
2. newer versions of moderngl will prefer using load_opengl_function over load if present.
3. moderngl will pin a minimum glcontext version with load_opengl_function present.
4. glcontext will have the load method removed and major version incremented.

Point 3. and 4. will be far in the future.

Looks like we left a stinker in the x11 backend.

$ python examples/basic_colors_and_texture.py 
2019-11-14 11:52:33,468 - moderngl_window - INFO - Attempting to load window class: moderngl_window.context.pyglet.Window
Traceback (most recent call last):
  File "examples/basic_colors_and_texture.py", line 126, in <module>
    ColorsAndTexture.run()
  File "/home/einarf/Documents/projects/moderngl/moderngl/examples/ported/_example.py", line 21, in run
    mglw.run_window_config(cls)
  File "/home/einarf/Documents/projects/moderngl/moderngl/.venv/lib/python3.7/site-packages/moderngl_window/__init__.py", line 185, in run_window_config
    cursor=show_cursor if show_cursor is not None else True,
  File "/home/einarf/Documents/projects/moderngl/moderngl/.venv/lib/python3.7/site-packages/moderngl_window/context/pyglet/window.py", line 71, in __init__
    self.init_mgl_context()
  File "/home/einarf/Documents/projects/moderngl/moderngl/.venv/lib/python3.7/site-packages/moderngl_window/context/base/window.py", line 137, in init_mgl_context
    self._ctx = moderngl.create_context(require=self.gl_version_code)
  File "/home/einarf/Documents/projects/moderngl/moderngl/moderngl/context.py", line 1236, in create_context
    ctx.mglo, ctx.version_code = mgl.create_context(None, standalone, require)
  File "/home/einarf/Documents/projects/moderngl/moderngl/.venv/lib/python3.7/site-packages/glcontext/__init__.py", line 25, in <lambda>
    return lambda glversion: x11.create_context(mode=mode, glversion=glversion)
SystemError: More keyword list entries (4) than format specifiers (3)

* Building wheel...
running bdist_wheel
running build
running build_py
running build_ext
building 'glcontext.windowed' extension
cc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fPIC -I/usr/local/include/python3.9 -c glcontext/windowed.cpp -o build/temp.freebsd-13.1-STABLE-amd64-cpython-39/glcontext/windowed.o -fpermissive
glcontext/windowed.cpp:61:12: error: no matching function for call to 'PyLong_FromVoidPtr'
    return PyLong_FromVoidPtr(glXGetProcAddress((unsigned char *)name));
           ^~~~~~~~~~~~~~~~~~
/usr/local/include/python3.9/longobject.h:93:24: note: candidate function not viable: no known conversion from 'void (*)()' to 'void *' for 1st argument
PyAPI_FUNC(PyObject *) PyLong_FromVoidPtr(void *);
                       ^
1 error generated.
error: command '/usr/local/libexec/ccache/cc' failed with exit code 1

ERROR Backend subprocess exited when trying to invoke build_wheel

Python-3.9
FreeBSD 13.1

Building wheels manually is a pain. We can do this from the ci systems. Still some manual testing should be done before releasing of course.

• Build wheels for every platform on push (build test)
• When making a tagged release, build wheels and attach them to the release on github
• When making a tagged release upload the wheels to PyPI

This should make life easier..

There seems to be some instances of context creation fails on darwin. All i know is that it worked in moderngl 5.5.x and it doesn't using glcontext in 5.6. This needs to be investigated and fixed before we can release 5.6.

We have some versions with missing source distributions. This is an issue for people on aarch64

glcontext/egl.cpp:219:23: error: cannot initialize a variable of type 'EGLDeviceEXT *' (aka 'void **') with an rvalue of type 'void *'
        EGLDeviceEXT* devices = malloc(sizeof(EGLDeviceEXT) * num_devices);
                      ^         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Version: 2.3.7
Python-3.9
clang-14
FreeBSD 13.1

This can save people a lot of time:
moderngl/moderngl-window#68

It's a simple way for people to regain compatibility when upgrading from moderngl 5.5 to 5.6 without having to change their code.

libX11.so is not found on some Linux distribution. find_library() should be used to find the correct name.

More info here: abey79/vpype#200 (work-around probably good for any ModernGL-based project).

moderngl/moderngl#512

A testcase for this is egl.

Problem

On aarch64, pip install glcontext builds the wheels from source code and then installs it. It requires the user to have a development environment installed on their system. Also, it takes more time to build the wheels than downloading and extracting the wheels from PyPI.

Resolution

On aarch64, pip install glcontext should download the wheels from PyPI.

@einarf, Please let me know your interest in releasing aarch64 wheels. I can help with this.

This must be an easy fix, we have to replace

    from distutils.sysconfig import get_config_var
    from distutils.version import LooseVersion
    ```

Cannot install via pip, this error happens:

    glcontext/x11.cpp:480:21: error: cannot initialize a member subobject of type 'void *' with an lvalue of type 'void (GLContext *)'
          {Py_tp_dealloc, GLContext_dealloc},
                          ^~~~~~~~~~~~~~~~~

Someone reported that when installing Manim, they were compiling glcontext and they failed to because they were missing some headers, their config was Python 3.9.2 on amd64, QubesOS like Debian 11 testing, and I could see https://pypi.org/project/glcontext/#files that manylinux wheels for py39 are missing.

Might need to start thinking about Wayland. The backend should use EGL instead of X11.

XDG_SESSION_TYPE env var should™ contain "x11" or "wayland" making us able to select the right backend for linux.