Rendering issue on Linux with Intel HD

[mandre96]

**Version/Branch of Dear ImGui:dear imgui, v1.61 WIP
**

Hello, I'm using ImGUI to render a interface for a Graphics Engine Being develop at an university class, My professor share the tasks and we commit to a git our work, and I Just added the Debug and UI using the library.
The thing is, everything works perfectly at my two Computers: An Alienware M17xR4 running Windows 10, and an Desktop on 7970 Vaporx 6gb and Intel 5820k.

When I commited and my teacher and classmates pulled at the University PC's on Linux ThinkCentre m700 Intel® HD Graphics and in my teacher's notebook, also on Linux Intel IvyBridge and with Intel® HD Graphics, our Engine failed to show any UI from ImGUI.

Also, I really don't know if this really matters, but I'm getting an error while trying to destroy ImGui:
Assertion failed: GImGui != 0 && "No current context. Did you call ImGui::CreateContext() or ImGui::SetCurrentContext()?", file c:\users\marcosandre\documents\dmg\magma-engine\src\imgui\imgui.cpp, line 2671

wich is the

ImGuiStyle& ImGui::GetStyle()
{
    IM_ASSERT(GImGui != NULL && "No current context. Did you call ImGui::CreateContext() or ImGui::SetCurrentContext()?");
    return GImGui->Style;
}

Here is the Program window:

and the ImGui related code:

In the Engine init(void) which init all the data from the scene:

 if ( getDebugMode() )//Gets the current Engine Mode
		 {
			 ImGuiContext* ctx = ImGui::CreateContext();
			 ImGui::SetCurrentContext(ctx);

			 ImGui_ImplGlfwGL3_Init(_window, true);


			 ImGui::StyleColorsDark();
			 ImGui::CaptureKeyboardFromApp(false);
		 }

In the Engine loop(void):

while ( !glfwWindowShouldClose(_window) )
		{
			glfwPollEvents();
		
			
			SceneRoot->update();
			inputHandler->handle(camera.get());
			
			

			{
				_drawGui();
				
			}
			
			_render( _renderer );
			

			
			if ( getDebugMode() )
			{
				ImGui::Render();
				ImGui_ImplGlfwGL3_RenderDrawData(ImGui::GetDrawData());
			}
			

			glfwSwapBuffers(_window);

}

_And the drawGui() is just setting up booleans of the wireframes Abbs,SBBs,normals, the spotlight colors and the direction of the Directional light, plz let me know if you wanna see, But is rather big and I dont think is really related.
And the code wich causes the error mentioned before:

    void Engine::shutdown(void)
	{
		ResourceManager<Texture>::singleton().clear();

		if( _window )
		{
			if ( getDebugMode() )//causing the Memory Error
			{
				ImGui_ImplGlfwGL3_Shutdown();
				ImGui::DestroyContext();
			} //Tried Switching the order of calls but didn't matter.
		
			
			glfwTerminate();
			
			_window = nullptr;
		}
	}

Aniway thanks in advance for the amazing library and all the support. Greetings from Brazil!

[ebachard]

Hello,

If you follow the guidelines, there is no initialization problem on Linux. Maybe you missed some important information with recent ImGui version ?

FYI, the assertion you hit means you need to add:

ImGui::CreatedContext();

just after gl3wInit() // or glewInit(), if you use glew instead

and the line:

ImGui::DestroyContext();

At the end, in the cleanup, just before you quit the application.

Did you read #1599 ? Or imgui.cpp inline documentation ?

Nice to see more and more ImGui users :-)

[ocornut]

@mandre96 We don't have the right information to help you.

(A)
About rendering:

Linux driver ecosystem appears to be a mess, so the first thing you want to do is to check if the unmodified OpenGL2 and OpenGL3 demos provided with imgui works on that setup, to see if something else in your code is interfering.

If the demos works but the imgui in your engine doesn't render, then something is interfering with it and you'll want to disable parts of your rendering code until you find what. Your report here would be useful. The example back-ends are trying to setup all the graphics state they need and restore all the graphics state they modify, so in theory they have no impact on the OpenGL state... But in practice OpenGL state is so obstuse and fiddly that maybe there's a case we haven't caught.

