Low frame rate with NVidia Laptop (Win Vista/7/8/8.1/10)

[Rachael]

If you have a recent-ish NVidia laptop (2014 or later or so, possibly earlier), chances are it uses a system called "Optimus" (name is literally derived from the character Optimus Prime in Transformers apparently in reference to its flexibility - some of NVidias various internal code references this).

Unfortunately with the new Desktop Window Manager introduced in Windows Vista and forced to be in use from Windows 8 on, Optimus interacts awfully with this program.

There is, unfortunately, no solution to this problem! However, there are several work-arounds you may want to try:

If you're running Windowed mode (NOT borderless):

Workaround 1: In GZDoom, you can turn off VSync and enforce a framerate cap instead. You may use the console for this:

Code: Select all

vid_vsync false
vid_maxfps 59

The actual FPS will be 63 or so, because of how the timing code works, but it works. DWM.exe enforces VSync, anyhow, unfortunately.

If you're using Borderless and/or Fullscreen:

Workaround 2: GZDoom functions better when VSync is forced on, with Optimus in either fullscreen mode.

Code: Select all

vid_vsync true

This will work regardless of windowed setting (but only works for OpenGL):

Workaround 3: You can force GZDoom to use your Intel processor. This is, again, accomplished with the console as follows:

Code: Select all

vid_gpuswitch 2

Set it to 0 to use the default again, or to let NVidia decide. NOTE: This solution has no effect on Vulkan.

Works ONLY in Windows Vista or 7

Workaround 4: You may disable the Desktop Window Manager. This can be done by using the Start menu, and typing "services.msc" into the search box and pressing Enter. Afterwards, look for "Desktop Window Manager Session Manager" in the service list, and stop the service. If you wish this change to be permanent, you can set the service to be disabled (not recommended). Note that this will cause Windows to disable the glass borders and switch to a "basic" theme, which many people do not like. You will have to personalize your desktop to use a different theme if you do not like this.

[Rachael]

If you've gotten this far reading this, you're probably wondering what in the living hell "Optimus" is and why it's so shitty with newer versions of Windows. I will attempt to answer that for you, here.

Without getting too gritty and technical, Optimus is a system that allows your NVidia chip to literally "draw" onto another graphics processor. In Leyman's terms, imagine that you're a better artist, but you have to use someone else's sketch pad because you have none of your own. Optimus-enabled laptops work like this.

