OpenGL on Ubuntu on WSL 2 timeline

WSL
1

I’m teaching a course in which students write an OpenGL game using C and C++. For the past few years, students running Windows had to install a convoluted toolchain using MinGW and MSYS2. We’d like to move to Ubuntu on WSL completely, but the OpenGL support of WSL 1 is too poor.

So my question is what the timeline is for OpenGL support on WSL 2. Is this something which would be usable by September or should we prepare for another year of fighting with MSYS2?

3 Likes
2

I suspect the answer is “wait until MS reveals more information” about their GUI support on WSL2. You can get OpenGL working via X11 if you export the environment variable LIBGL_ALWAYS_INDIRECT in the WSL2 and have a suitable X11 on your Windows-side, although this is limited to OpenGL 1.5 (IIRC) which is likely not helpful for your students who I imagine will be wanting much more recent capabilities (the supported OpenGL via Indirect GLX is decades old now).

1 Like
3

We don’t have a firm date for OpenGL support unfortunately. I do not think it will make it in time for class this semester.

OpenGL support will be dependent on work being done to optimize OpenGL over DirectX. That is being done by Microsoft and Collabora.

There is a progress update from Callabora on their blog here.

The workaround Dan may work for you, with the limitations he specified.

2 Likes
4

Yeah, from our testing, the indirect OpenGL support also seems to be broken for a number of GPU’s. Moreover, we often get better performance using the llvmpipe CPU renderer…

I did learn a lot about Mesa and OpenGL in the process of debugging all this, so that was nice :blush:

1 Like
5

@matlock

Has there been more progress on getting OpenGL to WSL 2? We’re starting a new semester in a few weeks so we want to re-evaluate our setup.

6

Yes, there is progress. We hope to land Mesa 21 in a pre-release Hirsuite build in WSL Community Preview sometime in February or March.

Mesa 21.0 Merges Initial Direct3D 12 Support For WSL - Phoronix

1 Like
7

@merlijn-sebrechts

Hi, I’ve been following your discussion, and realised some things:

You’re telling using msys2 is a fight. I’m wondering why, if you’re using it only for compiling. If you really find WSL2 to be more usable (which I find too), you can very much use it for everything except compiling (and debugging). I don’t know why you are saying the MSYS2 toolchain is convoluted. For me, it was pretty much installing msys2, pacman -S the packages needed and that’s it.

You mentionned indirect rendering with GLX has poor support for recent OpenGL, and that’s it’s often broken. On my machine, it’s indeed broken if I use WGL. But you can very much use normal rendering using LLVMpipe, as you said, and that one support the latest version of OpenGL. (on my machine, on WSL2, LLVMpipe support OpenGL 4.5).

If LLVMpipe give you high enough performances, you can do everything on WSL2. If you find that performances are too poor, you can always compile from MSYS2 and have native support. I don’t know what you’ll be doing with OpenGL, but if it’s just an intro, chances are CPU rendering will have good enough performances.

8

Some of our issues with MSYS2/MINGW64

  • ASAN is not supported
  • GDB can’t pause while the application is running and it doesn’t accept new breakpoints. You can only add breakpoints while the program is paused or before you start it.
  • MSYS2 has had multiple breaking changes throughout the past years. Take a look at the News Section for examples of how users had to manually run commands to fix their MSYS2 installation. Moreover, during the start of the previous semester, the servers were down for a few days.
  • Installing MSYS2 requires you to update the base install multiple times in a specific order. Do it wrong and you bork your install.
  • When students don’t use the defaults of the MSYS2 installer, the build toolchain can fail.
  • Finding the right combination of Windows installers + MSYS2 packages to get your setup working is difficult. Do you use Windows git or MSYS2 git? Which CMake do you use? Which version of the curses library do you use? What combinations work isn’t even consistent; the results are different depending on how you run your application, what other tools are already installed on the Windows system, and how those are configured.
  • No official VSCode integration.
  • When you update MSYS2 in the wrong order or with the wrong command, it can delete pacman itself requiring you to reinstall MSYS2.

