Drop support for earlier OpenGL versions

[VReaperV]

OpenGL 3.3 is already 15 years old, there's no point targeting hardware that's even older. It's not like anyone is playing on such hardware anyway, so it's just a burden on development and maintenance.

[illwieckz]

Most recent GMA Gen 5 is Intel GMA X4700MHD and was released in October of 2008, which means new devices making use of it were still launched maybe even years after that, this also means the last items of those devices were sold brand new even more years after that, and that finally means those devices entered the second-hand market more years after that.

For example the Thinkpad W500 was sold from 2008 to 2010 (when it was replaced by the W510), meaning professional refurbishers continued to receive W500 to refurbish from corporate dumps up to 2013 (when those companies replace their systems after 3 years), with refurbishers selling them for years after that, meaning it was likely common to find some refurbished W500 to buy from professional resellers with warranty in 2016. For other generic second-hand market like ebay and consumer-to-consumer sales, this lasted even more. The same can be said for the T500 and the x301, those kind of computers were big sellers. While the W500 had switchable graphics with some radeon, some T500 didn't have switchable graphics and no x301 had switchable graphics, only relying on the Intel GMA (X)4500MHD. Those device are also very appreciated by Linux users. The T500 and X301 even are devices of choice for running coreboot.

Note: the reported OpenGL version on TechPowerUp is not the one supported on Linux which is higher.

Actually GMA Gen 3, 4 and 5 are running OpenGL 2.1 on Linux and Dæmon 0.55.2 is expected to be able to run Unvanquished 0.55.2 on them.

In 2021 I got a report from someone from the LanPower association who was trying to run Unvanquished on a Gen 3. LanPower is a French non-profit association that organizes some open-source gaming events on refurbished computers with families in French rural areas.

At the time of that report the Gen 3 wasn't supported that's why I worked on that support. Gen 4 and Gen 5 were already supported by the engine.

It's also very common that drivers for chips found on ARM boards first deliver a functional OpenGL 2.1 on Linux before delivering an higher version years after that, as 2.1 is usually the base line for desktop compositors like GNOME Shell (making sure they don't fallback on CPU-based llvmpipe and start accelerating the render for real).

[VReaperV]

Most recent GMA Gen 5 is Intel GMA X4700MHD and was released in October of 2008, which means new devices making use of it were still launched maybe even years after that, this also means the last items of those devices were sold brand new even more years after that, and that finally means those devices entered the second-hand market more years after that.

For example the Thinkpad W500 was sold from 2008 to 2010 (when it was replaced by the W510), meaning professional refurbishers continued to receive W500 to refurbish from corporate dumps up to 2013 (when those companies replace their systems after 3 years), with refurbishers selling them for years after that, meaning it was likely common to find some refurbished W500 to buy from professional resellers with warranty in 2016. For other generic second-hand market like ebay and consumer-to-consumer sales, this lasted even more. The same can be said for the T500 and the x301, those kind of computers were big sellers. While the W500 had switchable graphics with some radeon, some T500 didn't have switchable graphics and no x301 had switchable graphics, only relying on the Intel GMA (X)4500MHD. Those device are also very appreciated by Linux users. The T500 and X301 even are devices of choice for running coreboot.

That's all decade+ old stuff. And I don't really see the connection with coreboot?

Actually GMA Gen 3, 4 and 5 are running OpenGL 2.1 on Linux and Dæmon 0.55.2 is expected to be able to run Unvanquished 0.55.2 on them.

In 2021 I got a report from someone from the LanPower association who was trying to run Unvanquished on a Gen 3. LanPower is a French non-profit association that organizes some open-source gaming events on refurbished computers with families in French rural areas.

Something tells me that nobody else in those 4 years has tried that.

It's also very common that drivers for chips found on ARM boards first deliver a functional OpenGL 2.1 on Linux before delivering an higher version years after that, as 2.1 is usually the base line for desktop compositors like GNOME Shell (making sure they don't fallback on CPU-based llvmpipe and start accelerating the render for real).

ARM only implements OpenGL ES, I don't think you should even be able to run OpenGL on them.

[illwieckz]

That's all decade+ old stuff.

That's not uncommon on Linux. This very month I answered to someone who responded to a post about GNOME Shell getting better performance out of triple buffering, this guy was hoping this would help his dad's computer to perform better (his dad's computer still running a GMA Gen 3 in 2025)

And I don't really see the connection with coreboot?

The connection is that some people actually look for such devices on purpose for various reasons (coreboot being one reason like that, and people wanting their firmware to be free may want their games to be free too).

Something tells me that nobody else in those 4 years has tried that.

That's possible, but who really knows? At least I tried myself. I have a Gen 3 in some place, and a Gen 4 at home (it was my fallback laptop until this year).

ARM only implements OpenGL ES, I don't think you should even be able to run OpenGL on them.

I mean the usual chips we find on Arm boards, like Broadcom, Mali, etc. Things you find on Raspberry Pi, Orange Pi, Banana Pi and other fruitful boards. Mesa implements Desktop OpenGL for them. And in general Mesa is good at implementing Desktop OpenGL 2.1 on devices not purposed for it. Actually yes, most of those chips only get proprietary OpenGL ES at release, but then Mesa comes and implement OpenGL 2.1 as fast as possible and later bump the version as far as they can. This is now changing as now Mesa is now shifting to implementing Vulkan as fast as possible and rely on zink for OpenGL.

But the last time I got an OpenGL 2.1 by Mesa from a stock distribution on an newly released Arm board I just bought brand new was in the last couples of years.

[VReaperV]

That's not uncommon on Linux. This very month I answered to someone who responded to a post about GNOME Shell getting better performance out of triple buffering, this guy was hoping this would help his dad's computer to perform better (his dad's computer still running a GMA Gen 3 in 2025)

Well, he's not playing Unvanquished, is he?

The connection is that some people actually look for such devices on purpose for various reasons (coreboot being one reason like that, and people wanting their firmware to be free may want their games to be free too).

Is there something stopping coreboot from working on newer devices?

That's possible, but who really knows? At least I tried myself. I have a Gen 3 in some place, and a Gen 4 at home (it was my fallback laptop until this year).

We haven't had reports of anyone trying to run that, right?

I mean the usual chips we find on Arm boards, like Broadcom, Mali, etc. Things you find on Raspberry Pi, Orange Pi, Banana Pi and other fruitful boards. Mesa implements Desktop OpenGL for them. And in general Mesa is good at implementing Desktop OpenGL 2.1 on devices not purposed for it. Actually yes, most of those chips only get proprietary OpenGL ES at release, but then Mesa comes and implement OpenGL 2.1 as fast as possible and later bump the version as far as they can. This is now changing as now Mesa is now shifting to implementing Vulkan as fast as possible and rely on zink for OpenGL.

But the last time I got an OpenGL 2.1 by Mesa from a stock distribution on an newly released Arm board I just bought brand new was in the last couples of years.

So then that's not an issue as Mesa presumably implements at least 3.3 anyway? Especially if they're implementing Vulkan now instead.

[illwieckz]

Well, he's not playing Unvanquished, is he?

This is just another example of how such hardware is still used today. I would like to extend our user base so I'm also considering what people who don't play Unvanquished are currently using as main computer.

We haven't had reports of anyone trying to run that, right?

I even myself didn't reported it when Unvanquished dropped the rendering code that was the only one that was performant enough at the time for a GMA Gen 4 when all I had was a GMA Gen 4… So I wouldn't assume that a lack of report is a lack of usage if even myself did not reported it when Unvanquished made my only computer unable to run the game properly…

In fact I'm aware that GL 2.1 support had been broken after the 0.55.2 release and I know it from before this thread was started, but I haven't reported it myself yet.

So then that's not an issue as Mesa presumably implements at least 3.3 anyway? Especially if they're implementing Vulkan now instead.

We are indeed at some turning point. I'm not saying that GL 2.1 isn't phasing out.

My main point is that except some obvious crap on the market, computers are very robust. So people keep them long time.

As an example, the GMA Gen 3 I have access to belongs to some of my family. This computer is “the computer of the house” in that house, and these years I have seen it used for gaming in holidays to play games like SuperTuxKart in improvised family parties (with some people being there for holidays joining with their laptop). People did that all by themselves, this was not my own initiative, and they even played without me before I was there myself. In those improvised SuperTuxKart games the computer running the GMA Gen 3 was used by some teenager in age for playing Unvanquished.

Now, if what I want for Unvanquished is to reach the same size of user base a game like SuperTuxKart has, then I should expect such use case to be found.

Actually this is very similar to that LanPower stuff, I never met them, but I know they organized public events with free games including SuperTuxKart, and I know they asked me for compatibility with Unvanquished on their machines that were likely running SuperTuxKart in their events. I would be surprised if my family and them were the only ones attempting to run free games on low-end computers like that. And as reported, I know random others still run such kind of computers today, that's still a market I want to reach. In fact for people having such computers, free games like ours are mostly the only ones they can get.

I know such old computers are actually used for playing games, and I know this from multiple experiences, so I know “It's not like any is playing on such hardware anyway“ isn't true. Now, “It's not like any is playing Unvanquished on such hardware anyway“ may bring a different answer as statistically the population that can play Unvanquished on such hardware is indeed smaller than the population that can play any game on such hardware.

Also, I know this sounds a lot like some “sunk cost fallacy”, but we finally reached that complete compatibility with all those GL 2.1 cards I can think of with 0.55, it feels weird to drop that with 0.56 and even drop what was already working before that…

[DolceTriade]

While supporting the widest range of hardware is desirable, I think we need to balance it with the maintenance burden of having to support it with minimal players... Just people people happen to exist with such hardware doesn't mean that they can run and play the game meaningfully.

[slipher]

It's nice for supporting lower-end hardware than other games to be a unique selling point of Unvanquished. We can't win if we compete directly against well-funded commercial titles in having the best graphics.

[VReaperV]

There's a huge gap between what commercial games require and ancient hardware that hardly anyone uses anymore (let alone for games).

[illwieckz]

Quote from:

• renderer: add non-bitwise alternative for u_Color and u_ColorModulateColorGen #1570

I don't mind if we use bitwise operations and uint in any feature that is not part of low and lowest presets.

So I ported the u_Color and u_ColorModulate code to emulate both uint and bitwise operations on GLSL 1.20.

I don't plan to do this for any other code that is not required by low and lowest presets. If it happens a not-low* preset uses uint or bitwise operations we can disable the feature on GLSL 1.20.

That also means that any feature from some advanced rendering code path (like the bindless one) can rely on uint and bitwise operations as much as we want.

We can assume the same for any non-GL 2.1 feature that is required by a non-low* preset: we can require an higher version and eventually disable the feature on GL 2.1.

For example it's OK to make deluxemapping GL 3+, and to not care about GL 2.1 ifdef in material system.

[VReaperV]

Well, that's an example of said maintenance burden with no clear benefit.

[VReaperV]

We can assume the same for any non-GL 2.1 feature that is required by a non-low* preset: we can require an higher version and eventually disable the feature on GL 2.1.

For example it's OK to make deluxemapping GL 3+, and to not care about GL 2.1 ifdef in material system.

@illwieckz What about dynamic lights?

[illwieckz]

@illwieckz What about dynamic lights?

Our tiled dynamic light renderer currently requires something greater than GL 2.1 (bitwise, UBO…).

I found interest in the forwardLighting renderer for gameplay realtime lights versus cosmetic realtime lights. We don't have that distinction implemented, but the idea is that some lights may be required for some gameplay elements, like the flashlight in Doom 3, or some lights used to paint captured zones, while others are purely cosmetic (fire light, weapon projectiles…).

I thought that for only rendering a couple of gameplay dynamic lights, like a flashlight, or lighting the room you're in, a less optimal but more compatible renderer would do the job, and would be usable on low-end devices. That's why I investigated the forwardLighting renderer and fixed it, I fixed it on that purpose for making possible to use lights as gameplay elements.

Now, if we do that (keep the forwardLighting renderer for gameplay elements), we can likely NUKE a lot of code from it. First we can NUKE everything from the forwardLighting renderer that is not expected to be used on low-end devices, especially the multitexture stuff (normal mapping, etc.). We can also NUKE the code unused for gameplay dynamic lights, for example I assume one of the forwardLighting variant is for some map global sun lighting, we never used that, we can NUKE it.

If there are remaining dynamic shadow code in the forwardLighting renderer, we can NUKE that as well.

Now, we can also declare that games using the Dæmon engine and implementing lights as gameplay elements would have 3.1 as minimal spec, while other games would have 2.1 as minimal spec.

On the other hand, that forwardLighting renderer works. I would like to know some example of burden coming from it being kept.

On one hand we lived with it for years while it was broken, and it wasn't a big deal to have it around. On the other hand we did not do the deep engine rewrites you are currently doing. I did deep rewrites like the GLSL shader mutualizing code, but I did not write a new rendering path, so maybe I can't really feel that burden.

I also wonder what would be the burden of it once it has been stripped down.

[VReaperV]

I found interest in the forwardLighting renderer for gameplay realtime lights versus cosmetic realtime lights. We don't have that distonction implemented, but the idea is that some lights may be required for some gameplay elements, like the flashlight in Doom 3, or some lights used to paint captured zones, while others are purely cosmetic (fire light, weapon projectiles…).

It is a good idea to have those, yes.

On the other hand, that forwardLighting renderer works. I would like to know some example of burden coming from it being kept.

Any change that affects shaders in general. #insert, colorGen change to uint, recent shader build rework, etc, all of that has to take these shaders into account. And issues like #1238 crop up with them as well. Any changes to GLShader, uniforms, various associated calls etc. always require changes in all of the forwardLighting*, shadowFill, debugShadowMap usages.

On top of that there's a ton of stuff on the cpp side that is only used by the forwardLighting renderer. So oftentimes when making a substantial change I have to go through a lot of code to figure out if something's only used by the forwardLighting renderer and not the tiled one and can be ignored. Right now I was doing some changes to how draw commands are created from BSP surfaces, and how the surfaces are sorted, and I had to look through a bunch of places to find out that interactionBits and lightCount are really only used by forwardLighting renderer. There's also a massive amount of code associated with it that does not seem to be working at all, like the shadow stuff.

I thought that for only rendering a couple of gameplay dynamic lights, like a flashlight, or lighting the room you're in, a less optimal but more compatible renderer would do the job, and would be usable on low-end devices. That's why I investigated the forwardLighting renderer and fixed it, I fixed it on that purpose for making possible to use lights as gameplay elements.

An alternative is to to only process those dynamic lights and skip lighttile for them.

[illwieckz]

Wait, it is actually possible with our code base to process dynamic lights without the forwardLighting renderer, while not using the lighttile shader?

[VReaperV]

Wait, it is actually possible with our code base to process dynamic lights without the forwardLighting renderer, while not using the lighttile shader?

Yes, just upload it into the u_LightTiles texture directly.

[illwieckz]

Hmm, I never understood that part,

• what does the lighttile shader do actually?
• do skipping the lighttile shader also skips the fetchIdxs() and nextIdx() calls?

[VReaperV]

• what does the lighttile shader do actually?

Puts lights into u_LightTiles based on which tiles they affect and the depth buffer depth at that tile.

do skipping the lighttile shader also skips the fetchIdxs() and nextIdx() calls?

No, but those are just texture fetches.