GNOME's Mutter Drops Legacy OpenGL Driver Support

[illwieckz]

There is a confusion in that merge topic, from the guy who merged the merge request, based on a misread of a Phoronix article:

In fact, older Intel only expose GLES 2.0 and had their partially software emulated GL 2.1/2.0 support dropped: https://www.phoronix.com/news/OpenGL...15-Now-Default

That Phoronix post doesn't say the support is dropped, but that the default exposed version dropped from 2.1 to 1.4, which has not the same meaning at all.

The GL 2 support for this hardware is not dropped at all, it is disabled by default to workaround applications that don't implement any check to prefer their own software renderer if that's faster.

To say it otherwise, because Google Chrome didn't implemented any check to select their faster code, Mesa disabled the feature by default for every applications to force the specific Google Chrome application to fallback on their faster code.

The support is still there and shipped. Applications needing GL 2.1/2.0 can request it at run time this way:

https://github.com/DaemonEngine/Daem...74cf23e7f32701

[Berniyh]

Vulkan doesn't magically improve performance for a compositor. The newer low-level APIs like Vulkan excel when you do many small draws. Compositors are the opposite of that - they do very few large draws.

No, performance really isn't a reason to do this, if even very old chips can render the desktop.

There are however some other points that could be relevant.
1. Vulkan reduces the CPU overhead, so theoretically, it could improve the power efficiency, which could be helpful on mobile devices.
2. It's easier to do multi-threading of the CPU part. Again, could help with power efficiency, theoretically.
3. The driver part is much slimmer, which means less driver-specific bugs, less application-specific workarounds etc.

As I noted, I don't know if there is really a measurable benefit of 1&2 and I don't know if they will actually implement multithreading for the rendering part anyways.
Point 3 however is already an advantage that we do see in games at least.

[mangeek]

No, performance really isn't a reason to do this, if even very old chips can render the desktop.

There are however some other points that could be relevant.
1. Vulkan reduces the CPU overhead, so theoretically, it could improve the power efficiency, which could be helpful on mobile devices.
2. It's easier to do multi-threading of the CPU part. Again, could help with power efficiency, theoretically.
3. The driver part is much slimmer, which means less driver-specific bugs, less application-specific workarounds etc.

As I noted, I don't know if there is really a measurable benefit of 1&2 and I don't know if they will actually implement multithreading for the rendering part anyways.
Point 3 however is already an advantage that we do see in games at least.

Adding a 4th advantage: Similar to #3, there's a strategic advantage to targeting Vulkan. Imagine a future where vendors prioritize (or maybe ONLY develop) a Vulkan driver. Zink would satisfy the OpenGL needs. If you can get the full stack targeting Vulkan, you open the path for faster and easier driver development for hardware. I can certainly imagine, for instance, a future Raspberry Pi or other similar platform where the vendor determines that going Vulkan-only with their driver makes the most sense. Just look at how much effort has gone into v3d and imagine if it was all able to go to v3dv from the start.

[mangeek]

Is there anything you've noticed broken? I set that globally on Fedora 37 earlier today and everything seems fine

The first time I tried it, when Ubuntu 22.04 came out, a bunch of apps had artifacts or the windows would be awfully garbled. Notably, Epiphany Browser was a glitchfest, which meant I couldn't use a WiFi captive portal. This round though, still on 22.04 (with Ubuntu OEM kernel 6.1), things are fine.

[brent]

No, performance really isn't a reason to do this, if even very old chips can render the desktop.

There are however some other points that could be relevant.
1. Vulkan reduces the CPU overhead, so theoretically, it could improve the power efficiency, which could be helpful on mobile devices.
2. It's easier to do multi-threading of the CPU part. Again, could help with power efficiency, theoretically.
3. The driver part is much slimmer, which means less driver-specific bugs, less application-specific workarounds etc.

1. Lower CPU overhead implies performance improvements - but that really doesn't apply here. Like I said, compositors do few big draws, pretty simple draws with few state changes most of the time. These have very low CPU overhead anyway, and there is not much there which could be saved.

2. It doesn't matter since you don't need this for a compositor because of point 1.

3. On the other hand, a compositor only excercises a small part of the OpenGL driver. Also, this just means the complexity is moved inside the compositor, so more bugs can happen there.

You really can't compare a compositor with modern video games, please don't try to.

[Berniyh]

1. Lower CPU overhead implies performance improvements - but that really doesn't apply here. Like I said, compositors do few big draws, pretty simple draws with few state changes most of the time. These have very low CPU overhead anyway, and there is not much there which could be saved.

Sure, but the performance improvement is not relevant, as was mentioned. Your actual argument is that the overhead of the OpenGL rendering part is already low.
That's fair enough. As I said in my post, the gain is a theoretical one. A don't know if it'll make any difference at all in e.g. the energy consumption.
We'll see how this develops, because the Vulkan rendering parts are coming. wlroots has it already implemented, kwin will implement it in version 6 and mutter surely will also do it at some point.
Once a proper comparison can be made there e.g. with regard to the energy consumption, I'm eager to see whether it's measurable or not.
And if it's not measurable, then at least you know that you have a good implementation of OpenGL, at least from that perspective.

3. On the other hand, a compositor only excercises a small part of the OpenGL driver. Also, this just means the complexity is moved inside the compositor, so more bugs can happen there.

You really can't compare a compositor with modern video games, please don't try to.

I'm not trying to compare it to a video game. I just noted that this effect takes already place there.
And it's not like there never were quirks with OpenGL drivers in the past. That happened every once in a while and I'd expect it to happen less often with Vulkan.

[sinepgib]

Sure, but the performance improvement is not relevant, as was mentioned. Your actual argument is that the overhead of the OpenGL rendering part is already low.
That's fair enough. As I said in my post, the gain is a theoretical one. A don't know if it'll make any difference at all in e.g. the energy consumption.
We'll see how this develops, because the Vulkan rendering parts are coming. wlroots has it already implemented, kwin will implement it in version 6 and mutter surely will also do it at some point.
Once a proper comparison can be made there e.g. with regard to the energy consumption, I'm eager to see whether it's measurable or not.
And if it's not measurable, then at least you know that you have a good implementation of OpenGL, at least from that perspective.

I'm not trying to compare it to a video game. I just noted that this effect takes already place there.
And it's not like there never were quirks with OpenGL drivers in the past. That happened every once in a while and I'd expect it to happen less often with Vulkan.

I think before even making a comparison (which requires the hard work of witing a new backend) it makes sense to profile what's the biggest power draw in a "typical" system. You should, most of the time, focus on the biggest bottleneck first. If the WM only consumes 1% of your energy compared to things like Electron, optimizing it more doesn't really save you anything significant.

[Berniyh]

I think before even making a comparison (which requires the hard work of witing a new backend) it makes sense to profile what's the biggest power draw in a "typical" system. You should, most of the time, focus on the biggest bottleneck first. If the WM only consumes 1% of your energy compared to things like Electron, optimizing it more doesn't really save you anything significant.

True, which is surely the reason why it hasn't been a priority so far. But as noted above, it'll be done eventually and then such a comparison will be interesting.

[sinepgib]

True, which is surely the reason why it hasn't been a priority so far. But as noted above, it'll be done eventually and then such a comparison will be interesting.

Yeah, I mean, I'm not against it. Devs are free to use their time in whatever they (or their employer) wants, and I enjoy shiny new things just as much as the next geek, so if they already plan to do it for whatever reason it is very much welcome.

[MorrisS.]

I hope that Gnome 45 will switch to vulkan as default render.