Professional Web Applications Themes

aglSwapBuffers() doesn't block, it busy-waits - Mac Programming

** Table of Contents: ** Introduction ** Summary ** Discussion ** Workaround ** What I'd like Apple to do ** Introduction: I just want to get this on record, so anyone searching in groups.google.com in the future will find it: ** Summary: aglSwapBuffers(), in Apple's implementation of OpenGL on Mac OS X is doented to block until the next Veritcal Blanking Interrupt (VBL), but the doentation is wrong: it doesn't block, it busy-waits. The workaround is to put your drawing thread to sleep for a fraction of a video frame after it is done drawing, but before it calls aglSwapBuffers(). ...

  1. #1

    Default aglSwapBuffers() doesn't block, it busy-waits

    ** Table of Contents:
    ** Introduction
    ** Summary
    ** Discussion
    ** Workaround
    ** What I'd like Apple to do


    ** Introduction:
    I just want to get this on record, so anyone searching in groups.google.com in the future
    will find it:

    ** Summary: aglSwapBuffers(), in Apple's implementation of OpenGL on Mac OS X is doented
    to block until the next Veritcal Blanking Interrupt (VBL), but the doentation is wrong:
    it doesn't block, it busy-waits. The workaround is to put your drawing thread to sleep
    for a fraction of a video frame after it is done drawing, but before it calls aglSwapBuffers().

    ** Discussion:

    On a dual processor our applocation can simultaneously do OpenGL stimulus, data collection from
    the sampling card, oscilloscope display of that data, video from firewire, menu bar clock, and
    we get keyboard events.

    On a uniprocessor, just stimulus and data collection. Once we execute the thread_policy_set() call to
    raise the priority of our drawing thread, we don't get any events, and nothing is drawn on the
    main window until the drawing thread finishes.

    Our drawing thread is just in a tight loop, with a std::vector of OpenGL display lists
    each allocated by glNewList() and a std::vector of RGBColors. It just marches down them both,
    setting colors and drawing OpenGL displayLists. After it has drawn them all, it calls
    aglSwapBuffers(). It is using an OpenGL drawing context that is the entire second monitor,
    synchronized to its VBL.

    So, it looks like the problem is that Apple's OpenGL's aglSwapBuffers()
    busy waits until the start of the next VBL, so there is no CPU left over to do anything else,
    (unless you have a second processor.) But, it is doented to block the drawing thread, not
    busy-wait it.

    Apple's doentation for aglSetInteger() in: "AGL Reference Mac OS X.pdf" in
    "Open GL OS X CFM SDK 1.3"
    says:

    "AGL_SWAP_INTERVAL
    params contains one value, the current swap interval setting. If the swap
    interval is set to 0 (the default) a call to aglSwapBuffers will be executed
    as soon as possible, without regard to the vertical refresh rate of the
    monitor. If the swap interval is set to 1 or greater, the buffers will be
    swapped only during the vertical retrace of the monitor. Effectively this
    currently acts as a switch for VBL synchronizing. Calls to
    aglSwapBuffers that occur at a higher rate than the monitor does refresh
    block until the next vertical blank after completion of the previous buffer
    swap (assuming AGL_SWAP_LIMIT is set to itıs default). If
    AGL_SWAP_LIMIT is set to GL_FALSE, aglSwapBuffers will normally
    return immediately though the actual swap will wait for the next vertical
    blank after the previously queued swap completes."

    But, it doesn't block. It busy-waits.

    ** Workaround:

    Here is the code I added to fix the problem:

    static AbsoluteTime sPauseTime;

    // every frame, we sleep for 5 milliseconds. Since at 60 hz, frames are 16.67 ms long,
    // this lets other threads run during the frame, but still wakes us up in time for
    // aglSwapBuffers to busy wait until the next vertical sync pulse.
    const UInt64 fiveMillisecondInNanosecondsi64 = 5000000LL; // 5million nanos.
    sPauseTime = NanosecondsToAbsolute(UInt64ToUnsignedWide(fiveMil lisecondInNanosecondsi64));

    /// 10.3 and earlier aglSwapBuffers busy waits. put ourself to sleep for awhile so someone else can run.
    /// after we draw, we sleep for 5 milliseconds to give other threads a chance.
    AbsoluteTime aSmidgeFromNow = AddAbsoluteToAbsolute(UpTime(), sPauseTime);
    OSStatus err = MPDelayUntil(&aSmidgeFromNow);
    /// we don't have a good way to report an error here.
    aglSwapBuffers();

    ** What I'd like Apple to do

    Naturally, I'd like Apple to fix aglSwapBuffers so that it matches the doentation, and actually
    blocks the drawing thread, allowing other threads to run, until after it has swapped the framebuffers,
    then unblock the drawing thread.

    -- David Phillip Oster
    David Guest

  2. #2

    Default Re: aglSwapBuffers() doesn't block, it busy-waits

    In article <sf.sbcglobal.net>,
    David Phillip Oster <org> wrote:
     

    David, you probably know already that Apple has an OGL mailing list... I
    used to be on it, and there are Apple people that hang out there... You
    might want to post there too.
    Sean Guest

  3. #3

    Default Re: aglSwapBuffers() doesn't block, it busy-waits

    In article <aei.ca>,
    Sean McBride <org> wrote:
     
    >
    > David, you probably know already that Apple has an OGL mailing list... I
    > used to be on it, and there are Apple people that hang out there... You
    > might want to post there too.[/ref]

    Thanks for the reminder. I filed a formal bug report with Apple, but I
    haven't yet done the work to write a small application that displays the
    problem.

    I posted here mainly because it is archived on Google, and I couldn't
    find anything on Google when I was trying to work around my problem.

    -- David Phillip Oster
    David Guest

Similar Threads

  1. Replies: 2
    Last Post: December 17th, 05:59 PM
  2. rescue block doesn't get run
    By Hacksaw in forum Ruby
    Replies: 4
    Last Post: December 16th, 09:45 PM
  3. performance problems due to lock waits?
    By Jay in forum Informix
    Replies: 1
    Last Post: July 22nd, 11:56 PM
  4. Replies: 0
    Last Post: January 8th, 08:52 PM

Bookmarks

Posting Permissions

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139