New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OpenGL 3 core context creation support #654

Closed
ecraven opened this Issue Jul 1, 2014 · 16 comments

Comments

Projects
None yet
8 participants
@ecraven

ecraven commented Jul 1, 2014

Add support for creating an OpenGL core context.

The default would still be a compatibility context, but there should be a way to create a core context, if explicitly wanted.
If you do this, you cannot use SFML Graphics (which still uses a compatibility context). It should be straightforward to add support for this (see for example http://en.sfml-dev.org/forums/index.php?topic=7903.msg53363#msg53363).

This gives users the option of using all the rest of SFML (save Graphics) and still get an OpenGL Core context.

@ecraven ecraven changed the title from Add OpenGL 3 core context support to Add OpenGL 3 core context creation support Jul 1, 2014

@zsbzsb

This comment has been minimized.

Show comment
Hide comment
@zsbzsb

zsbzsb Jul 1, 2014

Member

And the advantage to a core context over a compatibility context is what exactly? That deprecated functions will throw an error?

Member

zsbzsb commented Jul 1, 2014

And the advantage to a core context over a compatibility context is what exactly? That deprecated functions will throw an error?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jul 1, 2014

Member

Yes, as stated in the linked forum post.

Member

LaurentGomila commented Jul 1, 2014

Yes, as stated in the linked forum post.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Jul 1, 2014

Member

Essentially not a problem of OpenGL or SFML, but some drivers don't support compatibility context. For example Mesa on Linux requires you to have a core profile of at least 3.1 to get access to 3.3 features etc.
I think core profiles won't "harm" SFML and as such it would be a nice addition to the people that really need/want it. Of course this will also call for all the people that fail to understand that the graphics module would still require a compatibility context, meaning we'd get more stupid posts about this.

Member

eXpl0it3r commented Jul 1, 2014

Essentially not a problem of OpenGL or SFML, but some drivers don't support compatibility context. For example Mesa on Linux requires you to have a core profile of at least 3.1 to get access to 3.3 features etc.
I think core profiles won't "harm" SFML and as such it would be a nice addition to the people that really need/want it. Of course this will also call for all the people that fail to understand that the graphics module would still require a compatibility context, meaning we'd get more stupid posts about this.

@ecraven

This comment has been minimized.

Show comment
Hide comment
@ecraven

ecraven Jul 1, 2014

eXpl0it3r: SFML Graphics would just have to check whether it is running under a core context, and if it does, print a prominent error and exit.
The point is, if the default is compatibility, not core, this should really only happen if users on purpose enable core, and then they should know what they are doing.

zsbzsb: for example on mac os x 10.7, it seems you cannot get an opengl 3 compatibility context, only a core one. right now, this is the only one, but the common consensus seems to be (to me) that the way forward with opengl is core contexts.

ecraven commented Jul 1, 2014

eXpl0it3r: SFML Graphics would just have to check whether it is running under a core context, and if it does, print a prominent error and exit.
The point is, if the default is compatibility, not core, this should really only happen if users on purpose enable core, and then they should know what they are doing.

zsbzsb: for example on mac os x 10.7, it seems you cannot get an opengl 3 compatibility context, only a core one. right now, this is the only one, but the common consensus seems to be (to me) that the way forward with opengl is core contexts.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Jul 1, 2014

Member

Nobody is denying that SFML will make use of core-only rendering in the future (on capable platforms), and I can agree that having an option to request the only kind of core context available on OS X at the moment makes sense. The question is, how and more importantly when will it be implemented.

Obviously as mentioned, checks have to be put in place everywhere in the graphics module, so I think the biggest portion of the required code for this feature is not even context related at all. That is less than 100 lines of code, whereas the checks in graphics will make up more than that if we are to be thorough. But as eXpl0it3r already said, Murphy's law is going to get us again, and there will probably be really dim people who like to mess with settings they don't understand 😉.

Member

binary1248 commented Jul 1, 2014

Nobody is denying that SFML will make use of core-only rendering in the future (on capable platforms), and I can agree that having an option to request the only kind of core context available on OS X at the moment makes sense. The question is, how and more importantly when will it be implemented.

Obviously as mentioned, checks have to be put in place everywhere in the graphics module, so I think the biggest portion of the required code for this feature is not even context related at all. That is less than 100 lines of code, whereas the checks in graphics will make up more than that if we are to be thorough. But as eXpl0it3r already said, Murphy's law is going to get us again, and there will probably be really dim people who like to mess with settings they don't understand 😉.

@zsbzsb

This comment has been minimized.

Show comment
Hide comment
@zsbzsb

zsbzsb Jul 1, 2014

Member

Yes, as stated in the linked forum post.

All I got from the linked post was that the OP wanted deprecated functions to throw an error as a way to force use of modern GL functions.

but some drivers don't support compatibility context. For example Mesa on Linux requires you to have a core profile of at least 3.1 to get access to 3.3 features etc.

for example on mac os x 10.7, it seems you cannot get an opengl 3 compatibility context, only a core one.

Well none of this is stated in the forum post, that is why I asked. Just adding this because someone wants errors thrown at them doesn't justify a change like this in my eyes. But, I have no issues with adding the ability to get core contexts into the window module as long as there is legitimate reasons.

Member

zsbzsb commented Jul 1, 2014

Yes, as stated in the linked forum post.

All I got from the linked post was that the OP wanted deprecated functions to throw an error as a way to force use of modern GL functions.

but some drivers don't support compatibility context. For example Mesa on Linux requires you to have a core profile of at least 3.1 to get access to 3.3 features etc.

for example on mac os x 10.7, it seems you cannot get an opengl 3 compatibility context, only a core one.

Well none of this is stated in the forum post, that is why I asked. Just adding this because someone wants errors thrown at them doesn't justify a change like this in my eyes. But, I have no issues with adding the ability to get core contexts into the window module as long as there is legitimate reasons.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Jul 1, 2014

Member

All I got from the linked post was that the OP wanted deprecated functions to throw an error as a way to force use of modern GL functions.

Therein lies the thinking error. Just because an error is thrown, does not mean it was because you called a legacy function. One way or the other, you will still have to resort to documentation to understand why the error was thrown. GL_INVALID_OPERATION existed long before deprecation was introduced into OpenGL so I don't think "it will throw an error so I know it is deprecated" counts as a valid reason for me. If you are really keen on writing clean, modern GL code, go read up on the ideas behind the new model. It isn't too complex. Once you understand it, you will intuitively know what might or might not be deprecated and won't have to rely on trial and error with a core context.

Member

binary1248 commented Jul 1, 2014

All I got from the linked post was that the OP wanted deprecated functions to throw an error as a way to force use of modern GL functions.

Therein lies the thinking error. Just because an error is thrown, does not mean it was because you called a legacy function. One way or the other, you will still have to resort to documentation to understand why the error was thrown. GL_INVALID_OPERATION existed long before deprecation was introduced into OpenGL so I don't think "it will throw an error so I know it is deprecated" counts as a valid reason for me. If you are really keen on writing clean, modern GL code, go read up on the ideas behind the new model. It isn't too complex. Once you understand it, you will intuitively know what might or might not be deprecated and won't have to rely on trial and error with a core context.

@ecraven

This comment has been minimized.

Show comment
Hide comment
@ecraven

ecraven Jul 1, 2014

Indeed, but the only way to be sure you write valid core profile code is to actually use a core profile.

Could we possibly move the discussion a bit more towards feasibility and effort, and away from necessity? I think most arguments on why one would want or not want a core context have been mentioned, the question that remains is, how hard would it be to provide one, and which parts of SFML would be influenced by this.

ecraven commented Jul 1, 2014

Indeed, but the only way to be sure you write valid core profile code is to actually use a core profile.

Could we possibly move the discussion a bit more towards feasibility and effort, and away from necessity? I think most arguments on why one would want or not want a core context have been mentioned, the question that remains is, how hard would it be to provide one, and which parts of SFML would be influenced by this.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Jul 1, 2014

Member

the only way to be sure you write valid core profile code is to actually use a core profile.

This is not necessarily true. I use SFML for context management and I also stick to core functionality even with a compatibility context. I rely on external tools (such as CodeXL or the defunct gDEBugger) to inform me of things that are done inefficiently, wrong etc. This includes calls to deprecated functionality. Because of this, I can be truly sure that I am restricting myself to the core API, even with a compatibility context. It isn't the responsibility of the API to make sure that you stick to a specific model. As it's name suggests, the API is just the interface between your code and the driver. The reason why it throws GL_INVALID_OPERATION is not because it sees that it is deprecated, but because the operation is invalid in the current state you call it in. There is currently no mechanism to "warn" the developer of deprecated functionality. GL_INVALID_OPERATION can result from many other things as well that are not deprecation related, so I strongly suggest to use an external tool to do GL debugging. There are more and more of them showing up these days because programmers have recognized the need to verify that they aren't doing something dumb, and any serious GL programmer should always have one at hand.

Member

binary1248 commented Jul 1, 2014

the only way to be sure you write valid core profile code is to actually use a core profile.

This is not necessarily true. I use SFML for context management and I also stick to core functionality even with a compatibility context. I rely on external tools (such as CodeXL or the defunct gDEBugger) to inform me of things that are done inefficiently, wrong etc. This includes calls to deprecated functionality. Because of this, I can be truly sure that I am restricting myself to the core API, even with a compatibility context. It isn't the responsibility of the API to make sure that you stick to a specific model. As it's name suggests, the API is just the interface between your code and the driver. The reason why it throws GL_INVALID_OPERATION is not because it sees that it is deprecated, but because the operation is invalid in the current state you call it in. There is currently no mechanism to "warn" the developer of deprecated functionality. GL_INVALID_OPERATION can result from many other things as well that are not deprecation related, so I strongly suggest to use an external tool to do GL debugging. There are more and more of them showing up these days because programmers have recognized the need to verify that they aren't doing something dumb, and any serious GL programmer should always have one at hand.

@whateverpl

This comment has been minimized.

Show comment
Hide comment
@whateverpl

whateverpl Jul 8, 2014

It's regarding to useful of core context. Last time(about one week ago, by the way I still use it) I needed OpenGl core profile 3.3 because, my laptop (graphics card Intel HD graphics 4000) suports 3.3 in core and 3.0 in compatibility (OpenGL tutorial was for 3.3). I like very mush SFML, so I decided to add and recompile sources with special enum in ContextSettings for core profile. I lost some time for it, even if for developer it should be 10 mins. So I think in my case it would be very useful(I lost a lot of time, because I was writing it also in rbSFML) :)

whateverpl commented Jul 8, 2014

It's regarding to useful of core context. Last time(about one week ago, by the way I still use it) I needed OpenGl core profile 3.3 because, my laptop (graphics card Intel HD graphics 4000) suports 3.3 in core and 3.0 in compatibility (OpenGL tutorial was for 3.3). I like very mush SFML, so I decided to add and recompile sources with special enum in ContextSettings for core profile. I lost some time for it, even if for developer it should be 10 mins. So I think in my case it would be very useful(I lost a lot of time, because I was writing it also in rbSFML) :)

@binary1248 binary1248 self-assigned this Jul 8, 2014

@binary1248 binary1248 added this to the 2.x milestone Jul 8, 2014

@binary1248 binary1248 added s:accepted and removed s:unassigned labels Jul 8, 2014

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Oct 20, 2014

Are there any news about this or does anybody know of a workaround to get a core context?
Under MacOS there is no compatibility mode.

gnzlbg commented Oct 20, 2014

Are there any news about this or does anybody know of a workaround to get a core context?
Under MacOS there is no compatibility mode.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Oct 20, 2014

Member

See the gl_dev branch.

Member

eXpl0it3r commented Oct 20, 2014

See the gl_dev branch.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Oct 20, 2014

Member

Additionally, see 0a5f381 (already in master)

Member

mantognini commented Oct 20, 2014

Additionally, see 0a5f381 (already in master)

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Oct 20, 2014

Awesome, i'll switch to master and give it a try.

gnzlbg commented Oct 20, 2014

Awesome, i'll switch to master and give it a try.

@eXpl0it3r eXpl0it3r removed this from the 2.x milestone Nov 13, 2014

@ecraven ecraven removed this from the 2.x milestone Nov 13, 2014

@binary1248 binary1248 added this to the 2.3 milestone Feb 24, 2015

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Feb 24, 2015

Member

Will be added as part of #779.

Member

binary1248 commented Feb 24, 2015

Will be added as part of #779.

@ghost ghost referenced this issue Mar 22, 2015

Closed

SFML Port (Master Task) #105

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Mar 26, 2015

Member

Has been fixed through #779

Member

eXpl0it3r commented Mar 26, 2015

Has been fixed through #779

@eXpl0it3r eXpl0it3r closed this Mar 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment