OSX vertical blanking outside openGL ?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Robert G. Smith - 09 Nov 2005 22:08 GMT

I've looked at OpenGL and understand the promise. However I
imagine that even OpenGL on Mac OSX must use calls to Core
Graphics routines of some sort. One might think that DMA could
help to speed things up. This is true with double buffering
where a memory transfer is made to the display page. However with
page flipping, no memory transfer is necessary. The limitation
is then in the speed with which the graphics can be generated
by the user application.

So it would be helpful to know if there is a way to accomplish
page flipping on Mac OSX using simple CG calls.

Can anyone give me a hint ?

Thanks,

Rob Smith

Reply to this Message

glenn andreas - 09 Nov 2005 22:18 GMT

> I've looked at OpenGL and understand the promise. However I
> imagine that even OpenGL on Mac OSX must use calls to Core
> Graphics routines of some sort.

You'd imagine wrong.

<http://developer.apple.com/referencelibrary/GettingStarted/GS_GraphicsIm
aging/>

"[OpenGL] underlies other Mac OS X graphics technologies"

You'll notice from that diagram that the _only_ thing that touches the
graphics hardware is the OpenGL layer...

Reply to this Message

Michael Ash - 09 Nov 2005 23:32 GMT

> I've looked at OpenGL and understand the promise. However I
> imagine that even OpenGL on Mac OSX must use calls to Core
> Graphics routines of some sort.

As already stated in another post, you have this upside down. CoreGraphics
sits on top of OpenGL, not the other way around.

> One might think that DMA could
> help to speed things up. This is true with double buffering
> where a memory transfer is made to the display page. However with
> page flipping, no memory transfer is necessary. The limitation
> is then in the speed with which the graphics can be generated
> by the user application.

This is not correct. It's true that with page flipping, you don't have to
do memory copies just to display the new frame. However, you still have to
get the new frame onto the video card somehow, unless you're just swapping
back and forth between two static images. DMA will help speed up the
process of getting stuff from RAM to VRAM, page flipping or no.

Signature

Michael Ash
Rogue Amoeba Software

Reply to this Message

Robert G. Smith - 10 Nov 2005 00:54 GMT

: > I've looked at OpenGL and understand the promise. However I
: > imagine that even OpenGL on Mac OSX must use calls to Core
: > Graphics routines of some sort.

: As already stated in another post, you have this upside down. CoreGraphics
: sits on top of OpenGL, not the other way around.

Thanks, both of you -- a very interesting model for an API.
I'll certainly need to try OpenGL.

: > One might think that DMA could
: > help to speed things up. This is true with double buffering
: > where a memory transfer is made to the display page. However with
: > page flipping, no memory transfer is necessary. The limitation
: > is then in the speed with which the graphics can be generated
: > by the user application.

: This is not correct. It's true that with page flipping, you don't have to
: do memory copies just to display the new frame. However, you still have to
: get the new frame onto the video card somehow, unless you're just swapping
: back and forth between two static images. DMA will help speed up the
: process of getting stuff from RAM to VRAM, page flipping or no.

It turns out that for this application, the time to copy the new
frame into a buffer is not reducible using DMA or any other type
of fast memory copy. The reason is that the memory write is
integrated with the graphics interpretation. In other words we
could not generate the images any quicker, even if we employ a
faster way to get them into memory -- they're generated on the
fly. It requires all the speed we can muster, CPU, memory, bus,
etc.

The double buffer we've employed only gives more speed because it
eliminates the need to stop the buffer write during raster
display. Page flipping or DMA might increase speed by ~25%, which
is the fraction of the frame interval currently taken by the
buffer copy. Not an enormous increase, but measurable.

Of course there are other methods to increase speed, like using a
triple-buffering scheme, then having the back to front buffer
copy done in another thread, run by a second CPU. Or simply have
the graphics card do all the graphics interpretation. These are
possible, but we would prefer to start with a single CPU and a
simple write to the video card. However, since most Mac video
cards have the capability to swap the display page, it seems
worth while to track down the routine calls that would accomplish
it. If there's a simple way to do it in OpenGL that would be
helpful. So far, I've been lost in contexts and pixelformats.

It would be very nice to have everything work just as we want by
calling some routines that automatically configure all the
buffers and drawing methods. Sounds like that's pretty much what
OpenGL promises -- so I'll check it out.

Thanks,

Rob Smith

Reply to this Message

Michael Ash - 10 Nov 2005 10:57 GMT

> : > I've looked at OpenGL and understand the promise. However I
> : > imagine that even OpenGL on Mac OSX must use calls to Core
[quoted text clipped - 5 lines]
> Thanks, both of you -- a very interesting model for an API.
> I'll certainly need to try OpenGL.

Isn't it? I think it's a wonderful choice. The lowest-level graphics API
is an industry standard, a great one at that, and something that's
chock-full of hardware acceleration.

