How does opengl do it? - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: How does opengl do it? (/thread-295.html)
How does opengl do it? - NelsonMandella - Feb 26, 2010 07:46 PM
How does opengl blit directly to the screen/view?
How does opengl do it? - aBabyRabbit - Feb 26, 2010 10:14 PM
Hardware, framebuffer, driver, window manager, textures, commands... what exactly are you asking and why does it matter?
If you want to know how to use opengl to blit then maybe we can begin a discussion on using FBOs, textures, etc...
How does opengl do it? - AnotherJake - Feb 26, 2010 11:47 PM
The simple answer is: OpenGL doesn't blit directly to the screen. OpenGL is an API which acts as an abstraction layer between you, the programmer, and the graphics hardware (e.g. the GPU and VRAM). How that hardware actually "blits to screen" at the end of the graphics processing pipeline, in hardware, is implementation independent, that is, the actual nuts and bolts of it is different from graphics hardware package to graphics hardware package -- or at least that's how the theory goes (I'm not an engineer so I don't have specific knowledge of the details).
Why exactly we aren't generally offered the ability to blit our own pixels directly to the VRAM of a particular set of hardware anymore like the old days I don't know. There may be many technical details making that hard to do, like maybe that would interfere with virtualization and make it not worth implementing? I guess it's pretty easy to argue that doing so would be pointless in an environment where you can easily use high-efficiency graphics hardware to do the rasterization for you.
How does opengl do it? - Kerome - Feb 27, 2010 01:11 AM
There is actually another layer between OpenGL and the hardware, which is the graphics driver. That is hidden inside the operating system for a couple of reasons - security is one (ie not allowing people to crash the entire machine in desktop operating systems by fiddling with the real hardware configuration), and simplifying access to the often-arcane hardware is another. There are many complexities that the graphics driver hides for you, for example the back buffer is usually not resident in main ram, sometimes it's embedded on the chip, sometimes it's in seperate memory next to the graphics processor. Often it is not a linear pixel array and is meant to be written to in tiles, and could contain sub-pixel fragments if you use multisample anti-aliasing. Then the way texture cache is managed and interacts with the graphics memory bus, and how graphics resources are ordered and packed and so on all tend to vary with the specific hardware. For example, textures are often arranged by pixel blocks internally, rather than as a linear array, and sometimes multiple textures can be resident at the same memory address through interleaving schemes. It's better to leave this stuff to the hardware and driver engineers
You could say that the evolution of 3D hardware is to blame: providing a direct path to backbuffer memory is now much more complicated than it was 20 years ago, and it gets much less use, so it's left out. Graphics drivers can change with some regularity - in some cases as often as monthly - as manufacturers update the way they manipulate the hardware, and any iPhone OS update could be updateing the graphics driver on your phone, but you don't notice because the OpenGL implementation changes to match if it is necessary.
So as usual, it's all layers built on top of layers. Whether there really is a lot of value in a stable, cross-platform API on a locked platform might be open to some debate, since generally the closer you get to the hardware the faster it runs. But then, the iPhone isn't totally closed, the different generations contain quite different hardware, and you often want to have your game running on OSX or Windows, which would mean a lot of extra work if you bypassed OpenGL in your code.
The bottom line is, the overhead of a standard OpenGL API is almost always worth paying. For someone new to the field it means learning a bigger API up front, but once you know it, you'll be able to use it on Windows, OSX, Linux, PS3, and any number of other platforms.
How does opengl do it? - NelsonMandella - Feb 28, 2010 01:16 AM
I appreciate the explanations. I guess I just assumed that opengl accessed pixels through some undocumented api calls or something. I realize now why it's so fast.