Windows, Intel(R) HD Graphics and Fly Mode: Bad GPU performance

[jonathanlinat]

System Information

TrenchBroom V2.1.0-RC1 on Windows 10

When I use the Right-Click + WASD or the Fly Mode, my GPU is saturated.

[kduske]

Is the performance any different on 2.0.6?

[jonathanlinat]

MovIng the mouse over the 3D viewport without holding any mouse buttons.

TrenchBroom V2.0.6, Windows 10

TrenchBroom V2.1.0-RC1, Windows 10

[kduske]

I can't reproduce this behavior on macOS. I'll try again later on Windows, but I doubt that I will be able to reproduce it there either. I'm afraid this might be a case of "works for me"...

[ericwa]

I tested on an Intel 4400. I can get 90% GPU utilization just moving the mouse over the default map with 1 brush. It seems tied to the viewport size, if I make it ~100px wide the gpu use only goes up to 30 or 40%.

Flying around ad_sepulcher.map on this laptop is sometimes smooth but it gets choppy after a few seconds of flying. If I leave it alone for 10 seconds it's smooth again.. might be thermal throttling?

I'm not sure what this means, unless the fragment shader to draw the void is really expensive.

[jonathanlinat]

I can confirm what @ericwa told about 3D viewport size vs. GPU performance.

[ericwa]

I think this is it: TB is not getting VSync on my Win10/Intel 4400 test system, and renders at around 200fps when moving the mouse over the window or right-click-drag looking around. On nvidia / Windows 10, it uses VSync and is capped at 60fps. Looking into enabling vsync explicitly..

[jonathanlinat]

[ericwa]

@jonathanlinat if you want to confirm, try this build where I added logging: https://ci.appveyor.com/api/buildjobs/nuqod8ou06qn408e/artifacts/cmakebuild%2FTrenchBroom-Win32-v2.1.0-RC1-18-gb2f54e1-Release.7z

This is what I get when moving the mouse around on my Nvidia system; it's clearly using vsync

[ericwa]

Ok, just adding wglSwapIntervalEXT(1); fixes the issue on my Intel test system. The gpu usage is around 25% instead of 90+% before.

Here is a build with the fix if you want to try it (still has the debug logging from the previous comment):

https://ci.appveyor.com/api/buildjobs/abgeanh4lfqkmdi3/artifacts/cmakebuild%2FTrenchBroom-Win32-v2.1.0-RC1-19-g64e676a-Release.7z

[kduske]

@jonathanlinat or just try to force vsync in your driver settings and see if that fixes the issue (for testing), as per https://www.intel.com/content/www/us/en/support/articles/000005552/graphics-drivers.html?_ga=2.186360801.990319321.1540704476-1338956147.1540673977

[jonathanlinat]

@ericwa Doesn't work.

@kduske My driver doesn't include this kind of option.

[jonathanlinat]

@kduske Nevermind, I found the option and I activated it. It works.

[kduske]

@ericwa it looks like your vsync build also doesn't have any effect even if the driver is set to "application defined"

[ericwa]

@jonathanlinat Thanks for trying. Just want to confirm, it was the b2f54e1 build that still had nearly 100% cpu? The previous one I posted g64e676a wasn't enabling vsync.

That's annoying because it worked on my Intel system, but I was testing on slightly older hardware (4400 vs 5500).

[jonathanlinat]

@jonathanlinat Thanks for trying. Just want to confirm, it was the b2f54e1 build that still had nearly 100% cpu? The previous one I posted g64e676a wasn't enabling vsync.

That's annoying because it worked on my Intel system, but I was testing on slightly older hardware (4400 vs 5500).

b2f54e1 didn't work. 64e676a worked. :+1: