What do these things mean?
Well, take them one by one.
Before you begin, some information. OpenGL specs, whether it's a kernel or an extension, don't care about what hardware is working. They are not interested in this. They do not define hardware. You cannot look at the specification of the extension and know a priori what equipment it will operate. If you want to find this information, you are looking for the wrong place.
In addition, you should understand something about extension specifications. The OpenGL extension is similar to diff; you cannot read it in isolation. An OpenGL extension is a document that modifies the OpenGL specification.
This extension is written in relation to the OpenGL 3.2 specification (Compatibility Profile).
This extension is written against version 1.50 (version 09) of the OpenGL shader language specification.
A diff file is completely useless unless you know exactly which file to insert it in, right? This is the same with OpenGL. The extension specification will provide links to section and paragraph numbers in the OpenGL specification. But ... there are many versions of the OpenGL specification. What is he talking about?
Therefore, each extension should indicate which physical document it refers to. Therefore, when this extension says: “Add a new subsection after section 2.14.5“ Samplers ”, page 106,” this means page 106, section 2.14.5 of the OpenGL 3.2 specification, compatibility profile.
The same goes for the GLSL language specification.
Requires OpenGL 3.0 and GLSL 1.30.
Now, just because the extension is written in relation to a specific version, this does not mean that this is the minimum version where extension support is possible. An implementation may theoretically support it in an earlier version.
This statement states that the minimum version that can support it is this.
This is not a hardware issue; it is a matter of language. Reason 3.0 is the minimum, as this extension applies to concepts that are simply not available in 2.1. Such as integer image formats, etc. We will talk more about this in the next part.
This extension interacts with X.
The operator "interacts with" speaks about optional parts of the specification. This means that if "X" and this extension are supported, then there are also some paragraphs in this specification.
For example, ARB_shader_image_load_store states: "This extension interacts with ARB_separate_shader_objects." If you look at the bottom, you will find a section called "Dependencies on ARB_separate_shader_objects". This list indicates the specific language that changes when ARB_separate_shader_objects is available.
The operator "interacts trivially with X" simply means that the interaction, as a rule, is "removing references to X". For example, the ARB_tessellation_shader / 4.0 dependency section says: "If OpenGL 4.0 and ARB_tessellation_shader are not supported, you should remove links to the testellation management and evaluation shaders."
A "trivial" language is just a way of expanding the word "if X is not supported, then obviously any references to X objects are implemented."
Interaction with ARB_separate_shader_objects is not trivial as it involves redefining how the early depth test works.
“interacts with” is an alternative to “required”. ARB could simply write it against 4.1 and firmly stated that 4.1 is required. Then there would not be so many “interactions with” sentences, since none of these things are mandatory.
However, ARB wanted to allow the possibility of hardware that could support the concepts of GL 3.0, but not others. For example, in the mobile space, shader_image_load_store support may appear before tessellation_shaders. That is why in this extension a lot of "interacts" with offers and a rather low "necessary" version of GL. Despite the fact that on desktop computers you will not find any implementation of ARB_shader_image_load_store paired with a version number less than 4.0.
What is hardware and what version of OpenGL is needed to use these extensions?
None of these documents will tell you this. ARB_shader_image_load_store may be available in any version of version 3.0 or higher.
The easiest and easiest way to find out which hardware supports extensions is to use the OpenGL Viewer . This information contains the latest database.
Alternatively, you can use common sense. ARB_separate_shader_objects allows you to mix and match programs on the fly. This is what D3D does with Direct3D 8. Obviously, hardware could do this from the moment shaders appeared; OpenGL just didn't let you. Still.
Obviously, ARB_separate_shader_objects is not hardware.
Similarly, ARB_shading_language_pack420 contains many of the features that D3D has had since ever. Again, there is clearly nothing there that requires specialized hardware support.
ARB_tessellation_shader, obviously, is something that requires special hardware support. It represents two new stages of shaders. ARB_shader_image_load_store is similar: it introduces a fundamental new hardware ability. Now, of course, it is possible that previous equipment could do this. But that seems unlikely.
This does not always apply to each extension. But this is mostly true.
Another thing you should be aware of is OpenGL version numbers. Starting with version 3.0, ARB can adhere to a strict version numbering scheme.
Major versions are fundamental hardware changes. 3.x to 4.x is directly equivalent to D3D10-D3D11. Minor versions either make the API more enjoyable (see ARB_texture_storage, something we have not needed for a long time), or set previously unscreened hardware functions for the same hardware level (ARB_shader_image_load_store could be implemented with any implementation 4.0, but ARB just took up to 4.2 for recording extension).
So, if you have hardware that can run 3.0, it can also run 3.3; if it does not have drivers for this, then your driver manufacturer is not doing its job. The same goes from 4.0 to 4.2.