It's also perfectly possible that just updating the drivers would fix something.

(B)
About the assert:

You say "I'm getting an error while trying to destroy ImGui", however GetStyle() isn't called by DestroyContext(), so your issue probably come from another bit of piece calling ImGui functions before context creation or after shutdown. When reporting an assert, please look and share the actual callstack (which your debugger should be able to provide you with).

[OvermindDL1]

Linux driver ecosystem appears to be a mess, so the first thing you want to do is to check if the unmodified OpenGL2 and OpenGL3 demos provided with imgui works on that setup, to see if something else in your code is interfering.

Actually it is pretty solid nowadays, even more so than windows. As an example, modern Intel and AMD 'drivers' are part of the kernel and Mesa now, but as Mesa is a reference renderer it demands that engines follow the spec, otherwise you get 'undefined behaviour'.

So if OP is using the latest Mesa (at least 16, but latest is best) and a recent kernel (at least 4.12 or so, but 4.15 or newer is best) then it should work perfectly if the code is following the GL spec.

As for the Intel drivers on windows, those are more questionable, they have a tendency to report that they can do things that they can't do if it is an older model, but if it is a newer model then if the spec is followed then they tend to work perfectly as well.

It's also perfectly possible that just updating the drivers would fix something.

But yep, for linux this goes back to making sure both the kernel (4.15 at least) and mesa (18.x at least) are updated.

(Before recent kernel and mesa versions both amd and intel used their own non-open-source drivers that were... less than great in their quality, kind of like how nvidia's closed source drivers on linux are pretty garbage in quality, though are fast. But both intel and amd open sourced their drivers and merged into mesa and the kernel now, significantly improving their stability and mesa mandates full and proper OGL compliance.)

When I commited and my teacher and classmates pulled at the University PC's on Linux ThinkCentre m700 Intel® HD Graphics and in my teacher's notebook, also on Linux Intel IvyBridge and with Intel® HD Graphics, our Engine failed to show any UI from ImGUI.

But yeah, make sure to tell them to make certain that both the kernel and mesa are up to date, especially if using intel or amd GPU's (nvidia's a crapshoot on whether it works well or not, when it works it works very well, when it doesn't it is very wtf'y).

[mandre96]

ebachard, as you can see I'm creating the context in the init Function, that's definetly not the problem!

[mandre96]

what i noticed is that for some reason calling shutdown does'nt seem to break the current state of the code, almost like the other function is running on a Thread WICH IS NOT! here is how I captured the input, because ImGUI kind of implements the GLFW3 callbacks, making my older one useless:

Any Ideas?

OCornut thanks for the reply, I'm going to ask them to do as you said and I'l report back with news!

[ocornut]

It looks like it's just a bug in your code and imgui isn't initialized at the time you are calling NewFrame for some reason. We'll let you figure that out on your side.

I'm not sure why you just changed the topic to inputs... You can install your callback and call the ImGuiGlfw callbacks from yours. The init function has a parameter to disable the Glfw callbacks if you need to.

Let's focus on the rendering aspect, will be waiting for your feedback here.

[mandre96]

Thanks Omar I'l look into it, I just maded a post in our class group explaining what every linux user should do(install the latest drivers, run the GL3 examples and change to glew as well) I'l give you guys feedback as soon as they answer, thank you!

[mandre96]

Omar, update, the GL3 Example works just fine! I'v been told by some friend that visual studio compiler can make some changes in memory and make things, that otherwise should'tn work, work! I will try to change to release and even compile on eclipse and check the results, I will come back with some more info. I will also try to think what in our Graphics Engine could be interfiring with the ImGUI that only repercutes on Linux, please if you can give some directions to where to look for this interference I will be very gratefull. I will report all my results so other people that go trhough something similar can have some light! Thanks in advance!

[ocornut]

Closing this as dangling random-opengl-drivery-backendey issue lacking enough details.
May or not apply any more today.