OpenGL on Windows (high CPU usage)

#1

Hi there, I help develop an open-source DAW called Mixbus

Like most DAW’s it supports plugins. On Windows, the most common format (for audio plugins) is VST although others also exist (AAC / LV2 / LUA and a few others).

Many of our users have complained about very high CPU usage when launching certain plugins. If the CPU is normally running at 10%, launching just 1 x instance of the plugin will make that shoot up to 30%. A 2nd instance increases it to 50% and so on. Before long (with just a few plugins open) the whole app will crash.

After 2 months of testing we’ve finally realised that the common factor (for all the affected plugins) is that they all use OpenGL. And yet I thought the whole point of OpenGL was to use hardware acceleration (and therefore minimize CPU usage)?

Does OpenGL simply not work on Windows? Or could the plugin devs be misusing it somehow (or misunderstanding it maybe)? Or is there more to all this than simply installing OpenGL drivers and hoping it’ll all work?

#2

[QUOTE=johne53;1292725]…open-source DAW called Mixbus … supports plugins.
Many of our users have complained about very high CPU usage when launching certain plugins.
1 x instance of the plugin will make that shoot up to 30%.
A 2nd instance increases it to 50% and so on.

After 2 months of testing we’ve finally realised that the common factor (for all the affected plugins) is that they all use OpenGL.[/QUOTE]

That’s an interesting data point. But now you need to look deeper for correlations beyond that.

And yet I thought the whole point of OpenGL was to use hardware acceleration (and therefore minimize CPU usage)?

OpenGL is just an API. By itself, it doesn’t do anything and can’t cause performance problems. It’s a spec.

Graphics drivers (from the GPU vendors, CPU vendors, and 3rd parties) develop graphics drivers that implement that spec. Users develop applications that sit on top of those drivers to make use of GPUs and CPUs via the graphics driver (yes, CPUs; some graphics drivers run on the CPU). These drivers, the apps that sit on top of them, and the underlying hardware are what determine the performance, good or bad.

Does OpenGL simply not work on Windows?

Some vendors’ graphics drivers and GPUs work exceptionally well on Windows. Performance problems can sometimes be driver related. However…

It’s more common for graphics performance problems to come from inefficient usage of the OpenGL API from the application (the plugins in this case).

Or could the plugin devs be misusing it somehow (or misunderstanding it maybe)?

This seems more likely. In any case, what you’re looking for is correlations between specific graphics drivers and/or app plugins with the performance problem you’re seeing. Then you can dig deeper and see why that correlation exists.

You can go a long way toward identifying these correlations by capturing, in addition to the plugin names and versions, the graphics driver names and versions and the underlying GPU or CPU being used. For information on how to do this, see the GL_RENDERER, GL_VENDOR, and GL_VERSION string queries here:

[ul]
[li]OpenGL_Context#Context_information_queries [/li][/ul]
After creating a GL context, you can make these queries and log the results. To get a sample of what some of the GL_RENDERER and GL_VERSION strings look like, see this link:

[ul]
[li]gpuinfo.org : OpenGL Reports [/li][/ul]

#3

Thanks for the info and links (I’ll try them a bit later…)

I’m working on Windows - but in the meantime, one of the Linux devs just told me that (for Linux) it usually isn’t enough to just install the OpenGL drivers. There’s usually some kind of app to launch (presumably from the card manufacturer?) which will check for hardware acceleration and allow you to activate or deactivate it (i.e. the OpenGL driver won’t necessarily do this automatically) Any idea if there’s something similar needed on Windows?

I’m using NVidia GeForce graphics (8400GS). It’s old by modern standards but it supports hardware acceleration AFAIK.

#4

I’m not an expert there, but I have read that if the graphics drivers aren’t installed properly on Windows, it can fall back to Microsoft’s GDI implementation, which implements OpenGL 1.1 on the CPU (not on the GPU):

[ul]
[li]Platform_specifics:_Windows#The_Default_Renderer [/li][li]gpuinfo.org report for Microsoft GDI OpenGL 1.1 Fallback driver [/li][/ul]

Hopefully someone with more knowledge here will chime in. Most GL apps nowadays won’t even function on that driver, but if they do, the performance will be poor.

Also, my vague recollection is that on Windows if the app requests a pixel format for the window that the GPU driver doesn’t support, Windows will fall back to using Microsoft’s OpenGL 1.1 GDI driver rather than the GPU vendor’s graphics driver.

#5

Thanks again Dark Photon. I’ve only just woken up over here but I’ll follow those links after I’ve had some breakfast !

BTW - I’d also read about problems with the standard Microsoft driver so just before posting here, I installed NVidia’s official driver (which tells me I’m now running OpenGL ver 3.3).

I’ll also check if there’s an NVidia forum somewhere. Maybe that’d be the best place to find out if my card supports hardware acceleration (and how to check if it’s enabled).

Thanks again for all your help.

P.S. - message to the forum moderators… your Captcha app doesn’t seem to work with Internet Explorer :dejection:

#6

Sounds good. Are you able to repro the perf issue with some plugins on that system? Just keep in mind that that GPU is 11 years old (which is ancient in GPU terms).

I’ll also check if there’s an NVidia forum somewhere.

There are these two that I know about:

[ul]
[li]https://devtalk.nvidia.com/ [/li][li]https://forums.geforce.com [/li][/ul]
However, I’ve generally gotten better responses to my OpenGL and GPU-related questions here than on the NVidia forums. Plus you can’t beat this site for the awesome search history (OpenGL-related posts going back to the early 2000s). So don’t feel like you can’t post in both places (here and on one of their forums).

Maybe that’d be the best place to find out if my card supports hardware acceleration (and how to check if it’s enabled).

Pretty much any NVidia GPU is going to support hardware acceleration, and their drivers are of excellent quality IMO. As an easy first check, you can see if someone else has submitted an entry for the GPU/driver here:

[ul]
[li]https://opengl.gpuinfo.org [/li][/ul]
Just type in the GPU model name in the “Renderer” column. This can also be a useful reference, though it doesn’t directly answer your question:

[ul]
[li]List of NVidia Graphics Processing Units (wikipedia) [/li][/ul]
However, probably the best test is to go to the NVidia driver download page:

[ul]
[li]NVIDIA Driver Downloads [/li][/ul]
select your GPU and OS, and see if you can download drivers for it.

P.S. - message to the forum moderators… your Captcha app doesn’t seem to work with Internet Explorer :dejection:

I sent an IM to the admin about this. Thanks for the heads-up!

#7

Perhaps time to move to MS Edge? :slight_smile:

#8

Hmmm… no matter what I type in the Renderer column, I just see an error message saying:- Warning: mysql_fetch_row() expects parameter 1 to be resource, Boolean

Yes, I did that a couple of days ago - and I also found from somewhere (here maybe?) a utility called the OpenGL Extensions Viewer. That utility gives me lots of information about the status of OpenGL on my system but the one thing it doesn’t seem to tell me is whether my OpenGL driver is making use of the hardware acceleration features offered by my card. Given how important this is for OpenGL I’m quite amazed that it’s so difficult to find this out… :tired:

#9

There’s no point in asking the driver that question, since it can basically lie anyway and you’d never know.

You should assume (for core OpenGL features) that if the implementation supports something, then it does so as fast as it could support it. That may not always be true, but it’s a good enough starting point.

Your problem is that essentially someone else is slowing down your program (possibly due to pathological use of an API) and you have no way to stop them. That’s not really a problem you can query a driver to resolve.

#10

Thanks Alfonse - if the problematic plugins all came from the same manufacturer I’d be inclined to agree with you but in fact, they come from different sources. The common factor is that the problematic ones all use OpenGL.

To me, this suggests that something about OpenGL isn’t working as it should. And when I see a big surge in CPU activity (as each OpenGL window opens) it suggests that maybe they aren’t using hardware acceleration for some reason. I’d just hoped there’d be a way to find out.

#11

Does the application provide a framework for plug-ins to use OpenGL? Or at least for them to use the windowing API? Windowing APIs generally don’t lend themselves to being used by multiple subsystems of a single application without any form of centralised management.

If this is consistent across a wide range of different hardware, I’d tend to assume that it’s something about either the application itself or a common framework which the OpenGL-based plug-ins are using.

It’s possible for individual systems to fall back to the software implementation, e.g. if drivers aren’t installed correctly. But Windows’ software OpenGL implementation only supports OpenGL 1.1; it certainly doesn’t support shaders, which I’d assume any kind of audio plug-in is going to require (fixed-function OpenGL wouldn’t be of much use, unless you’re talking about visualisation plug-ins: spectral plots, etc).

