Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: OpenGL on Windows (high CPU usage)

  1. #11
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,955
    Quote Originally Posted by johne53 View Post
    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.
    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.

    Quote Originally Posted by johne53 View Post
    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.
    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.

  2. #12
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,511
    Quote Originally Posted by johne53 View Post
    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
    Try a different browser. Firefox works.

  3. #13
    Junior Member Newbie
    Join Date
    Oct 2018
    Posts
    9
    Quote Originally Posted by Dark Photon View Post
    Try a different browser. Firefox works.
    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?

  4. #14
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,511
    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.

  5. #15
    Junior Member Newbie
    Join Date
    Oct 2018
    Posts
    9
    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..?)

  6. #16
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,511
    Quote Originally Posted by johne53 View Post
    But I've installed the latest driver from NVidia (and yet I'm still seeing very poor OpenGL performance).
    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?
    Last edited by Dark Photon; 10-14-2018 at 05:04 PM.

  7. #17
    Junior Member Newbie
    Join Date
    Oct 2018
    Posts
    9
    Quote Originally Posted by Dark Photon View Post
    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?
    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

  8. #18
    Junior Member Newbie
    Join Date
    Oct 2018
    Posts
    9
    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

    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?

  9. #19
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,511
    Quote Originally Posted by johne53 View Post
    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?
    See this post by Detlef Roettger (NVidia):

    Re: Where OpenGL 2.1 located in the driver package

    Quote Originally Posted by Detlef Roettger
    This is not how OpenGL under Windows works.

    The opengl32.dll and opengl32.lib come from Microsoft and you need to link against that.
    The DLL contains Microsoft's software OpenGL 1.1 implementation as well as the mechanism to load OpenGL "Installable Client Drivers" (ICD) which get installed on your system along with the display drivers for your graphics board. These vendor specific ICDs implement newer OpenGL versions for your GPU.

    What you do inside your application is to link against Microsoft's opengl32.lib which loads the opengl32.dll which then loads the GPU vendor's installable client driver at runtime.
    Everything from then on is a matter of enumerating the OpenGL pixelformats and selecting the one which uses the OpenGL implementation you want your application to run on.

    Additionally using any functionality beyond OpenGL 1.1 under Windows requires to get the OpenGL entry point function pointers added to these versions. Similarly for OpenGL extensions.
    To ease that work there are utility libraries like GLEW http://glew.sourceforge.net/ which take care of getting all available entry point function pointers with a few calls in your application.
    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. 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.
    Last edited by Dark Photon; Today at 06:06 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •