[2.1] Only 1 item displayed in multiple renderwindows

[spookyboo]

I have a 2.1 setup in which Ogre runs in 3 Qt widgets. In each widget a Renderwindow is created, a Scenemanager is created and an Item is displayed (using the same mesh). The problem is, that only the Item is displayed in the latest widget that was created and not in the first 2. Ogre log says:

Code: Select all

21:10:13: Vertex Shader: 536870913VertexShader_vs
Fragment Shader: 536870913PixelShader_ps
 GLSL validation result : 
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. Some kind of element buffer must be bound.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. VAO names must be generated with glGenVertexArrays before they can be bound or used.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. Array object is not active.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. VAO names must be generated with glGenVertexArrays before they can be bound or used.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. Some kind of element buffer must be bound.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. VAO names must be generated with glGenVertexArrays before they can be bound or used.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. Array object is not active.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. VAO names must be generated with glGenVertexArrays before they can be bound or used.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. Some kind of element buffer must be bound.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. VAO names must be generated with glGenVertexArrays before they can be bound or used.
21:10:13: OpenGL:error(high) 1282: GL_INVALID_OPERATION error generated. Array object is not active.

This keeps on going during rendering.
If I create just only 1 widget (and 1 Renderwindow) everything is fine. What could be the cause? (still trying to find my way in 2.1)

[dark_sylinc]

If I have to guess, you're creating 3 different GL contexts, and for the love of everything that is good and even after praying to all the Graphics Gods, I couldn't get that to work.

Fortunately, you can have multiple windows using the same context (as long as they have the same pixel format and MSAA settings).
The 2nd and 3rd window create them using the same context. This snippet works for me:

Code: Select all

static HGLRC g_glContext = 0; //Global variable. Do it properly if you want.
QtOgreWidget::QtOgreWidget( ... )
{
    Ogre::NameValuePairList cfg;
    if( g_glContext )
    {
        //Use the OpenGL context from the first window.
        cfg["externalGLContext"] = Ogre::StringConverter::toString( (size_t)(g_glContext) );
        cfg["vsync"] = "No";
    }
    
    m_window = Ogre::Root::getSingleton().createRenderWindow( "Wnd_" + instanceStr,
                                                              width(), height(), false, &cfg );
    if( !g_glContext )
    {
        g_glContext = wglGetCurrentContext(); //glXGetCurrentContext on Linux.
    }
}

That is, the first time it creates the window and grabs the GL context.
The next iterations will reuse the GL context.
VSync has to be forced to off on the subsequent windows because otherwise 3 windows are going to VSync three times in some systems (giving you an effective 15FPS throttle) or one time in some systems (giving you 60 FPS as supposed)

If anybody is able to get Ogre to run with multiple Contexts, I'd want to know it!

[spookyboo]

Thanks. That was exactly the problem

[king_virtualize]

Hi !

It seems the externalGLContext misc parameter is not parsed in the OGREGL3PlusRenderSystem source (while creating a render window) (OgreGLXWindow.cpp 133) :

Code: Select all

            // NB: Do not try to implement the externalGLContext option.
            //
            //   Accepting a non-current context would expose us to the
            //   risk of segfaults when we made it current. Since the
            //   application programmers would be responsible for these
            //   segfaults, they are better discovering them in their code.

I tried to use the currentGLContext misc parameter to share the GLX context between two render windows, but I cannot make
it work, my second render window buffer is not updated correctly.

My second render window cannot be displayed, and if I let OGRE initialize a new context per render window, then I have graphics glitches, as described
in this post, is there a way to make multiple render window work appropriately (so I can inject the feature in my game engine) ?

Is there specific code inside the GL3 Render System I can write to make the GL context sharing work correctly ?

[dark_sylinc]

I just tried (Mesa git; Radeon HD 7770) using currentGLContext and commenting this line:

Code: Select all

glxContext = glXGetCurrentContext();
//glxDrawable = glXGetCurrentDrawable(); //---> comment this line

in GLXWindow::create.

It should in theory make Ogre use the same Context but create different drawables, which by spec, it must be supported. But I couldn't get it to work. I get random garbage in one window and black on the other window; and destroying the context on exit causes X11 to deadlock.

