OpenGL reqs status, planning

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

OpenGL reqs status, planning

#1 Post by Dilvish »

A recent user support request that wound up appearing related to our OpenGL reqs got me looking at them a bit more, and it seems there is some murkiness around the topic, worth some discussion and clarification and perhaps some planning for the future.

FO needs 2.0 or 2.1, for what?
Our Wiki Reqs page and a check in HumanClient.cpp say FO needs OpenGL 2,0 for best performance and may be able to get by with OpenGL 1.5, but our Readme.md says FO requires OpenGL 2.1. That latter req seems first introduced in PR 1457, though I don't find any actual discussion of the OpenGL req. Marcel, do you recall (or does anyone else know) what prompted that increase from 2.0 to 2.1?

Appendix J of the OpenGL_2.1 specs describes the differences between OpenGL 2.0 and OpenGL 2.1. Glancing briefly over that I see a number of changes to (or at least new options for) texture handling, and at least one change to pushing and popping attributes as being among the more likely possibilities for us, but nothing I clearly recognize as an issue for us.

If the HumanClient finds OpenGL less than 2.0, it tries disabling a few things, and perhaps we could do a bit more on that front?

To help deal with that sort of thing better in the future, it seems it might be worthwhile to start adding some extra comments/doc infor for GG methods that directly use OpenGL calls, noting which version they require and why.

Also, in my brief reading on this right now, it sounds like OpenGL 3.3+ provides quite a bit better performance than OpenGL 2.0/2.1, but that even if we want to keep supporting OpenGL 2.0/2.1 it should be possible to write most or all of the Open 2.0 code to use the 2/0/3.3 intersection in ways compatible with the OpenGL3.3+ coding guidelines so that we can more easily let people with better cards get better performance from that.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: OpenGL reqs status, planning

#2 Post by adrian_broher »

Wiki
The wiki isn't maintained and is not bound to a software version and therefor useless as any reference.
What prompted that increase from 2.0 to 2.1?
Me being sick of people japping about the game not working on their valuable Intel Isomenumber integrated graphic card in the PC they have bought 15 years ago. OpenGL 2.1 is a more than reasonable baseline (Release 2006), making features available as core specification that should be considered standard today (shaders, buffers of all kind) and gives still more leverage than I would consider useful in terms of backward compatibility.
If the HumanClient finds OpenGL less than 2.0, it tries disabling a few things, and perhaps we could do a bit more on that front?
In other words you're volunteering to support +10 year old graphic hardware that was already crap at that time?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: OpenGL reqs status, planning

#3 Post by Vezzra »

adrian_broher wrote:In other words you're volunteering to support +10 year old graphic hardware that was already crap at that time?
Well, if that could be achieved by adding just a few lines of code, why not? The question with issues/requests like this is how much effort would be required. If it takes one dev half an hour and makes 10 people with ancient crappy hardware happy, I think it's worth it.

However, in this particular case I guess it's unlikely to be so simple. If supporting OpenGL versions prior to 2.1 means adding (and maintaining!) extra code scattered throughout GG (checking the provided OpenGL version and based on that enabling and disabling sets of features, and probably executing different code sections?), I don't think it's worth it. Of course, if someone absolutely wants to put their time into this, by all means, go ahead. (But even then I'd still keep the official requirements for OpenGL 2.1, and just "silently" provide that extra support older OpenGL versions in the code.)

What's far more pressing are those issues with OpenGL and Intel Integrated Graphics which are reported frequently, even for more recent hardware (unless I misunderstood those reports). I don't know if there is anything we can do to work around what, if I understand correctly, is abysmal Windows driver support for OpenGL on that hardware. However, given how widespread that combination is (Windows on Intel Integrated Graphics), if there is anything we could do, we should at least try...?

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OpenGL reqs status, planning

#4 Post by Dilvish »

