[osg-users] context IDs

Discussion:

Andy Skinner

2018-09-17 18:08:13 UTC

If we get our contextIDs from GraphicsContext::createNewContextID(), it could give us a new number or return a previous one, if we are returning them with GraphicsContext::decrementContextIDUsageCount. Right?

Is there an intended connection between a contextID that has been used and a new one? It looks to me that extensions are stored per context ID and never reset.

So if we change something about what we are looking for in the context (sometimes we fall back to software OpenGL for testing or helping a customer through an issue), we might reuse a context ID, but still have extensions associated with the ID that are not appropriate for it.

Am I missing an assumption here? Should I be able to reuse a contextID for an unrelated context? If not, I'll just remove call to decrementContextIDUsageCount. That means the number and various maps will continue to grow.

thanks
andy

Robert Osfield

2018-09-19 08:19:54 UTC

Permalink

Hi Andy,

It's quite a while since I worked specifically on the osg::State,
ContextID, osg::GLExtensions management. In principle it should be
possible to reuse ContextID's, the sticky issue of whether the
GLExtensions object is recreated for each new graphics context is
something I haven't personally tested. Looking at osg::State is does
look to clean up the GLExtensions object in 3.4 onwards (I haven't
checked further back)

For graphics performance I would recommend that applications don't go
creating and destroying GraphicsWindows, if possible just hide the
window and reuse it will provide better performance.

Cheers,
Robert.

Post by Andy Skinner
If we get our contextIDs from GraphicsContext::createNewContextID(), it could give us a new number or return a previous one, if we are returning them with GraphicsContext::decrementContextIDUsageCount. Right?
Is there an intended connection between a contextID that has been used and a new one? It looks to me that extensions are stored per context ID and never reset.
So if we change something about what we are looking for in the context (sometimes we fall back to software OpenGL for testing or helping a customer through an issue), we might reuse a context ID, but still have extensions associated with the ID that are not appropriate for it.
Am I missing an assumption here? Should I be able to reuse a contextID for an unrelated context? If not, I'll just remove call to decrementContextIDUsageCount. That means the number and various maps will continue to grow.
thanks
andy
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Andy Skinner

2018-09-19 11:44:37 UTC

Permalink

Thanks. The problem is in GLExtensions.cpp. It has some maps that it keeps, and it adds contexts and does not take them off. But GraphicsContext will provide an old, no-long-used context ID, and that ID can look up the wrong thing in GLExtensions.cpp if we have changed from hardware to software OpenGL.

Oh, wait. I see, you're talking about when the GLExtensions object gets created. Let me look into that.

We make lots of windows over time, and don't really know in advance how many we'll have, either at one time or across a session. We are drawing into buffers that then get drawn into Java windows.

andy

-----Original Message-----
From: osg-users <osg-users-***@lists.openscenegraph.org> On Behalf Of Robert Osfield
Sent: Wednesday, September 19, 2018 4:20 AM
To: OpenSceneGraph Users <osg-***@lists.openscenegraph.org>
Subject: Re: [osg-users] context IDs

Hi Andy,

It's quite a while since I worked specifically on the osg::State, ContextID, osg::GLExtensions management. In principle it should be possible to reuse ContextID's, the sticky issue of whether the GLExtensions object is recreated for each new graphics context is something I haven't personally tested. Looking at osg::State is does look to clean up the GLExtensions object in 3.4 onwards (I haven't checked further back)

For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance.

Cheers,
Robert.

Andy Skinner

2018-09-19 14:52:18 UTC

Permalink

OK, I've digested some more. I see what you mean (I think) about ~State clearing the GLExtensions object from the static map (s_extensions) defined in GLExtensions.cpp.

However, if the next GLExceptions::Get will make a new one, the GLExtensions constructor will use other static maps: s_glExtensionSetList, s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions object, we will get the answers from last time, because they were cached.

It seems to me that if we need to store these per context ID, and if we can re-use context IDs, then we need a way to clear out what is stored, possibly when the context ID usage count goes to 0, or maybe explicitly.

thanks

andy

-----Original Message-----
From: osg-users <osg-users-***@lists.openscenegraph.org> On Behalf Of Robert Osfield
Sent: Wednesday, September 19, 2018 4:20 AM
To: OpenSceneGraph Users <osg-***@lists.openscenegraph.org>
Subject: Re: [osg-users] context IDs

Hi Andy,

It's quite a while since I worked specifically on the osg::State, ContextID, osg::GLExtensions management. In principle it should be possible to reuse ContextID's, the sticky issue of whether the GLExtensions object is recreated for each new graphics context is something I haven't personally tested. Looking at osg::State is does look to clean up the GLExtensions object in 3.4 onwards (I haven't checked further back)

For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance.

Cheers,
Robert.

Robert Osfield

2018-09-19 18:27:54 UTC

Permalink

Hi Andy,

