Re: OpenGL driver consumes 100% CPU

On Dec 2, 2:52 am, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Nov 27, 12:47 am, David Barrett-Lennard <davi...@xxxxxxxxxxxx>
wrote:

According to the windows task manager on my dual core machine both
processors are 100% utilised while this window is displayed

This is because you have given the computer a time slice that is too
small to be used.

My understanding is that the time slice given to a thread by the
scheduler is of the order 10-100 msec. However, the overhead of a
context switch is /much/ smaller - typically only a few microseconds.

The code I posted uses a timer that runs every 15 msec, just to
illustrate the problem. In my actual application a similar problem
arises when every WM_MOUSE_MOVE event invalidates the scene, and I
presume that's typical of many applications.

My particular concern is that the background threads (which run at
lower priority than the main GUI thread) aren't getting fair use of
the CPU.


When I comment out the call to glFinish the CPU usage drops from 100%
to exactly 50% suggesting that at any given time one processor is
fully occupied within SwapBuffers(). Does this suggest the OpenGL
driver is using a spin lock?

No. It may be using an adaptive lock. Again, however, it's the same
problem. You have given the OS an amount of time that is too small.

Are you suggesting that any application that wants to render frames at
60Hz will inevitably hog the CPU because that rate of context
switching isn't economical?


If the timer period is increased from 15 msec to 17 msec the total
processor activity drops from 100% down to about 3%. Presumably this
has something to do with the synchronisation with the screen refresh.

It may be, it may also be simply that the time interval is less than
the OS can reasonably use.

I strongly suspect it is waiting for the vsync. At 60Hz this would be
every 16.67msec.


Suppose you slept for 5 microseconds. Would you expect the OS to
schedule another process, knowing you want the CPU back in 5
microseconds? Unless it has no choice, it makes much more sense just
to keep your process scheduled, especially if no other process wants
the CPU.

Yes I agree for 5 microseconds. But not for 15 msec (which is 3000
times longer!)


Is it reasonable for the OpenGL driver to consume the CPU like that?

That's what CPU is for, when nobody else wants it. Is there any point
in the OS bothering to switch to the idle process just to have to
switch back a few milliseconds later?

Of course, if there is no other process wanting the CPU.

.

Relevant Pages

  • Re: Blocking read() policy?
    ... >> It doesn't require any particular advanced scheduler. ... Especially if pgms demanding short latency ... that a CPU intensive process would ... starts over with the shortest possible time slice. ...
    (comp.os.linux.development.system)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: fixed time slices?
    ... | to finish using its time slice), and assigns a full time slice ... become ready to run, and be scheduled on a CPU, when the scheduler is ... So it could put the CPU on ... the timer frequency. ...
    (microsoft.public.win32.programmer.kernel)
  • [RFC] dynsched - different cpu schedulers per cpuset
    ... the ability to switch the cpu scheduler of the linux kernel at runtime. ... The project is hosted on Sourceforge and the current patch applies ...
    (Linux-Kernel)
  • One minute delay when booting 2.6.24.1
    ... Switched to high resolution mode on CPU 1 ... io scheduler anticipatory registered ... # Infrared-port device drivers ...
    (Linux-Kernel)
Loading