Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eframe on Windows high CPU usage due to excessive calls to glutin::context::make_not_current #4173

Open
gerwin3 opened this issue Mar 15, 2024 · 6 comments · Fixed by #4284
Labels
native-windows Running on native Windows OS performance Lower CPU/GPU usage (optimize)

Comments

@gerwin3
Copy link

gerwin3 commented Mar 15, 2024

I noticed that my application CPU usage was much higher than expected on Windows. On a similar machine I was seeing 1%-2% usage on Linux, and around 20%-30% on Window while moving the mouse in window (just mouse movement).

After some optimization I got my rendering loop down to less than 1ms and still the CPU usage was too high. I then sampled the CPU with https://github.com/nico-abram/blondie/tree/main and this is the flamegraph that it produces:

As you can see, almost 90% of the time, it is calling the make_not_current function, which seems really excessive...

EDIT: I found in the docs here that this call flushes the rendering context so probably rendering is just very slow... Still not sure why though.

Screenshots

image

Another flamegraph with Windows Performance Analyzer (similar results):

image

This shows the call stack a bit deeper:

  • opengl32d.dll wglMakeCurrent
  • opengl32d.dll bMakeNoCurrent
  • opengl32d.dll wglMakeCurrent
  • opengl32d.dll wglMakeCurrent
  • opengl32d.dll wglMakeCurrent
  • KernelBase SetEvent

Desktop (please complete the following information):

  • OS: Windows
  • Version: egui 0.26
@emilk
Copy link
Owner

emilk commented Mar 19, 2024

I think this was introduced in #3172 when we added support for multiple viewports. When there are multiple viewports we need to switch to which has the "current" gl context, and we unfortunately pay this cost even when there is only one viewport, but that should be fixable.

@gerwin3
Copy link
Author

gerwin3 commented Mar 20, 2024

Is there a workaround for now (i.e. options to disable multi-viewport)? (Apart from reverting to an older version)

emilk added a commit that referenced this issue Apr 1, 2024
…since it is reportedly broken on Windows

* Early-out added in #4284
* Re-opens #4173 😭 
* Closes #4289
* Closes #4290
@emilk emilk reopened this Apr 1, 2024
@emilk
Copy link
Owner

emilk commented Apr 1, 2024

This is still an issue on Windows.

If someone wants to work on this, please take a look at

@gerwin3
Copy link
Author

gerwin3 commented Apr 3, 2024

Seems that the reverted fix (#4284), even when it wasn't reverted before still did not fix the issue. CPU load does not noticeably decrease and still hovers around 30% on my machine in the hello_world example.

@emilk
Copy link
Owner

emilk commented Apr 3, 2024

@gerwin3 With a single viewport or multiple?

In either case: I suggest if you want this fixed you start rolling up your selves ;)

Maybe start verifying wether or not this was introduced in #3172

@emilk emilk added performance Lower CPU/GPU usage (optimize) native-windows Running on native Windows OS and removed bug Something is broken labels Apr 3, 2024
@gerwin3
Copy link
Author

gerwin3 commented Apr 3, 2024

With a single viewport... yeah I took a spin at it but didn't get far yet. Will report back if I find something

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
native-windows Running on native Windows OS performance Lower CPU/GPU usage (optimize)
Projects
None yet
2 participants