The problem here is that the other graphics processor, the Intel, which actually shows your screen, is getting VSync timings at different times than your NVidia processor is. Normally this is not an issue, unless the drawing has to be buffered (i.e. it doesn't happen immediately, DWM gives the NVidia drawer a canvas to draw on instead of drawing directly to the screen). So you basically have proxy-of-a-proxy drawing. By the time it finally hits the Intel chip to be shown, it's already a frame late and it's quite likely a new VSync signal has already hit. DWM will only work on your Intel processor and get its VSync timings - whereas GZDoom will get NVidia's VSync timings - and therein lies the issue. So DWM thinks it needs to wait another frame to show a frame that GZDoom already drew for *this frame* - and that causes a noticeable frame lag, and because the timings are not sync'd, it looks like it stutters even if it really doesn't. In fact, it's completely random every frame whether it's stuck waiting for the next frame, or drawing on this one. And it looks like shit as a result.

It could easily be fixed by Microsoft if they introduced some way to turn off VSync syncing with DWM.exe, or if they allowed you to switch its VSync timing to the NVidia chip. But since they do not care enough about this issue to do anything at all about it, this is the situation we are stuck with.

[Graf Zahl]

I don't know why you blame Microsoft. To me it sounds like DWM is doing what it should, i.e. sync with the actual display adapter. This sounds to me like a shitty implementation by NVidia, whose driver poorly supports this setup. If the display is handled by the Intel chip, the secondary graphics ship should have no business reporting its own VSync state to the app.

[dpJudas]

I'd say there's plenty of blame to around.

Microsoft for locking OpenGL in 1.6 land with an ICD driver model from Windows 3.11 for Workgroups or something. I.e. the reason you can't select a GPU device is because MS effectively refuses to update OpenGL32.dll to support multiple ICD's. The DWM implementation itself is also pretty crap with the DWM failing to present a vsync flipped OpenGL frame once every few seconds on basically all systems.

Nvidia and Intel for selling a solution that's ultimately going to be shit.

[Rachael]

One of the primary reasons that I put a lot of blame on Microsoft for this is because DWM never needed to have VSync forced on without offering the user an option to flip it off. Windows never needed to be programmed so that it would require a DWM at all times - and they did not offer a non-compositing DWM system that wouldn't require VSync to be forced on in the first place.

[Graf Zahl]

I'd say there's plenty of blame to around.

Microsoft for locking OpenGL in 1.6 land with an ICD driver model from Windows 3.11 for Workgroups or something. I.e. the reason you can't select a GPU device is because MS effectively refuses to update OpenGL32.dll to support multiple ICD's. The DWM implementation itself is also pretty crap with the DWM failing to present a vsync flipped OpenGL frame once every few seconds on basically all systems.

And yet...
... compared to the implementations on other platforms it's still better. Just look at Apple who refuse to upgrade their OpenGL support at all and do not allow the graphics hardware manufacturers to provide up to date drivers.
Or look at that bug report of a Linux driver only half-implementing a feature so it could be bulletpointed on the cover - screw that it's useless in that form.
[/quote]

Nvidia and Intel for selling a solution that's ultimately going to be shit.

That one I fully agree with. To be blunt: If you want to sell a hardware solution, make sure it works with the operating system that's supposed to be run on it, goddamnit!

[dpJudas]

And yet...
... compared to the implementations on other platforms it's still better. Just look at Apple who refuse to upgrade their OpenGL support at all and do not allow the graphics hardware manufacturers to provide up to date drivers.
Or look at that bug report of a Linux driver only half-implementing a feature so it could be bulletpointed on the cover - screw that it's useless in that form.

I don't think that is a fair comparison for a couple of reasons. First, Microsoft can't ban OpenGL support from drivers, like Apple does, as it would get them hit by antitrust laws. Other than that, though, they have been doing exactly the same as Apple is doing lately: treat it as complete abandonware and not fix a single thing in their part of the codebase. The only thing that saves OpenGL on Windows is that wglGetProcAddress allows the driver to add it all without Microsoft's help. Ever since they introduced Direct3D they haven't done a single thing for OpenGL.

As for Linux, that's only a problem if you insist on using crappy Mesa-based hardware. The Nvidia OpenGL driver is just as feature complete on Linux as it is on Windows. It is AMD and Intel that is investing borderline nothing into their Linux drivers that causes all the problems there. That, and certain principles among Linux distributions about not helping corporations unless they fully GPL everything.

[Graf Zahl]

Other than that, though, they have been doing exactly the same as Apple is doing lately: treat it as complete abandonware and not fix a single thing in their part of the codebase.

You know what: Thank god they left it to the graphics card makers! Otherwise it'd either be stuck in a time loop like on Apple or be used as an upgrade weapon like Direct3D. The same goes for Vulkan, btw. That got into Windows without Microsoft doing anything at all!

As for Linux, that's only a problem if you insist on using crappy Mesa-based hardware. The Nvidia OpenGL driver is just as feature complete on Linux as it is on Windows. It is AMD and Intel that is investing borderline nothing into their Linux drivers that causes all the problems there. That, and certain principles among Linux distributions about not helping corporations unless they fully GPL everything.

A problem is a problem, regardless of who is ultimately responsible. And the rise of those crappy Mesa drivers has certainly made things a lot worse because for that hardware OpenGL now appears to be under control of some imbeciles.

[dpJudas]

You know what: Thank god they left it to the graphics card makers! Otherwise it'd either be stuck in a time loop like on Apple or be used as an upgrade weapon like Direct3D. The same goes for Vulkan, btw. That got into Windows without Microsoft doing anything at all!

That doesn't change the fact that Microsoft shouldn't be credited with the higher quality of OpenGL on Windows. Because their part of that contribution is to lock OpenGL to 1.6 forever. I'm quite sure its "mysteriously" banned on UWP apps, although I haven't bothered to verify if they ever lifted such a ban. As far as Microsoft is concerned, it is a feature that the Intel/Nvidia sync code is having difficulties - after all, they should be using Direct3D those damn GZDoom developers!

As for Vulkan, once again, the antitrust is the only thing allowing it. Strangely enough, their new walled-garden edition does not.

A problem is a problem, regardless of who is ultimately responsible. And the rise of those crappy Mesa drivers has certainly made things a lot worse because for that hardware OpenGL now appears to be under control of some imbeciles.

Sure, but that means we must judge Windows' OpenGL support by AMD and Intel's drivers. Otherwise it isn't an apples to apples comparison. Yes, they are less shit on Windows - but only barely.

[Graf Zahl]

You know what: Thank god they left it to the graphics card makers! Otherwise it'd either be stuck in a time loop like on Apple or be used as an upgrade weapon like Direct3D. The same goes for Vulkan, btw. That got into Windows without Microsoft doing anything at all!

That doesn't change the fact that Microsoft shouldn't be credited with the higher quality of OpenGL on Windows. Because their part of that contribution is to lock OpenGL to 1.6 forever. I'm quite sure its "mysteriously" banned on UWP apps,

I never credited Microsoft, but the fact remains that other companies have done far, far worse here. And regarding UWP: The Microsoft AppStore was modelled after Apple with all the same bullshit. The only difference being that they simply cannot afford to be as rabid as Apple in trying to enforce its use.

although I haven't bothered to verify if they ever lifted such a ban. As far as Microsoft is concerned, it is a feature that the Intel/Nvidia sync code is having difficulties - after all, they should be using Direct3D those damn GZDoom developers!

The problem here clearly lies with a driver that is poorly integrated into the system it's supposed to run on. Microsoft made the system and laid out the specs, NVidia chose to ignore them and as a result stuff doesn't work right. It only shows that it's not just Microsoft who considers OpenGL a second class citizen. I'm actually wondering if Vulkan works better on that hardware, because that is an API the graphics card makers actually have an interest in succeeding.

As for Vulkan, once again, the antitrust is the only thing allowing it. Strangely enough, their new walled-garden edition does not.

Yeah, the "walled garden" again. One property of walled gardens is that the wall's builder controls everything what's inside, and God forbid to let an external driver provide some API that may undermine the wall. Does this really come as a surprise? Apple showed how these things get done and Microsoft ineptly copies all of it.

Sure, but that means we must judge Windows' OpenGL support by AMD and Intel's drivers. Otherwise it isn't an apples to apples comparison. Yes, they are less shit on Windows - but only barely.

At least they work. Which is more than could be said 8-10 years ago. Oh the irony. Once upon a time Windows was considered the problem child of OpenGL support but by now both macOS and Linux with AMD/Intel have fallen hopelessly behind...


All that daid, I actually have no illusions here. Unless we get a Vulkan renderer up and running I see increasing problems in the future because OpenGL will inevitably decline in quality across the board. For all intents and purposes it's already a legacy API that's slowly deteriorating.

[dpJudas]

At least they work. Which is more than could be said 8-10 years ago. Oh the irony. Once upon a time Windows was considered the problem child of OpenGL support but by now both macOS and Linux with AMD/Intel have fallen hopelessly behind...

Hehe, on that we can only agree.

By the way, on that storage buffer thing - I think we only use storage buffers in the fragment shader (for lights). So it is actually complaining about dead code it could optimize away (in the vertex shader). I need to take a look at that code again - think its not too hard to do on our side.

[Chris]

At least they work. Which is more than could be said 8-10 years ago. Oh the irony. Once upon a time Windows was considered the problem child of OpenGL support but by now both macOS and Linux with AMD/Intel have fallen hopelessly behind...

AMD's and Intel's drivers on Linux could hardly be called "working" back then. If you wanted 3D gaming on Linux 10 years ago, it wasn't a question that you needed nVidia (which has comparable OpenGL support between Linux and Windows), AMD's and Intel's proprietary drivers were hopelessly broken with constant crashes, lying about supported features (actual broken behavior, not just hiding behind a technicality of the spec), or missing functionality that the hardware did support. Commercially, a number of OpenGL games never got ported to Linux with the developers specifically mentioning how it wouldn't work on AMD's Linux drivers and they didn't want to only support nVidia users.

These days, MESA has really caught up. AMD is a viable option now with the open source drivers.

[Major Cooke]

I'm tempted to suggest including that information in a side text file for future releases but that may snowball and soon require a detailed users guide in a document.