A lot of these issues are fixed by a lot of testing, writing perfect docs, and forcing students to follow our docs to the letter. The downside of this approach is that, once the students graduate, they experience all of the issues we do.

On some computers, LLVMpipe works well enough. On other computers it doesn’t work. We haven’t found a configuration that works on every computer. What gives good performance on one computer works badly on another. Helping students find the right config to get the performance they need is very time consuming. I don’t think this is an issue with LLVMpipe itself. I think it’s the combination of LLVMpipe, X11 forwarding to Windows, and the xorg server on Windows.

tl;dr Having 100 students install a setup on their own computers and use it for an entire semester is a great way to find out how robust something is :wink:

9

Thank you very much for your insights. Finding a solution that works everywhere is indeed very different from finding a personnal solution that will break with the slightest change.

I have strangely encountered none of the problems you listed. I have installed on several different machines and never found a way to broke the installation. But I guess 100 students are way more clever to find strange ways to break things than I’ll ever be. I agree with git and msys2 mix being a little bit cumbersome. Strangely, git depend on msys2, but installing both is always a clunky. I’ve always found that everything works better if I do everything from msys2, which is anyway general simpler than downloading 100 standalone package installers. But I guess it’s again too much expectation from students.

I guess using the default windows toolchain (Visual Studio with Visual C++ compiler and debugger) would be even more time consuming, and would require you to tell them how to write OS independent code, which is something I have very little experience with. Or have you considered it?

I would add that I wait with much impatience full native OpenGL support on WSL2, which will hopefully making all those things trivial.

10

When I started teaching the course, we used Visual Studio with VC++ but had a bunch of issues with it too.

  • Installation is very cumbersome too. First install Visual Studio, then run a different setup wizard to enable features, then run a project config wizard to enable those features in your project, then run the installer for the library, then go through a dozen config windows to add that library to your project etc… Compared to sudo snap install code; sudo apt install g++ sdl2-dev, everything is cumbersome :wink:
  • Random crashes and lockups, sometimes even requiring a Windows restart. Almost every exam we had at least one student who completely locked up their computer. Once everything was set up, VSCode + MinGW was much more stable and responsive.
  • non-free. Even though students can get a Visual Studio license from the university, they would lose this access once they graduate. Then they would either have to pay up or learn a different toolchain. I think it’s ethically questionable to lock your students into paid solutions.
  • Windows-only. This was a big factor for me. Students on Mac and Linux were forced to use a Windows VM or to dual-boot in order to follow the course. Moreover, given that a big part of the teaching staff uses Linux, it was also a pain to help students debug and to test their submissions.

Though there is a big conditional on supporting multiple platforms: if we support multiple platforms, then every platform needs to use the exact same compiler for a couple of reasons.

  • Before covid, the exams had to be done on Windows PC’s in the uni. So students who practice on Ubuntu would still need to make their exams on Windows. If the error messages are different, then those students would be at a disadvantage.
  • When testing student project submissions, we don’t want to have to constantly switch platforms, so the code has to work on every platform, even if the student makes a mistake. While we also teach how to write cross-platform code, it is not the main focus of the course.

GCC is the only compiler which can be used on every platform. Clang on Windows actually uses VC++ as backend, making it a very different experience from clang on Mac and Linux. We hoped MSYS2 would solve all our issues, but it also has a lot of downsides stated above. So I’m also impatiently waiting for WSL’s OpenGL support. Until that time, students on Windows will get an Ubuntu VM to program in.

I think winget + MinGW will also be a better experience than MSYS2, but then you still have the issues of GCC and GDB on Windows not supporting the full featureset. ASAN makes it so much easier to learn to program in C and C++.

11

@merlijn-sebrechts

I don’t know if you are aware but there finally is support for OpenGL in WSL2 : https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps

I don’t know how robust it is to integrate to a class.