| View previous topic :: View next topic |
| Author |
Message |
Trass3r
Joined: 29 Feb 2008
Posts: 66
Location: Germany
|
 Posted: Wed Aug 11, 2010 11:37 am Post subject: OpenGL4? |
 |
|
Any schedule for OpenGL versions >= 3? esp. 4.x of course because of the DirectX11 functionality  |
|
| Back to top |
|
 |
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Wed Aug 11, 2010 9:42 pm Post subject: |
|
|
It's on the TODO list, for sure. I don't have a timetable for you though. I hope to get the build system stabilized, the platform-specific GL extensions implemented, and the docs completed before moving on to this.
Another thing is that I'm not quite sure how to integrate the 3.x stuff. OGL4 is easy -- that's going to get its own package. But with the compatibility contexts of GL 3, I don't know what the best approach is.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
Trass3r
Joined: 29 Feb 2008
Posts: 66
Location: Germany
|
| Posted: Thu Aug 12, 2010 7:17 am Post subject: |
|
|
True, just skip v3  |
|
| Back to top |
|
|
ponce
Joined: 12 Nov 2009
Posts: 55
|
| Posted: Thu Aug 12, 2010 7:21 am Post subject: |
|
|
At least on Windows, to create a new style OpenGL context, one need to already have a context to check for WGL_ARB_create_context.
(Using WGL_ARB_create_context allow to create a context flagged as debug, which may be useful even when sticking to OpenGL 2.0 feature.)
In fact the ARB recommend to do so:
http://www.opengl.org/wiki/Creating_an_OpenGL_Context
As the two context (fake and 2nd) return in practice the very same capabilities, I don't see a problem with Derelict.
_________________
@p0unce | gamesfrommars |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Fri Aug 13, 2010 2:18 am Post subject: |
|
|
| ponce wrote: | At least on Windows, to create a new style OpenGL context, one need to already have a context to check for WGL_ARB_create_context.
(Using WGL_ARB_create_context allow to create a context flagged as debug, which may be useful even when sticking to OpenGL 2.0 feature.)
In fact the ARB recommend to do so:
http://www.opengl.org/wiki/Creating_an_OpenGL_Context
As the two context (fake and 2nd) return in practice the very same capabilities, I don't see a problem with Derelict. |
Yes, I'm aware of this. That's not the problem, as Derelict doesn't do any context creation. The problem is in the binding interface. Windows is really wonky about extensions -- you must have a valid context in order to load them and if you switch contexts there's no guarantee that the loaded extensions will function properly unless they are reloaded. What I'm worried about is the extension loader getting into an inconsistent state. Any extensions that have already been loaded but aren't available under the new context after reload will correctly return false on query through DerelictGL.isExtensionLoaded. But, and this is a big but, the function pointers themselves will not be reset to null -- there's no support for that currently. And adding it would be PITA.
Another issue is how to handle the gl3 interface itself. If you are using a non-compatible context, then most of the old 2.1 functions are unavailable. So we run into the same problem where DerelictGL.load pulls in numerous function addresses that become invalid after creating the gl3 context.
These potential issues point to a loader interface for GL3 that is separate from the current DerelictGL. It's just a matter of figuring out the right interface. Should DerelictGL3 get it's own package? Should it be integrated with the existing DerelictGL package? After all, when not using a forward-compatible context, all of the old 2.1 functions will still be available. And on that note, when DerelictGL.loadExtendedVersions is called, what is the best way to determine whether the current context is forward compatible or not?
There are a lot of questions to answer yet.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
ponce
Joined: 12 Nov 2009
Posts: 55
|
| Posted: Fri Aug 13, 2010 3:06 am Post subject: |
|
|
I didn't know about this need to reload entry points.
Using GLEW here (on a C++ project) I don't reload function pointers, yet everything works with NVIDIA and ATI cards (Intel doesn't support OpenGL 3 yet). But it's a Compatibility Profile context so this was expected.
I will try to create a 3.2 Core Profile context and see if "disabled" functions still work or not in practice.
In fact GLEW seems to ignore this problem:
| Quote: |
Note that according to the MSDN WGL documentation, you have to initialize the entry points for every rendering context that use pixel formats with different capabilities For example, the pixel formats provided by the generic software OpenGL implementation by Microsoft vs. the hardware accelerated pixel formats have different capabilities. GLEW by default ignores this requirement, and does not define per-context entry points (you can however do this using the steps described above). Assuming a global namespace for the entry points works in most situations, because typically all hardware accelerated pixel formats provide the same entry points and capabilities. This means that unless you use the multi-context version of GLEW, you need to call glewInit() only once in your program, or more precisely, once per process.
|
Besides, with GLEW, checking for an extension availability is done like this :
| Quote: |
if (GL_extension_name)
{
// blah
}
|
This feels better to me than testing against null, and more readable.
_________________
@p0unce | gamesfrommars |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Fri Aug 13, 2010 8:32 am Post subject: |
|
|
| ponce wrote: | I didn't know about this need to reload entry points.
Using GLEW here (on a C++ project) I don't reload function pointers, yet everything works with NVIDIA and ATI cards (Intel doesn't support OpenGL 3 yet). But it's a Compatibility Profile context so this was expected.
I will try to create a 3.2 Core Profile context and see if "disabled" functions still work or not in practice.
In fact GLEW seems to ignore this problem:
|
Yes, and Derelict's approach has been to leave it up to the user. If you need to create a new context and want to be safe, you call DerelictGL.loadExtensions again. Or not. What worries me is that GL3 adds a new dimension to this, in which case it becomes easy to corrupt the state of all the function pointers, not just the extensions. By separating it into another package and implementing the loader a bit differently, that danger can be mitigated.
| Quote: |
Besides, with GLEW, checking for an extension availability is done like this :
| Quote: |
if (GL_extension_name)
{
// blah
}
|
This feels better to me than testing against null, and more readable. |
Well, in Derelict you check against false, not null, but I do agree with you. I did have it in my head to go this route with Derelict2, but I also wanted to provide a means to be able to easily log which extensions are and aren't loaded along with the reason for those that aren't (not supported or failed to load). So taking the GLEW approach of testing a bool directly, implementing the output function becomes much more complex. However, it's easy for the user to do something like this during initialization just for the extensions he's interested in:
| Code: |
bool GL_ARB_XXX;
bool GL_ARB_YYY;
DerelictGL.loadExtensions();
GL_ARB_XXX = DerelictGL.isLoaded("GL_ARB_XXX");
GL_ARB_YYY = DerelictGL.isLoaded("GL_ARB_YYY");
|
And for people who like to do such checks to determine the codepath each frame, this would likely be a better approach than calling isLoad directly (which would cost an AA lookup each time).
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Fri Aug 20, 2010 7:02 am Post subject: |
|
|
Well, I've looked into this some more and I've decided to just throw caution to the wind and take the GLEW approach. Derelict will just load function symbols and not worry about anything else. So rather than break GL3.x and 4.x into separate packages, I'll lump them all into the current DerelictGL.
To facilitate this, I'm going to modify the interface to the DerelictGL loader somewhat. I'm mulling over a couple of different approaches, and I'm not quite sure which way I'll go yet. But, both involve removing the method loadExtendedVersions and replacing it with at least two new load methods (maybe three or four). This will put the burden of dealing with compatibility on the caller and I don't have to guess whether or not to throw an exception when a deprecated function fails to load under a 3.0 context. It's quite simpler than I made it out to be, I suppose.
Still, I won't get to this until I finish up support for the platform-specific extensions. So, I'm going to lay off the documentation for a while and focus on that.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
