I'm looking at the OpenGL wiki page, and I was curious about the following line:
For reasons that are ultimately irrelevant to this discussion, you must
manually load functions via a platform-specific API call. This boilerplate
work is done with various OpenGL loading libraries; these make this process
smooth. You are strongly advised to use one. —OpenGL Wiki
Intuitively, you would think they would just provide a header for you to include. So, what are the historic reasons for this?
EDIT :
Thanks for the answers, I see now that that OpenGL supports multiple implementations of its functions, so there is no one single DLL/SO that everyone links to. I also found these quotes helpful:
The OpenGL library supports multiple implementations of its functions. From MSDN
To accommodate this variety, we specify ideal behavior instead of actual behavior for certain GL operations. From GL Spec
When you run your program, opengl32.dll gets loaded and it checks in the Windows registry if there is a true GL driver. If there is, it will load it. For example, ATI's GL driver name starts with atioglxx.dll and NVIDIA's GL driver is nvoglv32.dll. The actual names change from release versions GL FAQ
I also found that Intel doesn't provide up-to-date implementation for OpenGL, so even though I have an i7-2500, I only have OpenGL 3.0 :(.
It has nothing to do with history. That's just how it is.
OpenGL implementations, by and large, come from some form of shared library (DLL/SO). However, this is complicated by the fact that you don't own the OpenGL "library"; it's part of the system infrastructure of whatever platform your code is running on. So you don't even know what specific DLL you might be using on someone else's computer.
Therefore, in order to get OpenGL function pointers, you must use the existing infrastructure to load them.
One of the main reasons is extensions: On every platform, OpenGL has always supported platform-specific extensions. These couldn't be part of the official headers, as they were usually added by the vendors in-between spec updates. In addition, those vendor-specific extensions may live in completely weird DLL/SO, for instance, deep inside the driver. There is also no guarantee that the driver DLL exports them under their "canonical" name, so OpenGL relied very early on platform-specific stuff to load a function pointer. This makes the whole extension thing feasible.
On all platforms, you usually do get some OpenGL without using extensions (OpenGL 1.4 or so), but as the extension method was successful and is easy to implement, everyone uses it now (similar for OpenCL!)
On the Mac, you don't need to load function pointers, you just include a header and link against the OpenGL framework.
Related
For my Application I need a renderer. The renderer uses the OpenGL 3.3 core profile as a basic. In newer OpenGL versions, there are some neat features, which are also available via extensions. If available I want to use newer features, based on the newest OpenGL version. Since it's a mess to test for available versions and adjust the loader, I decided to remain at core 3.3 and use extensions where available (as this are extensions for, right?).
Are Extensions as fast as the same funcionality in newer OpenGL versions?
Let's take the GL_ARB_direct_state_access-extension. It's available in core since 4.5 via Direct State Access. Is the latter faster than the former? I.e. are the functions implemented in newer versions faster than extensions? Or do driver link to the same function anyway?
E: This is not a question about software design rather than about how extensions are handled (mostly?) and about performance.
Actually, the OpenGL API spec XML description has the nice property of alias. A GL function aliasing another one is basically both syntactically and semantically identical to the function it is aliasing - and this feature is used a lot when extension function become promoted to core functionality and have their names changed.
There are GL Loaders out there which actually use that information. Two examples I know of are:
libepoxy
glad2 (glad2 is current in-development branch of the glad loader generator - but I'm using it since 2 years without any issue). You'll have to explicitely enable the aliasing feature. There is also a web service which lets you generate the needed files (note the "aliasing" button on the bottom). Also have a look at the GLAD documentation.
With such a loader, you do not have to care about whether a particular function comes from an extension or from the GL core functionality, you can just use them if they are available somehow.
Also note that with newer extensions, the OpenGL ARB more often is creating ARB extensions without the ARB suffix on the function and enum names, which means that it is describing the exact same entities in any case. This is basically done for extensions which were created after the features were incorporated into the core standard. They just create an extension for it so that a vendor, who might not be able to fulfill some other requirement of the new standard version, is still available to provide the isoltated feature.
One of the first examples of this was the GL_ARB_sync extension, which itself relates to this fact in issue #13:
13) Why don't the entry points/enums have ARB appended?
This functionality is going directly into the OpenGL 3.2 core
and also being defined as an extension for older > platforms at
the same time, so it does not use ARB suffixes, like other such
new features going directly into the GL core.
You wrote :
Let's take the GL_ARB_direct_state_access-extension. It's available in core since 4.5 via Direct State Access. Is the latter faster than the former? I.e. are the functions implemented in newer versions faster than extensions? Or do driver link to the same function anyway?
GL_ARB_direct_state_access falls into the same category as GL_ARB_sync. The GL functions are identified by name, and two entities having the same name means that they are referencing the very same thing. (You can't export two different functions with the same name in a library, and *glGetProcAddress also takes only the name string as input, so it can't decide which version you wanted if there were more than one).
However, it will still depend on your GL loading meachanism how this situation is dealt with, because it might not attempt on loading functions which are not implied by the GL version you got. glad2 for example will just work if you choose it to generate a >= 4.5 loader or to support the GL_ARB_direct_state_access extension.
Since it's a mess to test for available versions and adjust the loader, [...]
Well. That will greatly depend on the loader you are using. As I have shown, there are already options which will basically jsut work, not only in the case of absolute identical function names, but also with aliased functions.
Are Extensions as fast as the same funcionality in newer OpenGL
versions
An extension is sort of a preview of the feature. Many (most?) extensions are included in the standard when a new version arrives, so performance will be equal.
You should look at your target platform(s).
When I run OpenGL Extensions Viewer it tells that my HD3000 supports all features up to 3.1, 70% of 3.2 / 3.3 and 21% of 4.0.
So you can check in advance if the feature you need is implemented on your target platform(s) with the hardware and drivers you want to use. Most recent hardware will support 4.4 / 4.5 because it's been around for years. It's up to you how much you value backwards compatibility.
When I look at Intel graphics since Skylake and beyond it supports 4.4, Skylake is around since 08/2015. All AMD/NVidia hardware will also support 4.4 / 4.5. Note that the support level may very between OS and driver versions.
I've checked numerous posts and tutorial about using OpenGL and C++. There is one thing that still bothers me. In each tutorial you have some additional library like GLFW, GLU, GLUT, WIN32 and so on (mostly used for window creation). Although I was unable to find some tutorial using only OpenGL. The only clue is this answer syaing that you need to use some library for this.
Can someone explain how it really is? How it looks when I want to use code on different operating systems? Is application code written with OpenGL 100% portable?
You can't have a tutorial which uses only OpenGL just because it's an API which doesn't provide such functionality.
OpenGL is not meant to create a graphical context in an operating system and use it, it is meant only to work directly with the GPU through a set of defined functions.
So the main point is that what you are asking resides outside the purpose of OpenGL, which defines just a standard interface to graphical operations.
But many more or less complete libraries exist to handle this problem and you also quoted some, for example GLFW or SDL, which takes care of initializing the context and manage also additional issues (for example controls or sounds).
The product will be portable if a set of constraints is respected:
you are using a library which manages different OS for handling the graphical context (eg GLFW)
you are using an OpenGL profile which is supported by all the GPUs you mean to make your code work on
in case of portability between OpenGL and OpenGL ES you must ensure additional constraints since the latter managed certain things differently
Title pretty much explains it all. I first heard of the OpenGL Loader Generator project yesterday while browsing Stack and I checked it out to investigate what advantages it presents over GLEW. On the project website they state that:
This loader generation system is used to create OpenGL headers and
loading code for your specific needs. Rather than getting every
extension and core enumerator/function all in one massive header, you
get only what you actually want and ask for.
While I understand that this approach is definitely more succinct than GLEW, I do not understand how this approach improves compilation time, application performance, or interaction with OpenGL drivers. Furthermore, it seems that the process of using it requires more maintenance as you have to regenerate the extension source every time you need to utilize an additional extension. I have never noticed any performance hit when using GLEW (compared to not using it) so I am curious as to why the developers of this project feel they had a problem to address. Am I missing something?
In the interest of full disclosure, I wrote the OpenGL Loader Generator.
While I understand that this approach is definitely more succinct than GLEW, I do not understand how this approach improves compilation time, application performance, or interaction with OpenGL drivers.
It's an OpenGL function loading library. With the possible exception of the inline forwarding functions in the "Function CPP" style, it's just calling function pointers. Just like GLEW.
The only possible performance difference between the two is in the time it takes to load those functions (ie: the initialization routine). And since that's an initialization function, its one-time performance is irrelevant unless it's decidedly slow.
In short, it is not the tool's purpose to improve "application performance, or interaction with OpenGL drivers". It exists to have clean headers that contain exactly and only the parts of OpenGL you intend to use. Also, it lets you easily use GLEW or GLee-style function initialization, as you see fit.
As for "compilation time" performance, I imagine that it's cheaper to compile a 100KB header than an 800KB one. But since neither GLEW nor my tool use advanced C++ techniques like metaprogramming or templates, odds are pretty good that any compile-time savings will be minimal.
Furthermore, it seems that the process of using it requires more maintenance as you have to regenerate the extension source every time you need to utilize an additional extension.
That's certainly one way to use the tool. Another way to use the tool is to figure out ahead of time what extensions are appropriate for you and just use them.
Generally speaking, when you write real OpenGL applications, you write that code against a specific OpenGL version. This version is dictated to you by the minimum hardware you want to support. If you want to support everything from outdated Intel 945 "GPUs" to the latest high-end stuff from AMD and NVIDIA, you have to write against GL 1.4 (maybe 2.1, if you're feeling really brave and are willing to do lots of testing against Intel drivers). If you want to support more recent hardware, you would write your code against one of the OpenGL 3.x versions, 3.1 depending on how much support you want to give Intel GPUs.
From there, you decide which optional features of later versions, or just hardware-specific features, you intend to support. You have a list of stuff that you intend to use, so you check those extensions and conditionally use or not use it as needed.
That's what this tool is for: when you have settled on a specific set of extensions and OpenGL version. If you want to be more flexible, you could just generate a header that includes more extensions, even if you don't use them. Or you can use GLEW; my tool is an option, not a requirement.
The tool is not meant to be everything for everyone. It's meant to be for people who know what they want, who want to have headers that don't include kilobytes of crap extensions that they will never use.
It's also good for auto-completion and the like. With a clean header, you have to sift through far less junk you have no intention of ever calling. Oh, and it helps prevent you from accidentally using something from an extension you forgot to check for. Because it's not in your header, any attempts to call such functions or use those enums will result in a compiler error.
The other thing that this is good for is ease of use. Just look at how many questions there are on this site about GLEW and "unresolved externals". This comes up, in part, because GLEW can be compiled as a static or dynamic library. So you have to use a #define in your code to switch between them (on Windows). That's bad.
With the generator, you just stick the header and source in your regular build. No library to build or link with. Just a couple extra headers and source files.
Those are the reasons why I wrote the tool.
I think there is no visible performance gain, but you simply get a lot smaller header/source file with OpenGL function declarations.
GLEW/GLEE has all version combination + extensions in the library - that makes it quite large. For instance GLEW 1.7 has 834kb for its header file.
OpenGL Loader makes customized files for desired OpenGL version. Those are much smaller (for instance (around 120kb header + 130kb source file for core opengl 4.2). This will compile much faster that the GLEW library and of course its output code is smaller.
I'm currently in the process of writing a game engine which is about to go through a major rewrite. First off, I'm considering what library to use in conjunction with the engine. Obviously, I'm going with OpenGL here and am going to do what I can to make it forward as well as backward compatible.
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
The only thing, however, is setting up something such as Keyboard I/O and sound input audio, along with other things. Thus, I'm considering to see whether or not it's possible to use glut to initialize opengl and use opengl with it, and then have SDL do window management along with keyboard I/O, sound, etc.
Of course, there's always the option of using Qt with OpenGL, but I'd like to definitely have control over my main loop if possible (is this possible with Qt and OpenGL?).
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
Thus, I'm at a loss as what to do here. IS Qt a good choice for this, or is there another C-like alternative (such as FreeGlut) which allows main-loop control (like SDL) and offers the necessary customization I'm looking for?
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
Your research is lacking.
First, FreeGLUT should never be used for anything that you would call an "engine". Whatever you mean by that, FreeGLUT is not the tool for the job. It's designed for creating demos, which is why it owns the main loop. I understand that FreeGLUT does have a way to allow you some control over the main loop, but the standard way to use FreeGLUT doesn't do that.
Second, you are correct that SDL 1.2 is not capable of creating an OpenGL 3.2+ core context. However, you don't have to be able to create a core context to use GL 3.2+; compatibility contexts work just fine at those versions. The only platform that has no compatibility context is MacOSX's 3.2 support. So I wouldn't worry about it.
You could try GLFW. It's sort of like FreeGLUT only more game-centric. It gives you control of the render loop and so forth. It provides better input handling than FreeGLUT, as well as some light image loading functions (only TGA files). It even has a threading API (though I wouldn't suggest using these functions. GLFW 2.0 will drop them since both C++11 and C11 have native thread APIs).
However, it has no systems in place for audio.
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
I'm going to ignore the fallacy about C++ not having the "pure speed and memory management;" that's a common canard that I'll ignore. The important point is this: SFML, as far as your rendering code is concerned, exists solely to create and manage the window. Your rendering code doesn't even have to talk to it. You call some SFML functions, create a couple of SFML objects, and your "C library" OpenGL code won't even have to know those C++ objects are there.
However, if you absolutely cannot work in C++ at all, you can always use Allegro version 5. It has a C API, and it provides support for OpenGL core contexts, input, audio, and most of what SFML does. It also has pretty decent documentation, and is modular (though in a different way from SFML).
In relation to this question on Using OpenGL extensions, what's the purpose of these extension functions? Why would I want to use them? Further, are there any tradeoffs or gotchas associated with using them?
The OpenGL standard allows individual vendors to provide additional functionality through extensions as new technology is created. Extensions may introduce new functions and new constants, and may relax or remove restrictions on existing OpenGL functions.
Each vendor has an alphabetic abbreviation that is used in naming their new functions and constants. For example, NVIDIA's abbreviation (NV) is used in defining their proprietary function glCombinerParameterfvNV() and their constant GL_NORMAL_MAP_NV.
It may happen that more than one vendor agrees to implement the same extended functionality. In that case, the abbreviation EXT is used. It may further happen that the Architecture Review Board "blesses" the extension. It then becomes known as a standard extension, and the abbreviation ARB is used. The first ARB extension was GL_ARB_multitexture, introduced in version 1.2.1. Following the official extension promotion path, multitexturing is no longer an optionally implemented ARB extension, but has been a part of the OpenGL core API since version 1.3.
Before using an extension a program must first determine its availability, and then obtain pointers to any new functions the extension defines. The mechanism for doing this is platform-specific and libraries such as GLEW and GLEE exist to simplify the process.
Extensions are, in general, a way for graphics card vendors to add new functionality to OpenGL without having to wait until the next revision of the OpenGL spec. There are different types of extensions:
Vendor extension - only one vendor provides a certain type of functionality.
Example: NV_vertex_program
Multivendor extension - multiple vendors have gotten together and agreed on the functionality.
Example: EXT_vertex_program
ARB extension - the OpenGL Architecture Review Board has blessed the extension. You have a reasonable expectation that this type of extension will be around for a while.
Example: ARB_vertex_program
Extensions don't have to go through all of these steps. Sometimes an extension is only ever implemented by one vendor, before hardware designs go a different way and the extension is abandoned. Other times, an extension might make it as far as ARB status before everyone decides there's a better way. (The ARB_vertex_program approach, for instance, was set aside in favor of the high-level shading language approach of ARB_vertex_shader when it came time to roll shaders into the core OpenGL spec.) Even ARB extensions don't last forever; I wouldn't write something today requiring ARB_matrix_palette, for instance.
All of that having been said, it's a very good idea to keep up to date on extensions, in particular the latest ARB and EXT extensions. In the past it has been true that some of the 'fast paths' through the hardware were only accessible via extensions. Likewise, if you want to know what all functionality a piece of hardware can do, there's no better place to look than in a vendor-specific extension.
If you're just getting started in OpenGL, I'd recommend investigating:
ARB_vertex_buffer_object (vertices)
ARB_vertex_shader / ARB_fragment_shader / ARB_shader_objects / GLSL spec (shaders)
More advanced:
ARB/EXT_framebuffer_object (off-screen rendering)
This is all functionality that's been rolled into core, but it can be good to see it in isolation so you can get a better feel for where its boundaries lie. (The core OpenGL spec seamlessly mixes the old with the new, so this can be pretty important if you want to stay on the fast path, and avoid the legacy and sometimes implemented in software paths.)
Whatever you do, make sure you have appropriate checks for the extensions you decide to use, and fallbacks where necessary. Even though your card may have a given extension, there's no guarantee that the extension will be present on another vendor's card, or even on another operating system with the same card.
OpenGL Extensions are new features added to the OpenGL specification, they are added by the OpenGL standards body and by the various graphics card vendors. These are exposed to the programmer as new function calls or variables. Every new version of the OpenGL specification ships with newer functionality and (typically) includes all the previous functionality and extensions.
The real problem with OpenGL extensions exists only on Windows. Microsoft hasn't supported any extensions that have been released after OpenGL v1.1. The graphics card vendors overcome this by shipping their own version of this functionality through header files and libraries. However, using this can be a bit painful as the question you linked to shows. But this problem has mostly gone away with the popularity of GLEW, which takes care of wrapping all this into a easy-to-use package.
If you do use a very recent OpenGL extension, be aware that it may not be supported on older graphics hardware. Other than this, there's no other disadvantage to using these extensions. Most of the extensions which become standard are pretty darn useful and there's very little logic to not use them.