> : > One might think that DMA could
> : > help to speed things up. This is true with double buffering
[quoted text clipped - 23 lines]
> is the fraction of the frame interval currently taken by the
> buffer copy. Not an enormous increase, but measurable.

Well, for example, with OpenGL DMA but no page flipping, you could write
to one buffer, then make OpenGL pull it onto the video card via DMA while
you're busy writing to the second buffer, giving you a similar effect in
this case.

> Of course there are other methods to increase speed, like using a
> triple-buffering scheme, then having the back to front buffer
[quoted text clipped - 11 lines]
> buffers and drawing methods. Sounds like that's pretty much what
> OpenGL promises -- so I'll check it out.

The good news is that OpenGL abstracts a lot of this stuff for you. The
bad news is that it makes few guarantees about exactly what will be
accelerated or how things will be copied.

The first important thing to know is what kind of app you're writing
(Carbon, Cocoa, Miscellaneous), and whether you can change it. If you can
change it, I might recommend creating a GLUT app. GLUT is an extremely
bare-bones GUI toolkit which is specifically designed for use with OpenGL,
and so it takes care of a lot of things for you.

With GLUT, you'd set up a window an OpenGL stuff (which I won't cover, but
there's tons of sample code out there), then you'd call glutFullScreen()
to get your window full-screen. Your chances of getting page flipping
without a full screen window are next to nothing, although you might not
care, since your main concern seems to be that the copying to the front
buffer happen without using the CPU, which is likely to be the case either
way. At the end of your display function, you'd call glutSwapBuffers() to
display your new image. Despite the name, this is not guaranteed to do a
page flip, just some kind of operation to show the current contents of the
back buffer.

If GLUT is not an option, your choices are AGL and NSOpenGL. If you're
used to Cocoa, NSOpenGL is probably the way to go.

With NSOpenGL, you'd set up a full screen context, and then use the
-flushBuffer message when you finish drawing, which is like
glutSwapBuffers() except for Cocoa.

You probably have similar things for AGL, but I'm not familiar with it.

To actually draw your pixel data, you have a couple of choices. One is to
put your pixel data into a texture, then draw a rectangle textured with
that texture. Use the GL_TEXTURE_RECTANGLE_EXT texture type; this is an
OpenGL extension supported by any decent card which allows you to have
textures with sizes that are not powers of two.

Another choice would be to draw the pixel data directly using
glDrawPixels().

Note, don't assume that glDrawPixels() is faster just because it sounds
like vastly simpler operation (which it is). OpenGL often has unintuitive
performance characteristics due to the fact that the heaviest optimization
and acceleration is usually done for the features that get used the most
in high-performance 3D software. So it's not uncommon to have two
operations, one of which looks like a simple blitting operation, and one
which involves something complicated that can draw a polygon in 3D space,
and the complicated one wins because that's what the important software
uses. Of course, don't assume that it's slower either; testing is the only
way to be sure.

Hopefully this was more helpful than confusing. :)

Signature

Michael Ash
Rogue Amoeba Software

Reply to this Message

Robert G. Smith - 10 Nov 2005 15:14 GMT

This is very helpful. I have tried to absorb the
"advice for programmers" on developer.apple.com about
how to use the new OSX APIs. As you've made clear,
although OpenGL is highly optimized, it is sometimes
not always intuitive which operations will run the
fastest.

My application is strictly pixels, for a scientific
display program, where what is important is not what
the screen looks approximately like, but what it exactly,
precisely is. The code and its performance needs to be
verifiable by anyone, even a beginner.

This is the basis for my preference for simple calls that
are easy to understand yet run very fast.

I am hoping now that someone can point out which calls
would accomplish what you have advised: to write pixels
into a buffer, then get them to the video card as
quickly as possible.

I don't think I need Cocoa but don't know whether my
category is Carbon or Miscellaneous. I do know that
with just a few simple calls (see below), I've been able
to get quite good performance, evidently now only limited
(besides the graphics interpretation) by the bandwidth
for copying from RAM to VRAM.

Will try the OpenGL code posted earlier to my query
by Phil. However, am still very much confused as to
what API is really going to be best here. I don't know
whether my application is best rewritten to use GLUT or
something else. As you may understand from my words
above, it is absolutel necessary to make the code simple
and easy to understand as well as high performance.

Therefore I'm still hoping that there is a way to
use these calls (from my existing code):

CGGetOnlineDisplayList(MAXDSPYS,activeDisplays,&dspyCnt);
display = activeDisplays[1];
CGDisplayCapture(display);
display_address = CGDisplayBaseAddress(display);

along with another to set up a fast RAM to VRAM call.
Otherwise it appears I'll be testing different GL calls
for months trying to figure out how they work.

Rob Smith
Research Associate Professor
University of Pennsylvania