adrian_broher wrote:The wiki isn't maintained and is not bound to a software version and therefor useless as any reference.
The wiki may not be well maintained, but I and others certainly try to maintain it, particularly regarding compile/build instructions and requirements. As best I can make out, you are suggesting we ignore the wiki and/or intentionally leave inaccurate information there based on some theory that the wiki inherently just doesn't matter. Neither of those really make sense to me, and in your last big rewrite of the README you even added a reference to the wiki compile instructions rather than incorporate them all into the README, so your response here is pretty puzzling to me.
adrian_broher wrote:
What prompted that increase from 2.0 to 2.1?
Me being sick of people japping about the game not working on their... PC they have bought 15 years ago. OpenGL 2.1 is a more than reasonable baseline (Release 2006), making features available as core specification that should be considered standard today (shaders, buffers of all kind)...
2.1 added PixelBuffers, which I don't find us currently using, and it did advance which version of the Shader Language was supported, but it's not like it was the introduction of shaders and I haven't seen anyone assert we use any such v1.2 Shader Language changes. So, it's sounding like you upped the stated req from 2.0 to 2.1 mostly to try scaring off people with marginal hardware because they are a much higher risk of being a support headache? And perhaps you wanted to preemptively clear the way for actual reliance on 2.1 without needing a further review/discussion? I could maybe see that being within the range of reasonable decisions at least for the main README, especially since (apparently, based on my recent reading) some of those marginal cards that only report support for OpenGL 2.0 will sometimes not actually fully support it. But then I think the README should at least then point to the wiki page discussing the issue a bit and noting that at least some cards supporting OpenGL 2.0 may be sufficient to run FO. The people who are the biggest support headaches are the ones who won't be scared off anyways because they won't bother reading any of those things before asking for help. For the folks who do read at least a little, we should probably add a troubleshooting section to the README where we tell Windows users to run dxdiag to check what OpenGL version they have.
Vezzra wrote:
adrian_broher wrote:In other words you're volunteering to support +10 year old graphic hardware that was already crap at that time?
Well, if that could be achieved by adding just a few lines of code, why not?... However, in this particular case I guess it's unlikely to be so simple. If supporting OpenGL versions prior to 2.1 means adding (and maintaining!) extra code scattered throughout GG (checking the provided OpenGL version and based on that enabling and disabling sets of features, and probably executing different code sections?), I don't think it's worth it.
Please note, the bit about keeping track of which GG methods rely on which release of OpenGL was not only related to supporting old hardware, and I don't think it would need to touch every GG method. It was sounding to me like there are performance benefits to structuring the OpenGL code to be compliant with OpenGL 3.3 coding structure guidelines (and avoiding certain 2.1 features), even if we limited ourselves to the intersection of 2.0/2.1 and 3.3. (Perhaps the folks doing recent changes to FO's OpenGL use have already thinking about this and doing a lot of that, for all I know.) And in some places we might want to provide alternate execution paths if OpenGL 3.3+ is supported by the player's card.

Perhaps we are at a point where graphics performance on non-ancient cards is too minor an aspect of our overall performance for it to be worth looking at OpenGL 3.3, but I thought it worth at least a little thinking and discussion.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: OpenGL reqs status, planning

#5 Post by adrian_broher »

Dilvish wrote:The people who are the biggest support headaches are the ones who won't be scared off anyways because they won't bother reading any of those things before asking for help.
Your hardware is insufficient, go away.
And the headache is gone.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

dbenage-cx
Programmer
Posts: 389
Joined: Sun Feb 14, 2016 12:08 am

Re: OpenGL reqs status, planning

#6 Post by dbenage-cx »

Are sRBG textures different from sRBG color profile?
I could not determine from reading linked spec and history summary.
New calls are not used, at least directly, question is if EXT_texture_sRGB provides support for images using sRBG color profile, or if an "sRGB texture" is a different beast.
if 2.1 is not required, possibly all of the 2.0 uses are in ShaderProgram? If so, could add an option to disable/use some alternate and add it to render-simple flag.

Gating features from reported extensions might be a better approach, compared to relying only on the reported OpenGL version and expecting all extensions.
A lower version driver that provides some newer extensions would default a feature to enabled.
Drivers reporting an OpenGL version as 2.0, but lacking GL_ARB_multisample would default a feature to disabled.
0AD has a nice capability report from a couple of years ago.
Might prove helpful in highlighting extensions that were not as well supported at that time (I've not found any comparable mappings of extensions for various drivers)
Dilvish wrote:the intersection of 2.0/2.1 and 3.3
Certainly sounds reasonable in theory. Might also help prevent issues if a new driver does not fully test some 3.0 deprecated feature.

Post Reply