Perhaps it works with the NVIDIA proprietary drivers.

Our GL window creation code is a mess so it might be our fault.

I will try to repro this bug in a more isolated case; and if it's a Mesa bug then report it to Mesa.

Edit: This code should come in handy.

[king_virtualize]

It runs very well on my configuration, I'm on Linux Ubuntu 16.04.1 LTS Xenial Xerus (kernel 4.4.0-59-generic), with Nvidia proprietary drivers 367.57, with a Geforce GTX 960.
I thought it could be Qt that produced context sharing error with OpenGL, but it seems everything is ok.

Thank you for your quick reply !

[dark_sylinc]

I'm glad it works for you but I can't seem to make it work with Mesa, but I have no problem with small repros. Most likely our fault (or we're triggering a Mesa bug somewhere deep)

I cannot devote more time to this; I'm afraid the best solution begins to sound like rewriting the GLX code from scratch. Right now it's a mess.

[crancran]

I've tried everything possible short of doing just that to get Mesa to work with multiple render windows. Its really unfortunate as its a complete show-stopping use case.

[crancran]

I decided to create a stripped down implementation with Mesa and QT (no GL3+ renderer code). I was able to get this to work both with shared & individual GL contexts.

Selection_026.png

Edit:
I ported the GL3+ OgreGLXSupport code into my sample application and called into that for display management, it works just fine.
Since I am providing OGRE my own window handles, there's no need to be concerned with the windowing code itself.
So that makes me wonder if the issue is with something deeper inside the GL3+ render system itself or something lower level.

Dark, any suggestions or thoughts?

[crancran]

Dark

Actually the one difference between my simple application and OGRE is I believe OGRE pushes content to all render targets and then iterates and swaps buffers for all targets at the end of the compositor passes.

Previously my sample application's draw method looked something like the following.
You'll notice that I swap buffers immediately after the specific render target's contents had been updated.

Code: Select all

void RenderWidget::Draw() {
	if ( !glXMakeCurrent( support_->GetGLDisplay(), drawable_, glContext_ ) ) {
		printf( "Failed to make current %p, %lu, %p\n", support_->GetGLDisplay(), drawable_, glContext_ );
		return;
	}
        ratio_ = calculateDrawColorRatio();
        // adjust widget's color based on the ratio over tiem
	float r = r_ * ratio_;
	float g = g_ * ratio_;
	float b = b_ * ratio_;

	glClearColor( r, g, b, 1.0f );
	glClear( GL_COLOR_BUFFER_BIT );
	glFinish();
        glSwapBuffers( support->GetGLDisplay(), drawable_ );
}

I decided to mimic the compositors where we basically write to the drawables and then do buffer swaps at the end for all render targets. To do that, I moved glSwapBuffers to its on call:

Code: Select all

void MainWindow::OnDraw() {
	// perform passes
	for ( auto it = widgets_.begin(); it != widgets_.end(); ++it ) {
		( *it )->Draw();
	}
	// OGRE swaps buffers on all render targets after all passes
	for ( auto it = widgets_.begin(); it != widgets_.end(); ++it ) {
		( *it )->SwapBuffers();
	}
}

If I haven't made a mistake in undering OGRE's render pipeline, the GL3 renderer can't use a shared context for each render target because what ends up happening for me is this:

Selection_027.png

If I toggle the application not to use a shared context, the buffers draw and swap as in my previous screen-shot.
Before I go trucking off to hack away at GL3, do I have a misunderstanding of how this should ultimately work?

[crancran]

So my latest iteration to get this work involves the following setup:

1. The engine's OGRE wrapper creates a hidden 1x1 render window at bootstrap. No camera, scene manager, nor compositor workspace is attached.
2. The editor constructs several render windows, each with their own camera, scene manager, compositor workspace, and dedicated workspace background fill-color.

The initial render window is created simply using:

Code: Select all

root->initialise( false );
Ogre::NameValuePairList params;
params[ "hidden" ] = "true";
root_->createRenderWindow( "dummy", 1, 1, false, &params );

Later on when the editor asks the engine for render contexts, they're created simply using:

Code: Select all

Ogre::NameValuePairList params;
params[ "vsync" ] = "No";
params[ "externalWindowHandle" ] = windowHandleStr;
Ogre::RenderWindow* renderWindow = root_->createRenderWindow( name, width, height, fullscreen, &params );

In the editor, it looks like this:

Selection_028.png

The render windows are created from top-left to bottom right (red, green, blue, then white). It seems the workspace background color is being sent to the right drawables and contexts, but the actual scene content is what isn't. Are we certain we don't have something going wrong somewhere upstream with multiple render windows in play?

[crancran]

When I have 2 OGRE created render windows using GL3+ (no QT involved or other libraries), I'm noticing that the drawable that is rendered depends on the order of scene construction.

For example, this code builds all the components for the window, stores their pointers in the provided RenderContext struct and the iterates the constructed contexts and builds the scene for each render window. Using this method, OGRE ends up drawing only the scene associated to the last constructed RenderWindow.

Code: Select all

for ( int i = 0; i < 2; ++i ) {
  RenderContext* rc = new RenderContext();
  BuildWindow( rc );
  BuildSceneManager( rc );
  BuildCamera( rc );
  BuildCompositor( rc );
  contexts.push_back( rc );
}

for ( auto it = contexts.begin(); it != contexts.end(); ++it ) {
  RenderContext* rc = *it;
  BuildScene( rc );
}

However if we make a small modification in the logic and build everything for each window together, OGRE ends up only rendering the first RenderWindow.

Code: Select all

for ( int i = 0; i < 2; ++i ) {
  RenderContext* rc = new RenderContext();
  BuildWindow( rc );
  BuildSceneManager( rc );
  BuildCamera( rc );
  BuildCompositor( rc );
  BuildScene( rc ); // <-- notice the scene is built inline with the other objects
  contexts.push_back( rc );
}

This seems more likely the issue is somewhere internal with OGRE and scene management rather than the GL3+ code?

It seems the deciding factor is when my code calls:

Code: Select all

manualObject_ = sceneManager_->createManualObject();

[crancran]

My findings show what appears to be a single VAO being constructed for the manual-objects from both scenes. OGRE then attempts to share this VAO between two unrelated GLContexts which my understanding is that isn't possible unless you share GLContexts, which implies the use of the "currentGLContext" parameter being set to "true".

Unfortunately when I use this approach, the two contexts and render targets get created fine; however during the swapping of the buffers, I get this error:

Code: Select all

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  11 (X_GLXSwapBuffers)
  Serial number of failed request:  70
  Current serial number in output stream:  70

Both render targets output that they were created with FBConfigID=157, so I'm not exactly sure why it would fail if they both have the same config ids. It's also worth noting that both windows are being created by OGRE too.
Thoughts?

[crancran]

dark_sylinc -

The issue here really boils down to several problems when using a shared GL context between multiple drawables. The following is (in my opinion) a hack in order to get GL3+ to work under this setup. Along the way, the following are key points I identified that needed tweaked in my hack to make Ogre render multiple windows correctly.

#1
The code inside OgreGLXWindow.cpp specifically sets the glxDrawable when the currentGLContext is true.
Mentioned elsewhere, you've asked people to comment out that line of code:

Code: Select all

glxContext = glXGetCurrentContext();
//glxDrawable = glXGetCurrentDrawable();

#2
The problem at this point is that when allowing OGRE to create the render windows, I get a Mesa BadMatch crash shown in my last post.
The solution I found was to recreate the GLXFBConfig based on the newly created drawable window.
This is obviously a work around as I don't technically believe we **need** to do it this way, but it at least sufficed for moving forward.

Code: Select all

 glxDrawable = mWindow;
// FIXME this seems to be required when OGRE creates 2 drawables and we share a context between them
fbConfig = mGLSupport->getFBConfigFromDrawable( glxDrawable, &width, &height );

#3
At this point, OGRE at least creates the two render windows, it doesn't crash and neither window renders. If one render target is destroyed, then OGRE will magically start rendering the render target that was left open. I stepped through all of the GL3+ code and context swaps and everything seemed fine. I mocked up OGRE using Mesa directly and followed the same execution order from the compositor manager and could reproduce the same behavior in a simple OpenGL app. The problem stems from when we call glxSwapBuffers.

From what I can tell, glxSwapBuffers needs to be called immediately after we've rendered one surface and before we've transitioned to drawing the additional surfaces. By doing this, OGRE draws both windows correctly. This of course means a significant change in compositor behavior I believe and unfortunately I'm not versed enough with DX11 (or other render systems really) to know what impacts this ultimately has.

If you could give some input on my findings, that'd be great to know if I am at least on the right track.

[dark_sylinc]

I've bookmarked this page because those are great findings you have there, and I'll need to re-read them several times very carefully.

Keep up the good work!

[crancran]

I decided to test this on DX11 to see if I observed the same results.
DX11 seems to work just fine with the delayed compositor workspace buffer swaps.

[dermont]

For Linux/Qt on current code base try creating primary render window with "externalWindowHandle" and secondary windows with "currentGLContext" and "externalWindowHandle". For Linux/X create X windows and same as above. This is with proprietary drivers so may not what you are asking for.

[crancran]

I used your code dermont and unfortunately, it doesn't seem to render on 2.1, at least not under Fedora.

[crancran]

dark_sylinc -

I am attaching my test program (it is based on QT) where I have been working with 3 particular configurations:

1. Using 2 drawables with *NO* shared state.
2. Using 2 drawables where the secondary drawable shares state with the former (e.g. context sharing via shared list).
3. Using 2 drawables where they both use the same GL context (e.g. currentGLContext=true).

The attached program is simply designed to render a simple primitive triangle on the specified drawable surface (nothing fancy).
It could have mistakes, so be aware that I'm providing this as-is .

I have made a few notes inside RenderWidget.cpp, in particular inside RenderWidget::Update() and RenderWidget::SwapBuffers.
I am still trying to hack away at this, but I figured having a very simple app might help isolate where the problem lies with both multi-context and current-context support for GL3+.

[crancran]

Unfortunately, I've given as much time to this as I possibly can but sadly the results are not as I would have hoped.

It is my understanding that GL3+ with GLX treats the first render window as a main/primary context of sorts. Any subsequent windows that are created are therefore treated as child contexts, so they would essentially inherit the shared state their parent maintains to minimize the memory footprint needed. This design is exactly how the DX11 render system is designed too.

It's my understanding there are a number of data items that can be shared among contexts, notably VBOs and GPU programs, but one thing I've read isn't supported is the notion of sharing VAOs. This seems to contradict the current inherent design in OGRE where at the time of loading a renderable, a VAO will be constructed and therefore bound to whatever the "current" GL context happens to be. No other VAO will be constructed for the additional contexts, and so when the scene pass is executed on the drawable surfaces, one will be right while the others will appear black (or will have whatever background viewport color you've specified for your clear pass).

