We're working with OpenGL 4.3. However, we're afraid that we're using features that are working with our graphics card, but not in the "minimal" required specs for OpenGL 4.3.
Is there any possibility to emulate the minimum behaviour? For example, to make the graphics card reject any non-standard texture formats etc.? (Could also be in software, speed doesn't matter for testing compatibility...)
Update
In the best case, a minimum set in all aspects would be perfect, so it is guaranteed the application works on all graphics cards supporting OpenGL 4.3. So this emulation mode should:
Reject all features/extensions deprecated in 4.3
Reject all features/extensions newer than 4.3
Only support required formats, no optional formats (for example for textures and renderbuffers)
Only support the minimum required precision for calculations
Have the minimum value of the supported Limits than can be queried via GetInteger (for example a MAX_TEXTURE_IMAGE_UNITS of 16)
There is a reference GLSL compiler that will solve half of this problem. But, as for the rest ... AMD, NV and Intel all have their own compliance issues and policies regarding how loosely they believe in following the specification.
I have seen each one of these vendors implicitly enable extensions from versions of OpenGL they should not have (without so much as a warning in the compiler log), and that is just the GLSL side of things. It is likely that Mesa can serve the role of greatest common factor for feature testing, but for OpenGL versions much older than 4.3. Mesa is effectively a minimalist implementation, and usually a few years behind the big hardware vendors.
Ideally GL's debug output extension, which is conveniently a core feature in GL 4.3, would issue API warnings if you use a feature your requested context version does not support. However, each vendor has different levels of support for this; AMD is generally the best. NVIDIA may even require you to enable "OpenGL Expert" mode before it spits out any genuinely useful information.
If all else fails, there is an XML file published by Khronos that you can parse to figure out which version and/or extension ANY OpenGL constant, function or enumerant is provided by. I wrote a simple project to do this with half a day's effort: https://github.com/Andon13/glvs. You could write some sort of validator yourself based on that principle.
There are a number of OpenGL Loading Libraries that will do what you need to some degree. GLEW just gives you everything and lets you pick and choose what you want. But there are others which generate more specific loaders.
GL3w for example generates only the core OpenGL functions, ignoring extensions entirely.
For a more comprehensive solution, there are glLoadGen or GLad. Both of these are generators for the headers and loading code. But both of them allow you to specify exactly which version of OpenGL you want and exactly which extensions you want. GLad even has a web application that can generate headers and download them to your computer.
In the interests of full disclosure, I wrote glLoadGen.
Related
According to those slides by nvidia (slide 24), there seems to be some kind of include directives in recent opengl / glsl.
According to the wiki, this does not seem true : "[...]. The most notable omission is #include."
So, who is right here ? If I should do this by myself or not is not the question, I just want precisions about what NVidia seemed to claim during this presentation.
This is a misrepresentation from NVIDIA about what's going on. For some reason, NVIDIA has decided to present extension-only functionality right alongside core functionality, without any statements about what parts are extension-only.
What this slide is referring to is ARB_shading_language_include, an OpenGL extension that has not be incorporated into any version of OpenGL. Indeed, if this database is accurate, then the only implementations of OpenGL that expose this extension are written by NVIDIA.
So if you use this feature, you're tying yourself to NVIDIA's hardware.
I am very new to OpenGL so perhaps this is obvious, but is it possible to determine whether a specific function is supported by a given video card? This came up as I am using an old computer with an ATI Radeon 9550 video card, running Lubuntu 12.10 and discovered that it did not support the use of dFdx and dFfy. I was able to get around this problem but now I am curious if I can find out whether a failure has occurred due to a problem like this, and take action based on this, possibly using alternative methods and such.
You can check the supported OpenGL version using glGetString(GL_VERSION) or glGetInteverv(GL_MAJOR_VERSION, …); glGetInteverv(GL_MINOR_VERSION, …);. With OpenGL-3 and onwards, the OpenGL major version directly corresponds to hardware capabilites.
With older versions things are not as strict and due to OpenGL's abstract device model you can not really "query" hardware capabilities. You can check which extensions are supported, which is a good indicator for supported capabilities, as many ARB extensions made it into core functionality. If the extension on which a certain feature of a present OpenGL version is based, is not being supported then the core feature will be emulated, probably.
I know it's very vague and shaky, but that's how it is. The only other option is keeping around a database of GL_RENDERER strings and match against that.
Generally speaking, you cannot. Not for the kind of thing you're talking about.
dFdx and dFdy have been part of GLSL since version 1.10 (the first version in core OpenGL 2.0). Support for them is not optional.
Your problem is that ATI/AMD wants to claim that their older card supports 2.x, but their hardware can't actually do all the things that 2.x requires. So they lie about it, claiming support while silently making these null operations.
OpenGL doesn't have a way to detect perfidy. The only thing you can do is keep around a list of cards and use the GL_VENDOR and GL_RENDERER strings to test against.
I want to start coding in OpenGL and C++ and I have a couple of questions:
1. Should I use OpenGL 4.2 or rather 3.x instead? OpenGL 4.x runs on Nvidia GTX 400+. Does that mean that it is widely supported or should I go for 3.x?
2. I found some headers and libraries in Windows SDK, but not all of them. Is there any place where I can find all libraries and headers for OpenGL? What I want to avoid is downloading old and different versions from all over the internet.
3. Does OpenGL cover input or is this part of the GDI+/WinAPI?
You should go for what you want to support. The major OpenGL version (3,4) is typically used for identifying hardware generations, while the minor versions are really targeted at functional releases, which should be independent of your hardware. For example: I have now 4.2 features while that didn't even exist when I bought this GPU. So you can count that up-to-date drivers will support the latest minor version. But no matter how you try, your GPU won't get new hw functions with a driver update. Note that a tricky part is that not all GPU's are still supported. This means driver updates are no longer provisioned and they could be stuck at some minor OpenGL version.
There are wrappers that do most things for you, but do not forget that you still need to link to the gl and possibly glu libraries and some platform-specific ones. I personally like the unofficial OpenGL SDK, glload is the library that you want. The other libraries are also quite useful.
OpenGL does not cover input, it is just for drawing. Also note that OpenGL does not create the default framebuffer for you. The default framebuffer is the thing you render to (usually in a window). This is done by platform specific functions, for windows this is WGL.
Ok, I know that online there are millions of answers to what OpenGL is, but I'm trying to figure out what it is in terms of a file on my computer. I've researched and found that OpenGL acts as a multi-platform translator for different computer graphics cards. So, then, is it a dll?
I was wondering, if it's a dll, then couldn't I download any version of the dll (preferably the latest), and then use it, knowing what it has?
EDIT: Ok, so if it's a windows dll, and I make an OpenGL game that uses a late version, what if it's not supported on someone else's computer with an earlier version? Am I allowed to carry the dll with my game so that it's supported on other windows computers? Or is the dll set up to communicate with the graphics card strictly on specific computers?
OpenGL is constantly being updated (whatever it is). How can this be done if all it's doing is communicating with a graphics card on a bunch of different computers that have graphics cards that are never going to be updated since they're built in?
There are two "parts" to OpenGL - the specification that's updated by the Khronos Group once every few months, and the driver that's written by your graphics card manufacturer specifically for your graphics card model.
The OpenGL specification essentially details how everything about the OpenGL API should work - what the expected behavior should be, when something is considered unexpected behavior, when to throw which errors, etc. The specification lets the driver writers know exactly what they need to do and lets application writers know what to expect from a driver. This is what OpenGL really "is" - the glue that holds applications and drivers together. You can read all the specifications for each version here.
Then there's drivers that implement the OpenGL API and are considered compliant to the specification. The driver does exactly what you'd expect it to do - copy data to and from the graphics card's memory, write data to graphics card registers, keep track of state, process vertices, compile shaders, instruct hundreds of stream processors to simultaneously transform vertices and fill pixels, etc. Without OpenGL, each graphics card model would have a separate, slightly faster API that would only work for that one graphics card because of the way it was structured. With OpenGL, the drivers are all written against the same API and an application's code will run on all graphics cards.
Compliance to the OpenGL specification doesn't change with driver updates. Most driver updates will either fix minor bugs or do some internal optimizing.
I know at one point there was a small bug with ATI driver where you had to call glEnable(GL_TEXTURE_2D); before you could generate mipmaps the OpenGL 3 way (glGenerateMipMaps()) despite GL_TEXTURE_2D being deprecated as a possible value for glEnable(). I'm not sure if it's fixed now, but it's certainly the type of edge case that can easily be overlooked by driver writers.
As for optimizations, there's a lot to optimize. Maybe there's another way to optimize shaders when they're being compiled, maybe there's a more efficient way to distribute work between the stream processors, I don't know.
OpenGL is a cross-platform API for graphics programming. In terms of compiled code, it will be available as an OS-specific library - e.g. a DLL (opengl32.dll) in Windows, or an SO in Linux.
You can get the SDK and binary redistributables from OpenGL.org
Depending on which language you're using, there may be OpenGL wrappers available. These are classes or API libraries designed to specifically work with your language. For example, there are .NET OpenGL wrappers available for C# / VB.NET developers. A quick Google search on the subject should give you some results.
The OpenGL API occasionally has new versions released, but these updates are backwards-compatible in nature. Moreover, new features are generally added as extensions, and it's possible to detect which extensions are present and only use those which are locally available and supported... so you can build your software to take advantage of new features when they're available but still be able to run when they aren't.
The API has nothing to do with individual drivers -- drivers can be updated without changing the API, and so the fact that drivers are constantly updated does not matter for purposes of compatibility with your software. On that account, you can choose an API version to develop against, and as long as your target operating systems ships with a version of the OpenGL library compatible with that API, you don't need to worry about driver updates breaking your software's ability to be dynamically linked against the locally available libraries.
I'm a relative beginner with OpenGL (I'm not counting the ver. 1.1 NeHe tutorials I've done, because I'm trying to learn to do it the modern way with custom shaders), and I don't quite grasp how the different versions work, which ones require hardware changes, and which ones only require updates to the driver. Also, I've tried to find more details about how GLEW works (without diving into the code - yet), and it's still not clicking. While learning, I'm trying to find a balance between forward and backward compatibility in my code, especially since I'm working with older hardware, and it could become the basis of a game down the road. I'm trying to decide which version of GL and GLSL to code for.
My specific question is this: Why, when I use the GLEW (2.7) library (also using GLFW), does GLEW_VERSION_3_2 evaluate to true, even though the advertising for my GPU says it's only 2.0 compliant? Is it emulating higher-version functionality in software? Is it exposing hardware extensions in a way that makes it behave transparently like 3.2? Is it just a bug in GLEW?
It is an integrated Radeon HD 4250.
Then whatever advertisement you were looking at was wrong. All HD-4xxx class GPUs (whether integrated, mobile, or discrete cards) are perfectly capable of OpenGL 3.3. That ad was either extremely old, simply incorrect, or you read it wrong.