Multi-context/window rendering.

[Tryum]

Is it possible to use magnum to render to different contexts ?

I'm using multiple-windows, doing the all the complex rendering from the main context through render to texture. I'm wondering if I can do the quad rendering for the other windows through Magnum or if I should do direct openGL calls.

[mosra]

Hi!

(apologies if you know this already) not widely known, but it's possible (and encouraged) to use a single GL context to render to multiple windows. For rendering to a different window you need to make it current on a different surface. Having one GL context per window is also possible, but the overhead from context switching and the limitations of sharing data between different GL contexts is not worth the pain.

As far as Magnum::GL is concerned, it should "just work", no need to use direct OpenGL calls. The window switching is done by the platform-/toolkit-specific "make context current" call.

You only need to do extra work on the "application" side, but from the above I assume you're doing that already. There's a (quite stale) PR #168 that is adding multi-window single-context support to Platform::Sdl2Application, so you can look there to see how's that done for SDL. However, with the current state of the Sdl2Application API it should be possible to have multi-window support without needing to patch the Sdl2Application itself -- by calling SDL window functions directly. Plus for each event there's direct access to the underlying SDL_Event to know what window it is attached to.

[Tryum]

Ok, I'll give it a shot on my glfw app !
Thanks.

[Tryum]

Hmm,
So, at first I thought it was not working. But then messing around, I discovered that Imgui integration messes things around. If I disable imgui it works.
What's more interesting is that if I create a 3rd window, the rendering in the 3rd one is ok !

[Tryum]

GL::Context::resetState() to the rescue ;)

[mosra]

Can you share what exactly was the problem? We recently discovered issues with the ImGui rendering which were also "fixable" by calling resetState(), but ultimately it was a state tracker bug, fixed in ee16c25 / d6e0186.

So maybe this is yet another case of a state tracker bug that should be fixed on the engine side?

[Tryum]

I wrote a small sample at home, I'll push it tonight.

To test I used the red-square-one-liner.
First try I had nothing (just the clear screen)
Then I disabled the clearing, and the square was flickering.
I also noticed that if I call two draws, then I had a solid square.

[Tryum]

Here it is : https://github.com/Tryum/magnum-imgui-state-bug (press a key to toggle imgui rendering).

I did try to first draw a square in the primary window, it seems to solve the state tracker issue, as everything was rendered fine.

I didn't realise that the commit you referenced were recent, I'll try to setup a master build of magnum to try out.

[mosra]

Not seeing any flickering with current master ... so I guess that recent fix solved this as well?

[Tryum]

I just discovered the --head option of vcpkg trying in a few minutes ;)

[Tryum]

Nop problem not solved in my case with head builds.

What can I do to help tracking the state inconsistency ?

[mosra]

Apologies if you said this elsewhere -- what's the system and GPU you're running on? Can you paste the engine startup log here?

Some ideas to try:

• The log mentions what all optional extensions is it using. Running the app with e.g. --magnum-disable-extensions "GL_ARB_direct_state_access" will make it use different code paths and maybe that could narrow the issue down. The usual suspects responsible for problems (or having driver bugs) are GL_ARB_direct_state_access and GL_ARB_vertex_array_object.
• Try running the app with --magnum-gpu-validation on. Maybe it'll show some GL errors or other debug info that could be helpful.
• I am not sure if the framebuffer-related state is stored per-window or dragged along when making the context current on a different window, so maybe setting a clear color / viewport / scissor on one window affect the others as well, causing some flicker etc?

[Tryum]

I'm running on a windows 10 PC with a 1080ti. On special thing is I'm running in a VM with GPU pass-through, but I'll dual-boot to a native win10 to clear that out.

Here's the engine startup log :

Renderer: GeForce GTX 1080 Ti/PCIe/SSE2 by NVIDIA Corporation
OpenGL version: 3.3.0 NVIDIA 419.35
Using optional features:
    GL_ARB_ES2_compatibility
    GL_ARB_direct_state_access
    GL_ARB_get_texture_sub_image
    GL_ARB_invalidate_subdata
    GL_ARB_multi_bind
    GL_ARB_robustness
    GL_ARB_separate_shader_objects
    GL_ARB_texture_filter_anisotropic
    GL_ARB_texture_storage
    GL_ARB_texture_storage_multisample
    GL_ARB_vertex_array_object
    GL_KHR_debug
Using driver workarounds:
    no-layout-qualifiers-on-old-glsl
    nv-zero-context-profile-mask
    nv-windows-dangling-transform-feedback-varying-names
    nv-cubemap-inconsistent-compressed-image-size
    nv-cubemap-broken-full-compressed-image-query
    nv-compressed-block-size-in-bits

I'll try your suggestions.

[mosra]

Pass-through should be okay, running with GPU virtualization would be much worse, that's a bug minefield as there's a combinatorial explosion of bugs in the host system drivers, guest system drivers and the VM translation layer :)

The only possibility I could see is that the VM is interferring with window swapping or something. Let me know how it behaves natively and with ARB_dsa / ARB_vao disabled.

