Re: OpenGL driver consumes 100% CPU

On Dec 4, 3:45 am, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Dec 2, 10:17 am, David Barrett-Lennard <davi...@xxxxxxxxxxxx>
wrote:

You claim there's no point bothering to switch to the idle process.
Of course but so what? How is such a scenario relevant to my case
where there is useful low priority, on going work to be done by the
CPU?

Unfortunately, one most operating systems, priority is too coarse a
tool. The operating system presumes that if a higher-priority thread
is ready-to-run, you would prefer it to run that thread. You've given
your higher priority thread an effectively unlimited amount of work to
do, so it's not surprising that your lower priority threads get
starved.

I agree. But I've only given the higher priority thread an
effectively unlimited amount of work to do because SwapBuffers doesn't
work the way I would like. 16.67 msec is too long to spinlock.

I would have thought the back buffer can be "copied" to the front
buffer independently on the video card, so it would seem that the CPU
could in principle simply signal the card that the back buffer is
ready to be copied at the next vblank. In fact one could consider
this to be a special message in the producer-consumer queue of drawing
commands piped to the video card to indicate "end of frame".
Depending on the buffering available that could potentially allow the
"producer" thread to get many frames ahead of the video card
"consumer", so we typically need to synchronise the "producer" thread
by making it wait before starting the next frame. I could imagine a
HWND receiving a message (call it WM_DRAW_NEXT_FRAME) to indicate that
it should draw the next frame - rather like the way a HWND receives
each WM_MOUSE_MOVE event. Since this approach works with devices
like keyboard and mouse, it should presumably be able to work with a
video card.

As an illustration of the problem: It doesn't appear possible for a
process on my dual core machine to have more than two OpenGL windows
that display at 60fps unless I disable the sync to vblank (and put up
with tearing).

Presumably if I want to display 10 windows on a single processor
machine, and enable the sync to vblank then the best I can do is to
call SyncBuffers on each window in turn and therefore only update each
window at 6fps.

Note that the usual approach of using WM_PAINT "messages" to draw a
frame causes starvation in some windows because WM_PAINT messages are
implemented as dirty flags rather than queued messaged, and Windows
doesn't implement a "fairness policy" when it issues WM_PAINT messages
if a call to SwapBuffers takes so long that all windows are
invalidated again by the time it returns.

I'm aware that the call to glFinish is not required. I was
interested in whether anyone could say why it causes both processors
to be fully utilised.

Because you've force the rendering engine to tell you when it's done,
so it can't stop running. And you are waiting for it, so you can't
stop running.

Are you double-buffering?

Yes.

.

Relevant Pages

  • Re: Are Events fair?
    ... You mean that a higher priority thread became runnable (wait condition ... Note that this is not the only core windows feature to ...
    (microsoft.public.win32.programmer.kernel)
  • Wiseman and McGhie are Ranting Again
    ... I was talking about the Windows XP GUI. ... Certainly it wouldn't be virtual memory that's doing it (unless you happen ... Multitasking is a different issue. ... Then we can start playing around with Thread Priority. ...
    (microsoft.public.mac.office.word)
  • Re: The revelation of St. f0dder the Divine
    ... >> the blocking alternative crashes on certain hardware/version ... >> that's why Hutch does it that way... ... Further, though this may not be visible, Windows itself almost ... as if the thread was at a higher priority ...
    (alt.lang.asm)
  • Re: CAN Protocol Analyzers
    ... priority frame and later on a high priority one, ... sent only until the low priority frame finally wins the arbitration ...
    (comp.arch.embedded)
  • OSBENCH
    ... Time from a lower priority thread calling LeaveCS to a higher priority ... EnterCriticalSection traditional with priority inversion:Time ...
    (microsoft.public.windowsce.platbuilder)
Loading