2

As far as I know, Wayland is not using OpenGL but OpenGL ES for 3D rendering, usually used on embedded systems (except for Intel IGPs). In the long term, I read that OpenGL support would be implemented but was not a priority for now.

I guess it is because OpenGL ES is somewhat simpler but it does not seems like a strong point for making such a choice.

I was wondering what were the reasons for this decision, and what were (and would be, for the future of Linux) the consequences of this choice.

Update:

The Wayland FAQ was my fist stop before even thinking about asking it here. Feel free to correct me if I am wrong, but the last part seems, at least, not very clear, IMHO:

EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X.

As far as I understand, it's not that simple. EGL is an interface between GLs such as OpenGL and OpenGL ES. OpenGL ES calls are possible directly through Wayland/Weston while OpenGL support needs XWayland.

GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL.

So, this part refers to what I was saying above and, as far as I know, Wayland development team does not want to take that alternative route. So, for now, people willing to ports their applications which does not make direct use of Wayland/Weston are forced to translate their OpenGL API calls to OpenGL ES ones.

A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so Weston uses OpenGL ES to render.

This seems understandable, on a short-time basis, at least. Still, on the long run, Wayland devlopment team wants to add OpenGL APIs as well, so it seems more like a workaround for now to me, until things get serious. This is one of the sentences which triggered my question here in the first place.

As detailed above, clients are however free to use whichever rendering API they like.

If I am not mistaken, which means going for XWayland for OpenGL applications and Weston OpenGL ES, which seems to be a bigger deal that what the sentence implies, especially when it comes to 3D rendering, not to mention the fact that Wayland/Weston aim to replace Xorg.

For the record::

XWayland is a series of patches over the X.Org server codebase that implement an X server running upon the Wayland protocol. The patches are developed and maintained by the Wayland developers for compatibility with X11 applications during the transition to Wayland,[28] and was mainlined in version 1.16 of the X.Org Server in 2014.When a user runs an X application from within Weston, it calls upon XWayland to service the request.

N.B.: I am trying to learn more about Wayland/Weston, especially when it comes to (3D) rendering, but exact information on this subject is diffcult to find, especially because it seems that the only people really X11-savvy seem to be Wayland developers.

As far as I can tell so far, for OpenGL:

  • if OpenGL function calls are made through GLX interface, it falls back to XWayland, so the programme is (really) not using Wayland.

Addendum

It might seems that the discussion is out of the scope of the original question but it is actually linked to underlying OpenGL interfaces/libraries and it is difficult to separate all of this from the original question.

As it seems to be a complicated and confusing subject, here are some various links and quotes which lead me to think that OpenGL (not ES) is not really supported by Wayland per se, but falls back to X11, through XWayland:

What does EGL do in the Wayland stack

The Wayland server in the diagram is Weston with the DRM backend. The server > does its rendering using GL ES 2, which it initialises by calling EGL.

Hacker News comments

