# Simplified python wheel for VTK
**URL:** https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329
**Category:** Development
**Created:** [July 30, 2024, 10:44pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329 "2024-07-30T22:44:33Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [July 30, 2024, 10:44pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/1 "2024-07-30T22:44:33Z")
The vtk wheel from [pypi](https://pypi.org/project/vtk/) does not work on a machine that has a GPU without a display connected. A common problem is when people use trame with VTK/ParaView for remote rendering and run their server process in a cloud machine that provisions a GPU without any screen. Sometimes, the GPUs themselves do not even have ports to plug in a monitor. In these scenarios, VTK could be more adaptable by falling back to a suitable OpenGL context backend at runtime.
In order for VTK to use the GPU, users are asked to uninstall the `vtk` wheel and install another “vtk-egl”:
```sh
pip install "vtk-egl" --extra-index-url https://wheels.vtk.org
```
I did some research into why vtk-egl is not distributed in pypi. I think the reason has to do with being unable to bundle `libEGL.so` along with vtk wheel in pypi because `libEGL` is part of the linux graphics driver stack and comes with nvidia. I think pypi also doesn’t allow bundling arbitrary shared libraries in the wheel and all libs must be built from source. We could distribute mesa’s libEGL but that’s not great for nvidia gpus.
If I can adapt VTK to not link with libEGL at compile time, there wouldn’t be a need to have an entirely separate wheel. Imagine running a single command `pip install vtk`, on your laptop or in the cloud and VTK will automatically use X when it can open a display or EGL when a display is not available.
As I started looking deeper into this, the first problem was that the existing OpenGL/Context loader in VTK `glew` could not handle both EGL and GLX in the same build (issue [vtk/vtk#18547](https://gitlab.kitware.com/vtk/vtk/-/issues/18547))
@meak worked on that issue for a while and he came up with a nice solution. Michael changed VTK to use `glad2` instead of `glew`. [glad2](https://gen.glad.sh/) is a neat tool that generates custom OpenGL/Vulkan/WGL/EGL/GLX dynamic loaders. I’ve worked with glad in the past and liked the simplicity of it.
I’ve picked up @meak’s commits from [https://gitlab.kitware.com/michael.migliore/vtk/-/commit/cea5e2cd7c938c7770151fbafee2823857f8322d](https://gitlab.kitware.com/michael.migliore/vtk/-/commit/cea5e2cd7c938c7770151fbafee2823857f8322d) and made few more changes in my [use-glad](https://gitlab.kitware.com/jaswant.panchumarti/vtk/-/commits/use-glad) branch that extend the dynamic loading for glx and opengl as well.
Here, I’m emulating a headless machine by running the vtkProbeOpenGLVersion executable inside a docker container with/without an X display or GPU and it seems to do the right thing.
1. **No X display and no GPU**
2. **X display without GPU**
3. **GPU without X display**
4. Finally, **with a GPU and X display** (this is the most common usecase on a PC)
Many unit tests pass with EGL, so I’m close to creating an MR.
1. Is it a good idea to remove the `VTK_OPENGL_HAS_EGL` build setting? It does not make sense anymore because VTK will no longer rely on find\_package(OpenGL) to discover EGL at compile time. Can we remove it and act as if EGL always exists?
2. Can the Utility target `VTK::opengl` also be removed? All it’s targets are now dynamically discovered, except OSMesa. that should be trivial to implement.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [July 30, 2024, 10:51pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/2 "2024-07-30T22:51:35Z")
Having a different wheel for EGL also caused awkward packaging scripts for downstream packages that want to rely on the `vtk` wheel from pypi.
Some conda environments may not be able to pull in a wheel from a site specified in `--extra-index-url`. In those cases, the only solution was to build VTK from source.
---
### Author:  [@oyster](https://discourse.vtk.org/u/oyster)
#### Post date: [July 31, 2024, 11:55pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/3 "2024-07-31T23:55:10Z")
Awsome work. A couple days ago, we had to buy a RTX for our windows server.
---
### Author:  [@meak](https://discourse.vtk.org/u/meak)
#### Post date: [August 1, 2024, 6:41am UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/4 "2024-08-01T06:41:01Z")
I’m _glad_ someone is taking it over 🤭
Thanks @jaswantp!
---
### Author:  [@estan](https://discourse.vtk.org/u/estan)
#### Post date: [August 2, 2024, 1:33pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/5 "2024-08-02T13:33:52Z")
Just want to say great work. All the scenarios you enumerate have their use cases. I’ve used three of them, and having it just work ™ will be awesome.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [August 2, 2024, 1:59pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/6 "2024-08-02T13:59:04Z")
Nice! Which is the one you haven’t used? Just curious
---
### Author:  [@Edoardo\_Pasca](https://discourse.vtk.org/u/Edoardo_Pasca)
#### Post date: [August 6, 2024, 6:49am UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/7 "2024-08-06T06:49:31Z")
I recently stumbled upon the same problem, see [Core dumped on examples VTK Simple cone Remote Rendering · Issue #570 · Kitware/trame · GitHub](https://github.com/Kitware/trame/issues/570)
Additionally, every now and again vtk would instantiate an X instead of the EGL render window and it all crashed.
I had to pip remove/install vtk and vtk-egl a few times before it was somehow stable, but this may be a problem with the environment.
However it would be better if at the system would exit with an error rather than crash, but it seems you nailed it! Thanks.
---
### Author:  [@hakostra](https://discourse.vtk.org/u/hakostra)
#### Post date: [August 6, 2024, 5:56pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/8 "2024-08-06T17:56:22Z")
What about pure software rendering mode through OSMesa? Would that also work? That is an important use case (and why there is also vtk-osmesa wheels available).
Great work!
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [August 6, 2024, 6:02pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/9 "2024-08-06T18:02:54Z")
> What about pure software rendering mode through OSMesa? Would that also work?
Yes, OSMesa will be tried when VTK can’t find EGL. It can be forced with an environment variable too.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [August 8, 2024, 1:27pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/10 "2024-08-08T13:27:46Z")
Afaik, recent release of libegl support CPU software rendering, making osmesa a not so important usecase imo.
---
### Author:  [@hakostra](https://discourse.vtk.org/u/hakostra)
#### Post date: [August 8, 2024, 1:34pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/11 "2024-08-08T13:34:51Z")
That is very interesting, thanks for letting me know.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [August 8, 2024, 2:09pm UTC](https://discourse.vtk.org/t/simplified-python-wheel-for-vtk/14329/12 "2024-08-08T14:09:47Z")
Correct, osmesa is not really needed.