I have just had a quick look at the various s_* containers in
GLExtensions.cpp and I think these are an old hang over that should be
removed and replaced by code that is embedded into the GLExtensions
object so that it can be constructed and destructed.

Short of this refactor perhaps these data structures could be reset
within the GLExtensions destructor.

I don't have time to look into a fix right now, so either dive into
the code yourself or avoid creating and destructor lots of contexts.

Robert.

Robert.

Post by Andy Skinner
OK, I've digested some more. I see what you mean (I think) about ~State clearing the GLExtensions object from the static map (s_extensions) defined in GLExtensions.cpp.
However, if the next GLExceptions::Get will make a new one, the GLExtensions constructor will use other static maps: s_glExtensionSetList, s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions object, we will get the answers from last time, because they were cached.
It seems to me that if we need to store these per context ID, and if we can re-use context IDs, then we need a way to clear out what is stored, possibly when the context ID usage count goes to 0, or maybe explicitly.
thanks
andy
-----Original Message-----
Sent: Wednesday, September 19, 2018 4:20 AM
Subject: Re: [osg-users] context IDs
Hi Andy,
It's quite a while since I worked specifically on the osg::State, ContextID, osg::GLExtensions management. In principle it should be possible to reuse ContextID's, the sticky issue of whether the GLExtensions object is recreated for each new graphics context is something I haven't personally tested. Looking at osg::State is does look to clean up the GLExtensions object in 3.4 onwards (I haven't checked further back)
For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance.
Cheers,
Robert.

_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Andy Skinner

2018-09-19 19:32:16 UTC

Permalink

Thanks, I'll take a look. I am hoping this will be more remove than replace, not needing multiple levels of caching.

thanks
andy

-----Original Message-----
From: osg-users <osg-users-***@lists.openscenegraph.org> On Behalf Of Robert Osfield
Sent: Wednesday, September 19, 2018 2:28 PM
To: OpenSceneGraph Users <osg-***@lists.openscenegraph.org>
Subject: Re: [osg-users] context IDs

Hi Andy,

I have just had a quick look at the various s_* containers in GLExtensions.cpp and I think these are an old hang over that should be removed and replaced by code that is embedded into the GLExtensions object so that it can be constructed and destructed.

Short of this refactor perhaps these data structures could be reset within the GLExtensions destructor.

I don't have time to look into a fix right now, so either dive into the code yourself or avoid creating and destructor lots of contexts.

Robert.

Robert.

Post by Andy Skinner
OK, I've digested some more. I see what you mean (I think) about ~State clearing the GLExtensions object from the static map (s_extensions) defined in GLExtensions.cpp.
However, if the next GLExceptions::Get will make a new one, the GLExtensions constructor will use other static maps: s_glExtensionSetList, s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions object, we will get the answers from last time, because they were cached.
It seems to me that if we need to store these per context ID, and if we can re-use context IDs, then we need a way to clear out what is stored, possibly when the context ID usage count goes to 0, or maybe explicitly.
thanks
andy
-----Original Message-----
Sent: Wednesday, September 19, 2018 4:20 AM
Subject: Re: [osg-users] context IDs
Hi Andy,
It's quite a while since I worked specifically on the osg::State,
ContextID, osg::GLExtensions management. In principle it should be
possible to reuse ContextID's, the sticky issue of whether the
GLExtensions object is recreated for each new graphics context is
something I haven't personally tested. Looking at osg::State is does
look to clean up the GLExtensions object in 3.4 onwards (I haven't
checked further back)
For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance.
Cheers,
Robert.

_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org.
openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org.
openscenegraph.org

Andy Skinner

2018-09-21 15:46:47 UTC

Permalink

I tried your suggestion of clearing the s_gl* lists in ~GLException. I think it works, but have not been as thorough as I'd like yet.

Do I need to consider threading issues? Could someone be calling isGLExtensionOrVersionSupported at the same time ~GLExceptions is being called?

I am using an older version of OSG, and when I send a version for review, I should probably make the change to current files.

While I think the smaller fix would be appropriate for us, I like the alternate approach better. It would be:
* put the things stored on the s_gl* lists into GLExtensions
* pull out the code that gets the renderer string and extensions and have them called from GLExtensions constructor.
* have isGLExtensionOrVersionSupported do GLExtensions::Get to get or create the GLExtensions for the given context ID and check that.
* remove the s_gl* lists

I can't update the version of OpenSceneGraph in this part of our cycle, but I may be able to make a change. I think I feel better with the change to clear the existing list element in ~GLException. But I think the other approach would be better for current OSG.

andy

-----Original Message-----
From: Andy Skinner
Sent: Wednesday, September 19, 2018 3:32 PM
To: OpenSceneGraph Users <osg-***@lists.openscenegraph.org>
Subject: RE: [osg-users] context IDs

Thanks, I'll take a look. I am hoping this will be more remove than replace, not needing multiple levels of caching.

thanks
andy