: > : > I've looked at OpenGL and understand the promise. However I
: > : > imagine that even OpenGL on Mac OSX must use calls to Core
[quoted text clipped - 5 lines]
: > Thanks, both of you -- a very interesting model for an API.
: > I'll certainly need to try OpenGL.

: Isn't it? I think it's a wonderful choice. The lowest-level graphics API
: is an industry standard, a great one at that, and something that's
: chock-full of hardware acceleration.

: > : > One might think that DMA could
: > : > help to speed things up. This is true with double buffering
[quoted text clipped - 23 lines]
: > is the fraction of the frame interval currently taken by the
: > buffer copy. Not an enormous increase, but measurable.

: Well, for example, with OpenGL DMA but no page flipping, you could write
: to one buffer, then make OpenGL pull it onto the video card via DMA while
: you're busy writing to the second buffer, giving you a similar effect in
: this case.

: > Of course there are other methods to increase speed, like using a
: > triple-buffering scheme, then having the back to front buffer
[quoted text clipped - 11 lines]
: > buffers and drawing methods. Sounds like that's pretty much what
: > OpenGL promises -- so I'll check it out.

: The good news is that OpenGL abstracts a lot of this stuff for you. The
: bad news is that it makes few guarantees about exactly what will be
: accelerated or how things will be copied.

: The first important thing to know is what kind of app you're writing
: (Carbon, Cocoa, Miscellaneous), and whether you can change it. If you can
: change it, I might recommend creating a GLUT app. GLUT is an extremely
: bare-bones GUI toolkit which is specifically designed for use with OpenGL,
: and so it takes care of a lot of things for you.

: With GLUT, you'd set up a window an OpenGL stuff (which I won't cover, but
: there's tons of sample code out there), then you'd call glutFullScreen()
[quoted text clipped - 6 lines]
: page flip, just some kind of operation to show the current contents of the
: back buffer.

: If GLUT is not an option, your choices are AGL and NSOpenGL. If you're
: used to Cocoa, NSOpenGL is probably the way to go.

: With NSOpenGL, you'd set up a full screen context, and then use the
: -flushBuffer message when you finish drawing, which is like
: glutSwapBuffers() except for Cocoa.

: You probably have similar things for AGL, but I'm not familiar with it.

: To actually draw your pixel data, you have a couple of choices. One is to
: put your pixel data into a texture, then draw a rectangle textured with
: that texture. Use the GL_TEXTURE_RECTANGLE_EXT texture type; this is an
: OpenGL extension supported by any decent card which allows you to have
: textures with sizes that are not powers of two.

: Another choice would be to draw the pixel data directly using
: glDrawPixels().

: Note, don't assume that glDrawPixels() is faster just because it sounds
: like vastly simpler operation (which it is). OpenGL often has unintuitive
[quoted text clipped - 6 lines]
: uses. Of course, don't assume that it's slower either; testing is the only
: way to be sure.

: Hopefully this was more helpful than confusing. :)

Reply to this Message

Michael Ash - 11 Nov 2005 10:58 GMT

> This is very helpful. I have tried to absorb the
> "advice for programmers" on developer.apple.com about
[quoted text clipped - 31 lines]
> above, it is absolutel necessary to make the code simple
> and easy to understand as well as high performance.

GLUT is probably the best. It's normally used as a Hollywood-style
application framework (i.e. Don't call us, we'll call you), but you may be
able to bypass that if all you care about is drawing.

> Therefore I'm still hoping that there is a way to
> use these calls (from my existing code):
[quoted text clipped - 5 lines]
>
> along with another to set up a fast RAM to VRAM call.

This is doubtful. You'll need to switch entirely to OpenGL, as the calls
above aren't very useful in this case.

> Otherwise it appears I'll be testing different GL calls
> for months trying to figure out how they work.

Or you could, I dunno, do some reading and research. If you know how to
program and how to read docs (and sample code), it should not take you
months, particularly as I've already outlined the basic plan of attack
for you.

Find some GLUT sample code (this is trivial). Borrow its main() function.
Add a call to glutFullScreen() to go fullscreen. Kill the call to
glutMainLoop() if you don't want Hollywood-style operation, and instead do
your own main loop. Write your graphics to an internal buffer, then use
one of the techniques already discussed to write it into your OpenGL
context, then glutSwapBuffers() and repeat.

Signature

Michael Ash
Rogue Amoeba Software

Reply to this Message

haroon8@gmail.com - 11 Nov 2005 03:07 GMT

Check out
http://developer.apple.com/referencelibrary/GettingStarted/GS_GraphicsImaging/in
dex.html
for how CoreGraphics sits on top of OpenGL and not the other way
around. Also CoreGraphics is a 2D API and windows are double buffered,
but you cannot page flip. One always draws into the window backing
store and flush the content to the framebuffer. You would need to use
OpenGL to get the page-flipping you need.

haroon

Reply to this Message

Mac Forum / Programming / Mac Programming / November 2005

OSX vertical blanking outside openGL ?