Is the notion of using a VAO like this an intentional design choice?
Perhaps there were some performance implications that lead to this decision?

In order to use the "currentGLContext=true" option, it really appears that it boils down to a compositor manager change where the final render target swap needs to happen before moving onto the next surface to be drawn. I've tried to locate documentation that explains why that is necessary, but maybe it is just that Mesa must do it this way when sharing a single context with multiple drawables.

[dark_sylinc]

It is my understanding that GL3+ with GLX treats the first render window as a main/primary context of sorts. Any subsequent windows that are created are therefore treated as child contexts, so they would essentially inherit the shared state their parent maintains to minimize the memory footprint needed. This design is exactly how the DX11 render system is designed too.

That is correct. This is some D3D9 remnant; and when it comes to GL it's tricky. D3D11 doesn't have this issue at all, but it just behaves in the same way for consistency (and probably due to how the code works too).

It's my understanding there are a number of data items that can be shared among contexts, notably VBOs and GPU programs, but one thing I've read isn't supported is the notion of sharing VAOs. This seems to contradict the current inherent design in OGRE where at the time of loading a renderable, a VAO will be constructed and therefore bound to whatever the "current" GL context happens to be. No other VAO will be constructed for the additional contexts, and so when the scene pass is executed on the drawable surfaces, one will be right while the others will appear black (or will have whatever background viewport color you've specified for your clear pass).