Wayland is actually pretty stable. Nvidia has problem with OpenGL in Xwayland (i.e. 3d accel for x11 apps), otherwise, it should work. There are warts though, when using Wayland. When using scaling (doesn't have to be fractional, either), X11 apps are being upscaled, not downscaled, resulting in blurriness. Unfortunately, neither Firefox nor Chrome does support Wayland natively, and who wants to use their most used app on their computer in blurry mode?

How come GLX-based applications can be run on Wayland on Ubuntu?

So based on the link @genpfault provided:

So based on the link @genpfault provided:

  • XWayland is a part of XOrg that's providing an X server on top of Wayland. Any application that's linked against X11 libs and running under Wayland will automatically use XWayland as its backend. So the GLX part of XWayland is the mechanism that allows GLX-based OpenGL applications to run on Wayland.
  • Not being able to use MSAA in GLX-based applications seems to be a known bug of XWayland, at least for Intel and AMD GPUs (cf. https://bugs.freedesktop.org/show_bug.cgi?id=98272 ). But I couldn't find any additional information on the matter.
  • @sourcejedi I was not clear I guess. It's not contradictory if you read "direct use" as "without using XWayland". – Paradox Apr 8 at 13:21
  • I think this is relevant: stackoverflow.com/a/10187032/799204 and "OpenGL is enabled by default" at mesa3d.org/egl.html . I am guessing Mesa EGL supports EGL_OPENGL_API, because I don't know why it wouldn't. – sourcejedi Apr 8 at 13:42
  • So I searched "wayland opengl egl" - that did it. Anyone care to write it up as a proper answer? The result was reddit.com/r/opengl/comments/7whgo0/opengl_context_in_wayland/… – sourcejedi Apr 8 at 14:15
  • @source jedi Sorry, I already saw/read all of these. But they do not answer the question. Or I missed really something when reading. Again, I do not see where there is any proof there is no lack of support of "classic" OpenGL, which leads to use XWayland. But again, my bad if I am missing something. Since 2014, the documentation and information are pretty dry and scarse, apart from bug fixing announcements, some distributions/DE making use of Wayland by default and users being mad for some reasons. Not to mention the phase where people were (are?) taking sides regarding Mir/Wayland/X11. – Paradox Apr 8 at 17:47
  • That is a buildable code example, and "it worked perfectly on my Debian Stable machine in X using the weston compositor from the repos". I am not sure what more you could want! – sourcejedi Apr 8 at 20:58
2

From https://wayland.freedesktop.org/faq.html:

Why does Wayland use EGL?

EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X. GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL.

A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so Weston uses OpenGL ES to render. This also enables Weston to run on GPUs which don't support the full OpenGL API.

As detailed above, clients are however free to use whichever rendering API they like.

  • Could you elaborate, please? I updated my question to mention that I already read this piece of documentation but I tried to address what was not clear about it. – Paradox Apr 8 at 12:21
  • 'What is the drawing API? "Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer.' – Johan Myréen Apr 8 at 18:05
  • Thanks but I already knew that. The problem is when you take a look at how Wayland handles EGL calls there seems to have a discrepancy between the APIs: AFAIK, OpenGL ES function calls are handled "natively" by Wayland, while "classic" OpenGL function calls fall back to X11 compatibility layer and therefore XWayland. Which leads me to think either OpenGL support is not coming to Wayland and has not come yet, which is my question. But, if I'm wrong or missing something, I'd like to see evidence of that. – Paradox Apr 9 at 16:48
0

Web search [wayland opengl egl]: "Worked perfectly on my Debian Stable machine in X using the weston compositor from the repos".

Since you apparently haven't had five minutes to run these commands yourself yet

$ git clone https://github.com/eyelash/tutorials/
cloning into 'tutorials'...
remote: Enumerating objects: 88, done.
remote: Total 88 (delta 0), reused 0 (delta 0), pack-reused 88
Unpacking objects: 100% (88/88), done.
$ cd tutorials
$ gcc -o wayland-egl wayland-egl.c -lwayland-client -lwayland-egl -lEGL -lGL

$ ./wayland-egl & # a green square appears! $ ss --unix -a -p | grep wayland-egl u_str ESTAB 0 0 * 3920430 * 3921234 users:(("wayland-egl",pid=3260,fd=3)) $ ss --unix -a -p | grep 3921234 u_str ESTAB 0 0 /run/user/1001/wayland-0 3921234 * 3920430 users:(("gnome-shell",pid=2271,fd=100),("gnome-shell",pid=2271,fd=20)) u_str ESTAB 0 0 * 3920430 * 3921234 users:(("wayland-egl",pid=3260,fd=3))

This code is using Wayland protocol to share its rendering buffer with the compositor, gnome-shell. And rendering using OpenGL. There is absolutely no way this program is running using the XWayland server process, X11 protocol, or the OpenGL ES (GLES) API. I do not see how there can be any doubt here.

For contrast:

$ glxgears >/dev/null 2>&1 & # spinning gears appear! $ ss --unix -a -p | grep glxgears u_str ESTAB 0 0 * 3924917 * 3922619 users:(("glxgears",pid=3310,fd=3)) $ ss --unix -a -p | grep 3922619 u_str ESTAB 0 0 * 3924917 * 3922619 users:(("glxgears",pid=3310,fd=3)) u_str ESTAB 0 0 @/tmp/.X11-unix/X0 3922619 * 3924917 users:(("Xwayland",pid=2307,fd=14))

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.