[Tryum]

In the magnum-imgui-state-bug sample I wrote the problem is solved by disabling either ARB_dsa or ARB_vao, but not in my current app (state tracking more complex ?).

[mosra]

What if you disable both?

app.exe --magnum-disable-extensions "GL_ARB_direct_state_access GL_ARB_vertex_array_object"

[Tryum]

Then only the main window is rendered, the additional windows only have the clear color !

[mosra]

Huh. I'm trying to reproduce again, disabling one, the other or both extensions, but at least on Mesa and either Intel or AMD GPU I'm getting no issues :( Unfortunately it's been some time since I had a machine with a NVidia GPU, so I can't really try to reproduce on NV right now. I could try to reproduce this on Intel/AMD and Windows tomorrow, tho.

Any chance you could try to run this on the Intel onboard GPU instead of NV (assuming your CPU is Intel)? If I'm not mistaken, all Intel chips have it, there's just a different amount of pain involved with getting apps to run on it. Or trying out on a different machine with a different GPU vendor, if at all possible.

I assume you still have a single GL context and only making it current on a different window surface (like in that magnum-imgui-state-bug sample), so all the various problems related to multiple GL contexts sharing some-but-not-all GL objects don't apply here. So then my suspicion now is that NVidia has some funny idea about what state gets transferred when making a context current on a different surface. (But, also, I am not well aware of all interactions involved between multi-windows and GL state, so there's a possibility that this has a clear explanation which I'm not seeing and Mesa is too forgiving so it is not visible there.)

By the way, when other community members tried to run the above sample on a NV card, it reported just 15 FPS instead of 60 (and, on non-NV cards, it was going smooth 60 without any problems). Are you getting that as well? Also, was there any change in the behavior when you tried on the non-passed-through GPU but a native system?

[Tryum]

I did not tried yet on the native system, but I should be able to test on both intel and nvidia, since both are plugged to the screen for the host+gpu passthrough ;)

The only problem is that I don't have develop tools on the native win10, so I'll just launch and report. I'll be able to try things on my work machine in the next days though (win10 + GTX1060).

[Fleischner]

Default installation from vcpkg + imgui running the imgui integration sample.

Renderer: Intel(R) UHD Graphics 630 by Intel
OpenGL version: 4.5.0 - Build 25.20.100.6519
Using optional features:
GL_ARB_ES2_compatibility
GL_ARB_direct_state_access
GL_ARB_get_texture_sub_image
GL_ARB_invalidate_subdata
GL_ARB_multi_bind
GL_ARB_robustness
GL_ARB_separate_shader_objects
GL_ARB_texture_filter_anisotropic
GL_ARB_texture_storage
GL_ARB_texture_storage_multisample
GL_ARB_vertex_array_object
GL_EXT_direct_state_access
GL_KHR_debug
Using driver workarounds:
no-layout-qualifiers-on-old-glsl

• driver are up to date
• Same behavior on GL3/2, debug/release.
• Error resoved if running with --magnum-disable-extensions "GL_ARB_direct_state_access GL_EXT_direct_state_access"
• edit: Problem starts as soon as a new window is opened in imgui

But works fine if running on second grafics card

Renderer: Quadro P2000/PCIe/SSE2 by NVIDIA Corporation
OpenGL version: 4.5.0 NVIDIA 398.27
Using optional features:
GL_ARB_ES2_compatibility
GL_ARB_direct_state_access
GL_ARB_get_texture_sub_image
GL_ARB_invalidate_subdata
GL_ARB_multi_bind
GL_ARB_robustness
GL_ARB_separate_shader_objects
GL_ARB_texture_filter_anisotropic
GL_ARB_texture_storage
GL_ARB_texture_storage_multisample
GL_ARB_vertex_array_object
GL_EXT_direct_state_access
GL_KHR_debug
Using driver workarounds:
no-layout-qualifiers-on-old-glsl
nv-zero-context-profile-mask
nv-windows-dangling-transform-feedback-varying-names
nv-cubemap-inconsistent-compressed-image-size
nv-cubemap-broken-full-compressed-image-query
nv-compressed-block-size-in-bits

[mosra]

@Fleischner yes, this is unfortunately a bug in the Intel drivers on Windows ... it was fixed worked around with ece6eef in March, so not part of the stable 2019.01 release installed by Vcpkg. You can, however, install latest Git master, it behaves much better on Intel (this and half a dozen other Intel driver bugs was worked around) -- note you need to do this explicitly for all magnum-related projects so all repositories get the Git master:

vcpkg install --head corrade
vcpkg install --head magnum
vcpkg install --head magnum-integration
...

[Fleischner]

Thanks. Problem resolved.
And sorry for the inconvenience. I completly missed that they added an head option to vcpkg.

[mosra]

@Tryum anything left to be done here? :)

[Tryum]

I manage to get something working by hacking around.
I hope I'll have more time to make things cleaner in the next months or so.

[mosra]

Closing as it was independently confirmed this is not a problem anymore.