That is half spot on.
For v1 objects, we have one global VAO created at init time and works the way you described.
For v2 objects though, we keep one VAO per vertex format (actually it's per buffer pool per vertex format; but the majority of use cases end up using one pool, thus one VAO per vertex format. But it's not impossible to have more than one VAO per vertex format). The VaoManager is responsible for handling this.

Is the notion of using a VAO like this an intentional design choice?
Perhaps there were some performance implications that lead to this decision?

The global vao was just for simplicity. The old v1 code is from long before VAOs and GL3 requires a VAO to be bound, so using a mutable VAO was a quick and simple solution (one that many use).
But for v2 we have multiple VAOs, and it would be extremely complicated and unreasonable to multiply the VAOs based on the number of RenderWindows currently live.

Even if we were to adjust our VAOs to fit context sharing, the real issue here is that trying to get multiple GL contexts is a no-go. The OpenGL specs define it loosely and allow a very wide range of behaviors; which makes it impossible to make it run reliably on multiple drivers and platforms. Crashes, glitches, nothing rendering, deadlocks, inexplicable errors, BSODs... context sharing is a pandora's box.
GL context sharing is only useful in practice for running background stuff like data streaming and shader compilation (and even then, dealing with driver glitches and driver crashes is a PITA; but if you target one platform you can enable it for one major vendor or two where you've tested it).

Using one GL context with multiple drawables is a far more stable approach in general.

In order to use the "currentGLContext=true" option, it really appears that it boils down to a compositor manager change where the final render target swap needs to happen before moving onto the next surface to be drawn. I've tried to locate documentation that explains why that is necessary, but maybe it is just that Mesa must do it this way when sharing a single context with multiple drawables.

Yeah, it's not necessary for Ogre, but it was necessary for certain RenderSystems. I remember D3D9 was the most picky about it (which we no longer support); but in general the order in which RenderWindows are swapped is mostly just to get drivers to work and doing at the end used to work with all the combinations we tried so far (obviously not the case here). Since it's not hard requirement, this can be adapted.

If Mesa requires to swap buffers before switching the GL context to use a different drawable, it might just be a Mesa bug; nonetheless it's possible that we should just detect if Mesa is being used and do a swap before switching (or do it for every GL implementation). It may also be possible that calling glFlush() could work (likely glFinish too, but that would be slow).

[crancran]

Using one GL context with multiple drawables is a far more stable approach in general.

That makes sense, then I would propose we shift GL3+ to behave this way by default. Today it assumes the notion of creating a secondary context that inherits the parent. Obviously this approach on Mesa doesn't work; hence my stance to move toward the single context / multi-drawable solution as default. I also think the GL3+ render system can be tweaked so that users don't need to be concerned with creating a dummy window to preserve the main context either. It doesn't seem to much to make those changes given I have this almost working as-is locally for Mesa. Whats your thoughts on shifting the default behavior?

In order to use the "currentGLContext=true" option, it really appears that it boils down to a compositor manager change where the final render target swap needs to happen before moving onto the next surface to be drawn. I've tried to locate documentation that explains why that is necessary, but maybe it is just that Mesa must do it this way when sharing a single context with multiple drawables.

Yeah, it's not necessary for Ogre, but it was necessary for certain RenderSystems. I remember D3D9 was the most picky about it (which we no longer support); but in general the order in which RenderWindows are swapped is mostly just to get drivers to work and doing at the end used to work with all the combinations we tried so far (obviously not the case here). Since it's not hard requirement, this can be adapted.

If Mesa requires to swap buffers before switching the GL context to use a different drawable, it might just be a Mesa bug; nonetheless it's possible that we should just detect if Mesa is being used and do a swap before switching (or do it for every GL implementation). It may also be possible that calling glFlush() could work (likely glFinish too, but that would be slow).

My local fix I've been playing with (single GL context + multi-drawables) does precisely this. I added a new method to RenderTarget that indicates an immediate buffer swap post update and the default implementation is false, to keep existing other drivers/implementations status-quo and then for GLXWindow, it returns true. This way the compositor workspace update checks this and determines should it do an immediate buffer swap or not before moving to the next render target.