-----Original Message-----
From: osg-users <osg-users-***@lists.openscenegraph.org> On Behalf Of Robert Osfield
Sent: Wednesday, September 19, 2018 2:28 PM
To: OpenSceneGraph Users <osg-***@lists.openscenegraph.org>
Subject: Re: [osg-users] context IDs

Hi Andy,

I have just had a quick look at the various s_* containers in GLExtensions.cpp and I think these are an old hang over that should be removed and replaced by code that is embedded into the GLExtensions object so that it can be constructed and destructed.

Short of this refactor perhaps these data structures could be reset within the GLExtensions destructor.

I don't have time to look into a fix right now, so either dive into the code yourself or avoid creating and destructor lots of contexts.

Robert.

Robert.

Post by Andy Skinner
OK, I've digested some more. I see what you mean (I think) about ~State clearing the GLExtensions object from the static map (s_extensions) defined in GLExtensions.cpp.
However, if the next GLExceptions::Get will make a new one, the GLExtensions constructor will use other static maps: s_glExtensionSetList, s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions object, we will get the answers from last time, because they were cached.
It seems to me that if we need to store these per context ID, and if we can re-use context IDs, then we need a way to clear out what is stored, possibly when the context ID usage count goes to 0, or maybe explicitly.
thanks
andy
-----Original Message-----
Sent: Wednesday, September 19, 2018 4:20 AM
Subject: Re: [osg-users] context IDs
Hi Andy,
It's quite a while since I worked specifically on the osg::State,
ContextID, osg::GLExtensions management. In principle it should be
possible to reuse ContextID's, the sticky issue of whether the
GLExtensions object is recreated for each new graphics context is
something I haven't personally tested. Looking at osg::State is does
look to clean up the GLExtensions object in 3.4 onwards (I haven't
checked further back)
For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance.
Cheers,
Robert.

Robert Osfield

2018-09-21 20:13:33 UTC

Permalink

Hi Andy,

I think it should be safe, if someone is calling isGL* at the same
time as the GLExtension is being destructed then there are wider
problems at play, as far as I'm aware it shouldn't happen in normal
operation of the OSG.

Once you have changes you are happy with just create a PR for it or
post the changes to osg-submissions.

Cheers,
Robert.

Post by Andy Skinner
I tried your suggestion of clearing the s_gl* lists in ~GLException. I think it works, but have not been as thorough as I'd like yet.
Do I need to consider threading issues? Could someone be calling isGLExtensionOrVersionSupported at the same time ~GLExceptions is being called?
I am using an older version of OSG, and when I send a version for review, I should probably make the change to current files.
* put the things stored on the s_gl* lists into GLExtensions
* pull out the code that gets the renderer string and extensions and have them called from GLExtensions constructor.
* have isGLExtensionOrVersionSupported do GLExtensions::Get to get or create the GLExtensions for the given context ID and check that.
* remove the s_gl* lists
I can't update the version of OpenSceneGraph in this part of our cycle, but I may be able to make a change. I think I feel better with the change to clear the existing list element in ~GLException. But I think the other approach would be better for current OSG.
andy
-----Original Message-----
From: Andy Skinner
Sent: Wednesday, September 19, 2018 3:32 PM
Subject: RE: [osg-users] context IDs
Thanks, I'll take a look. I am hoping this will be more remove than replace, not needing multiple levels of caching.
thanks
andy
-----Original Message-----
Sent: Wednesday, September 19, 2018 2:28 PM
Subject: Re: [osg-users] context IDs
Hi Andy,
I have just had a quick look at the various s_* containers in GLExtensions.cpp and I think these are an old hang over that should be removed and replaced by code that is embedded into the GLExtensions object so that it can be constructed and destructed.
Short of this refactor perhaps these data structures could be reset within the GLExtensions destructor.
I don't have time to look into a fix right now, so either dive into the code yourself or avoid creating and destructor lots of contexts.
Robert.
Robert.

Post by Andy Skinner
OK, I've digested some more. I see what you mean (I think) about ~State clearing the GLExtensions object from the static map (s_extensions) defined in GLExtensions.cpp.
However, if the next GLExceptions::Get will make a new one, the GLExtensions constructor will use other static maps: s_glExtensionSetList, s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions object, we will get the answers from last time, because they were cached.
It seems to me that if we need to store these per context ID, and if we can re-use context IDs, then we need a way to clear out what is stored, possibly when the context ID usage count goes to 0, or maybe explicitly.
thanks
andy
-----Original Message-----
Of Robert Osfield
Sent: Wednesday, September 19, 2018 4:20 AM
Subject: Re: [osg-users] context IDs
Hi Andy,
It's quite a while since I worked specifically on the osg::State,
ContextID, osg::GLExtensions management. In principle it should be
possible to reuse ContextID's, the sticky issue of whether the
GLExtensions object is recreated for each new graphics context is
something I haven't personally tested. Looking at osg::State is does
look to clean up the GLExtensions object in 3.4 onwards (I haven't
checked further back)
For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance.
Cheers,
Robert.