8000 Windows, Intel(R) HD Graphics and Fly Mode: Bad GPU performance · Issue #2369 · TrenchBroom/TrenchBroom · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
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

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

Closed
jonathanlinat opened this issue Oct 22, 2018 · 15 comments
Closed

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

jonathanlinat opened this issue Oct 22, 2018 · 15 comments
Assignees
Labels
Prio:3 Low priority: Minor problems and nice to have features
Milestone

Comments

@jonathanlinat
Copy link
Contributor

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.

trenchbroom_2018-10-22_18-39-54

@jonathanlinat jonathanlinat changed the title Windows, Intel Graphics HD and Fly Mode: Bad GPU performance Windows, Intel(R) HD Graphics and Fly Mode: Bad GPU performance Oct 22, 2018
@kduske
Copy link
Collaborator
kduske commented Oct 23, 2018

Is the performance any different on 2.0.6?

@kduske kduske added this to the 2.1.0 milestone Oct 23, 2018
@kduske kduske added OS:Win Prio:3 Low priority: Minor problems and nice to have features labels Oct 23, 2018
@jonathanlinat
Copy link
Contributor Author

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

TrenchBroom V2.0.6, Windows 10

image

TrenchBroom V2.1.0-RC1, Windows 10

image

@kduske
Copy link
Collaborator
kduske commented Oct 23, 2018

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
Copy link
Collaborator
ericwa commented Oct 23, 2018

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
Copy link
Contributor Author
jonathanlinat commented Oct 23, 2018

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

image

image

image

@ericwa ericwa self-assigned this Oct 23, 2018
@ericwa
Copy link
Collaborator
ericwa commented Oct 28, 2018

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
Copy link
Contributor Author

image

@ericwa
Copy link
Collaborator
ericwa commented Oct 28, 2018

@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
capture

@ericwa
Copy link
Collaborator
ericwa commented Oct 28, 2018

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
Copy link
Collaborator
kduske commented Oct 28, 2018

@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
Copy link
Contributor Author
jonathanlinat commented Oct 28, 2018

@ericwa Doesn't work.

image

image

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

@jonathanlinat
Copy link
Contributor Author

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

image

@kduske
Copy link
Collaborator
kduske commented Oct 28, 2018

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

@ericwa
Copy link
Collaborator
ericwa commented Oct 28, 2018

@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
Copy link
Contributor Author

@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. 👍

trenchbroom_2018-10-28_22-50-49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Prio:3 Low priority: Minor problems and nice to have features
Projects
None yet
Development

No branches or pull requests

3 participants
0