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 any 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.