In the absence of anything obvious, you’ll need to use a profiler to find out exactly where the CPU load is coming from.

#12

[QUOTE=johne53;1292735]Hmmm… no matter what I type in the Renderer column, I just see an error message saying:- Warning: mysql_fetch_row() expects parameter 1 to be resource, Boolean
[/quote]
Try a different browser. Firefox works.

#13

Aha, I found it… the trick is to type in the required text - but NOT to type a carriage return at the end!

BTW guys, something occurred to me this morning. Suppose I ran our application from a Windows Command Prompt. Would OpenGL print out any kind of error message if it fails to use hardware acceleration for some reason?

#14

No, not necessarily.

One good option is to print out GL_VENDOR, GL_RENDERER, and GL_VERSION to see if you end up getting “Microsoft Corporation”, “GDI Generic”, and … If you do, you should probably just refuse to use OpenGL on that machine because the user hasn’t installed graphics drivers on it properly.

#15

But I’ve installed the latest driver from NVidia (and yet I’m still seeing very poor OpenGL performance).

I wonder if OpenGL generates a log file that I could examine? (or maybe there’s an app that’ll do this…?)

#16

Badly behaved applications can end up forcing use of the Microsoft software driver, even if the GPU graphics drivers are installed properly.

Some applications may actually force use of the wrong libraries as well by including them in application directories. I would look to make sure there are no OpenGL libraries lying around in the app directories.

I wonder if OpenGL generates a log file that I could examine? (or maybe there’s an app that’ll do this…?)

OpenGL itself is an API defined in a spec, and so can’t itself generate a log file. Some graphics drivers and/or apps might however. You could make your application write a log for instance. After creating a GL context, consider printing the string variables associated with those tokens I mentioned.

On this PC, are you seeing poor performance in general with some common OpenGL applications (e.g. games), or with plugins using your application in particular? What common applications have you tried?

#17

Hi Dark Photon. Our product is a digital audio workstation (DAW) which doesn’t use OpenGL itself. Like most DAW’s though, it allows users to load 3rd-party plugins. These are DLL’s (almost always closed source) which offer various audio effects - such as reverb / chorus / EQ and so on. Users have been complaining that some plugins (admittedly a minority) are producing a huge increase in CPU usage when launched.

After some investigation I realised that it’s not the plugins themselves which overload the CPU - it’s their GUI window. Whenever their GUI window is visible, CPU loading shoots up and then returns to normal again if we close the GUI window (but leave the plugin running). The plugins come from different manufacturers but after further investigation I’ve realised they do have something in common… the plugins which exhibit this behaviour invariably use OpenGL.

My suspicion is that OpenGL sometimes isn’t making use of hardware acceleration for some reason - but we don’t have access to the plugin code, so I’d been hoping there might be some OpenGL utility (or a log file or whatever) which I could use to check this. Ultimately though, I guess we’ll just have to tell users to avoid those particular plugins. Thanks for everyone’s help with this

#18

One more question… I’ve found a range of audio plugins called Blue Cat which use OpenGL but which don’t seem to suffer from the high CPU usage :smiley:

I guess there’s a possibility they’re just designed better but maybe these ones are using hardware acceleration when the others aren’t. This brought something else to mind… What decides whether or not an OpenGL app can use hardware acceleration? Does the OpenGL driver handle this invisibly? Or does the app need to ‘request’ hardware acceleration somehow?

#19

See this post by Detlef Roettger (NVidia):

Re: Where OpenGL 2.1 located in the driver package

From what I understand, it is Microsoft’s DLL that determines if and when to load a specific ICD graphics driver for a GPU.

I do know that when the app does things like choose pixel formats for the DC used to create a GL context that are not supported by the GPU’s ICD, it will cause a fallback to Microsoft’s software OpenGL 1.1 implementation. So there is apparently some logic within Microsoft’s OpenGL library and handshaking with the ICD which determines whether the ICD can support the application’s request.

Where I’ve personally hit this before is with rogue code that requests a 32-bit depth buffer in the pixel format set on the DC used to create a GL context to be associated with an on-screen window. On Win7 with NVidia GL drivers installed, this will force a fallback to Microsoft’s software OpenGL 1.1 implementation rather than use of NVidia’s GL driver.

#20

That’s a great explanation from Detlef and many thanks to Dark Photon for finding it.