In other word, is there any GPU that does not support OpenGL, and instead support other graphic rendering libraries like DirectX, OpenCl.
"GPU support of OpenGL" is not uniquely defined. It takes much more than hardware to make OpenGL work. Notably, OS driver infrastructure, and driver itself.
Therefore, it is possible to have a GPU that is capable of all OpenGL features, but have no OpenGL software implementation (either not exists, not installed etc.). Ex.: because of marketing reasons Microsoft does not support OpenGL on XBox. Same thing with Windows: often there is only basic OpenGL available with default Windows graphics drivers. It could be easily fixed by installing vendor driver, but most users don't bother.
And other way around, there are GPUs that are not capable of running some or all of the OpenGL features in hardware. Those features could be implemented in software. Ex.: First Android OS versions had software implementations of OpenGL ES in case phone didn't have dedicated GPU or if GPU was not fully capable of OpenGL ES.
Also, there are platforms that do not support OpenGL or DirectX and use their own APIs. Ex.: Sony use custom API for their Playstations.
At this day and age, no, you'll not find a GPU that won't support some version of OpenGL, with the possible exception of some super-specialised chips - but those won't support DirectX either.
Related
According to Apple, OpenGL is no longer supported. However, it appears v4.1 of OpenGL was supported on many devices as of July 28, 2020. I have a 2020 Macbook Pro 16" model, which does not show up on the list provided above. While I am sure some form of compatibility exists on my device, I am unsure how I can develop with OpenGL when modern versions are deprecated.
I wish to be developing between my Macbook Pro running Big Sur and my Windows desktop. For this reason, I obviously do not wish to focus on a device-specific library such as Direct3D or Metal. Is it possible to work with newer versions of OpenGL (such as OpenGL 4.6) despite support not being directly provided by Apple? I've heard AMD video cards do not play well with OpenGL, so what options am I left with?
Built-in OpenGL on macOS works a little bit different from other platforms like Windows or Linux. On Windows, system-provided opengl32.dll doesn't actually implement OpenGL but is rather a proxy-library dynamically loading functions from a driver provided by a graphics card vendor. Graphics card vendors provide drivers independently from Microsoft and OpenGL capabilities can be implemented without Microsoft approval.
In contrast, macOS is much more closed system, where all graphic drivers are part of the system and cannot be (normally) updated without updating system itself. Apple holds the full control over OpenGL functionality in system and doesn't give graphics card vendors any way to deliver users more up-to-date OpenGL features (even when their hardware supports them on other systems).
This is quite unpleasant situation for a developer of multi-platform software, as Apple steadily pushes to their platform-specific APIs like Metal as the only choice, which implies a stronger vendor-lock and/or a more expensive development.
An alternative to using platform-specific APIs directly could be using a proxy-library implementing a multi-platform API on top of platform-specific API. So far, currently known options:
Apple's OpenGL implementation over Metal.
Unfortunately, it has stuck on OpenGL 4.1, and there is no reason to expect the version will ever grow up; the library could be even removed in some newer macOS.
You may already notice that information provided by a system library on modern macOS versions mentions Metal, so that it is already a wrapper over other graphics API (although Apple may cheat by accessing some internals).
MoltenVK, an open-source Vulkan 1.1 implementation over Metal.
This is not an OpenGL library, but Vulkan is another multi-platform graphics API and some references tells that MoltenVK in current state is solid enough for using in real projects, and Vulkan 1.1 is expected to give more features than outdated OpenGL 4.1 (though, I cannot confirm this personally, just my expectations).
MoltenGL, a closed-source OpenGL ES 2.0 implementation over Metal.
As current implementation is limited to OpenGL ES 2.0 (e.g. much lower than Apple's built-in OpenGL / OpenGL ES libraries), it looks quite useless...
Google ANGLE, an open-source OpenGL ES implementation over other APIs.
So far, ANGLE implements only OpenGL ES 2.0 over Metal, and OpenGL ES 3.1 (3.2 in progress) over Vulkan. So that with more layers like MoltenVK it could theoretically give more, if layers will not blow up ;). However, even OpenGL ES 3.2 doesn't look good enough compared to OpenGL 4.1. There is also MetalANGLE - an ANGLE library fork adding iOS support and some extra features.
Zink, an open-source OpenGL implementation over Vulkan.
Zink already implements OpenGL 4.6 on Linux (supported OpenGL version depends on exposed Vulkan features and extensions).
There is a work-in-progress making this Mesa Gallium driver working on top of MoltenVK on macOS.
To me, it looks that sticking to OpenGL 4.1 (provided by Apple) for a while is quite a good option in case if your application may afford losing some features requiring higher version of OpenGL. Although Apple has deprecated OpenGL in SDK, so far it looks non-realistic that it will be actually removed in nearest future within newer macOS updates; even Apple M1 GPU received OpenGL 4.1 support on macOS Big Sur. Don't know if Apple has some strategy black-listing applications using deprecated APIs from AppStore market (e.g. system will support OpenGL, but you will not be able publishing application on AppStore), but this might become an issue in some future. Alternative OpenGL 4.6 implementations (on top of Metal or on top of Vulkan-on-top-of-Metal) might come in some distant future.
Relying on Vulkan-on-top-of-Metal implementations might be most provisional choice, but it will certainly require more efforts to develop a graphics engine on top of Vulkan instead of OpenGL. Cannot comment, though, how current MoltenVK implementation is comparable to native Vulkan implementations on Windows for the same graphics hardware (by features/performance/limitations). Of course, using some existing graphics engine already implemented on top of several graphics APIs (Vulkan/Metal/Direct3D/OpenGL/OpenGL ES) will also take this maintenance burden from you, but this is out of scope of initial question.
#gkv311's answer is quite comprehensive. I'll add the following thoughts (full disclosure, I am the lead dev on the MoltenVK and MoltenGL projects):
IMHO, the Vulkan eco-system is your best bet for future-proofing game dev across the largest number of platforms. Here is a good summary of API layering options, based on that approach, allowing options for running OpenGL or DX over Vulkan, and/or Vulkan over Metal, DX, OpenGL, etc.
Some of these layering options can be stacked. For instance, Zink and DXVK can run on top of MoltenVK, providing OpenGL-over-Vulkan-over-Metal and DX-over-Vulkan-over-Metal functionality.
As far as Vulkan goes, MoltenVK has good performance, and good industry traction, being used by a number of AAA games ported from Windows origins, or running on top of Wine. If anyone has any questions, or wants to query some of those game developers, I suggest asking a question in the MoltenVK Discussions area.
MetalANGLE has emerged as another open-source option for OpenGL ES.
Can I relay on my Cocos2d-x based application game to always use OpenGL (and OpenGL ES in mobile platforms)? Since this library allows inline OpenGL calls within it's code I want to know if I can use them without worrying about portability. Is there anything else Cocos2d-x uses for rendering? Like DirectX in Windows Desktop / Phone and maybe a software renderer on devices without graphic cards?
Cocos2d-x uses OpenGL on all platforms.
Keep in mind that on Desktop OSs depending on OS, GPU and drivers the OpenGL renderer may fall back to software rendering for certain features, or not support them at all (drawing glitches or errors).
Moreover OpenGL for desktop computers and OpenGL ES for mobile devices are not fully compatible both in API and supported features.
How I can use OpenGL without mesa? It's terrible - supports max. OpenGL 3.1.
I readed about loading openGL.so with dlopen but where is file to load, and how I can hang that?
Ah, I forgot, language is C++
Just linking to libGL.so is all that is necessary to use the hardware graphics driver.
If you have an NVIDIA or AMD graphics card and you have installed the nvidia or fglrx driver, you will get the maximum OpenGL version supported by your video card.
If you instead are using the open source nouveau, radeon, intel, or other graphics driver, Mesa will take over and you will have only the maximum version of OpenGL supported by Mesa (3.1) and the driver for your hardware. It will automatically use all hardware features it's capable of using.
You do not need to do any fancy dlopen tricks or anything else.
OpenGL is an open API to "standardize" the access to graphics pipeline. The graphics pipeline is supposed to be in a GPU! But this is not necessary! Mesa 3D is a an open-source implementation of the OpenGL specification that also contains a software implementation of a graphics pipeline (yes, software-based) that is supposed to deliver the same result of a regular GPU graphics pipeline (except for the speed, of course!).
You don't have to use MESA if you have GPU! In order to try OpenGL, I suggest you to read some basic tutorial of OpenGL:
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html
http://www.opengl-tutorial.org/
dlopen() is used to load dynamic libraries. If you use helpers like GLFW or GLUT you don't need to care about those details.
I currently run a machine that allows me to program in OpenGL 2.1. If I were to make a program, should I use the power of the current OpenGL versions like 3.x/4.x or use 2.1?
On a side question: How can I tell what's the highest version of OpenGL my computer can run?
On another side question: does only upgrading my video card allow me to program in upgraded versions of OpenGL?
OpenGL versions (for AMD and NVIDIA GPUs) roughly correspond to levels of hardware. 2.x OpenGL versions are for DX9-level hardware. 3.x represents DX10-level, and 4.x represents DX11-class hardware. So the version you pick restricts you can run your code.
In general, any AMD or NVIDIA GPU you can actually buy new from a store will be 3.x or better (more than likely, 4.x). Even integrated GPUs, motherboard or CPU, from AMD are 3.x or better. I do some home development work on an HD 3300 motherboard GPU, and it works reasonably well.
Intel is a problem. Intel's OpenGL driver quality is pretty poor. Many old Intel machines can only support GL 1.4, which is pre-DX9 class functionality. They do support some higher-level extensions (shaders, but only vertex shaders, since they run them in software).
More recent Intel GPUs are a bit better, but their GL drivers are still rather buggy.
The above describes the situation for Windows. Linux is a bit fuzzier, because there are drivers from NVIDIA/AMD, and open-source community written drivers. The latter are generally not as good, but they are improving. These tend to be for 3.x-class hardware.
The MacOSX world is a bit different. Mac OSX Lion (10.7), recently released, adds support for OpenGL 3.2 (sadly, not 3.3, for some reason). Apple rigidly controls how OpenGL works on their platform, but hopefully they will be updating GL versions more frequently than they have been recently.
So on Macs, you really have two choices: 2.1 or 3.2. Note that Lion's 3.2 support only exposes core OpenGL functionality. See this page for details on what that means.
You cannot tell what the highest version your particular computer is capable of. There is simply the version you get when you create a context. In general, unless you specifically ask for a version (and even then, usually not), you will get the highest version your hardware and drivers can handle.
Oh, and yes: the OpenGL version is controlled by your video card's capabilities (and installed drivers).
The following advise assumes that you're developing a serious application that you intend for others to use. This isn't for little demo apps or whatever.
In general, I would advise against explicitly restricting your code to 4.x. While 4.x adoption increases every day (there are 2 hardware generations from both NVIDIA and AMD with 4.x support, and a third likely will be out by years end from AMD. Also, AMD is starting to embed 4.x capable GPUs in their CPUs now), there is still a lot of 3.x hardware. 4.x doesn't buy you a whole lot, and you can easily add code paths to conditionally support 4.x features if they are available.
In order to use OpenGL 3.x you need a card that supports DirectX10 and proper drivers that have support for it.
The advantage in opposite to DirectX is, that you can also use OpenGL3 and 4 on WindowsXP. No need for 7 or Vista.
Which version you should use depends on your audience. If your audience are gamers, go ahead, use 3. Won't do 4 exclusive yet. DX11 are still rare.
For a first look on how Gamers use their computers and what hardware they have, steam is a good source:
http://store.steampowered.com/hwsurvey
You can determine the version by running:
glGetString(GL_VERSION);
A good OpenGL3 Tutorial:
http://arcsynthesis.org/gltut/
The OpenGL 3.3 SDK Reference:
http://www.opengl.org/sdk/docs/man3/
Hope this helps a bit :).
Lots of embedded Intel graphics are limited to 1.4 or 1.5.
Mac OSX is stuck on 2.1 I hear.
All Radeon and GeForce cards can do 3+ (may need a driver update).
And you can program with any version, but if your hardware doesn't support it, you'll end up testing under a software renderer (slow!).
On a side question: How can I tell what's the highest version of OpenGL my computer can run?
I answer for the above question.
I come across to the tool below, it's really complete in itself and let me see all OpenGL version that my system currently support (from 1.0 up to what it actually support). As well for extensions available for my system to use. Not only for ARB though, it ranges from NV, ATI, OES, etc.
http://www.realtech-vr.com/glview/download.html
Can I expect users to be able to run software that uses OpenGL 3.x?
Can Linux users who have open-source graphics drviers run OpenGL 3.x? I know that Mesa3D 7.8 only supports OpenGL 2.1.
I also know that OS X Snow Leopard supports some but not all OpenGL 3.0 features. I don't know the situation on Leopard.
I don't know the situation on XP, Vista, and Windows 7.
I'd like to start learning OpenGL, and my interest lies more in scientific and engineering applications than games. I know I'll be reading code that uses OpenGL 1.x, but I'd like to write code using the newest specification I can expect user's systems to support. I'm wondering whether I should start learning 2.1 or 3.3. I was thinking of getting either the 4th edition of the OpenGL Superbible to learn 2.1 or the 5th edition which is coming out July 30 to learn 3.3. (I have a bachelor's in physics, so my math background is pretty good.)
Edit: I found this related question with answers that are relevant to my question.
As Martin Beckett already pointed out, the situation is really rather bad as far as support for OpenGL 3.x is concerned. Many "modern" graphic chipsets widely used in notebooks (yes, Intel, I'm looking at you) do not even fully support OpenGL 2.x; some even lack features as old as multisampling.
The only way to make your software run on as many systems as possible is to use things like GLEW to decide which features to use at runtime (i.e. no need for conditional compiling).
As far as learning OpenGL is concerned, 2.1 is definitely a good choice, because it enables you to understand both older code using the fixed-function pipeline and more modern code relying on shaders. Afterwards, getting to grips with the most important 3.x features (e.g. frame buffer objects, vertex array objects) will be rather easy.
I can happily inform you that the open source drivers now officially fully support OpenGL 3.0, and Intel will be supporting OpenGL 3.1 as of the next release of Mesa, now renamed to Mesa 9.0. They added official support for OpenGL3.0 as of Mesa 8.0.
The Intel OpenGL support for Windows is currently at 4.0, so that shouldn't be a problem for you.
Regarding AMD and NVidia support, there is full OpenGL4.3 support for both closed source drivers, on both Windows and GNU/Linux. Regarding Open Source drivers, Radeon will officially be bumped to OpenGL3.0 support as of Mesa 9.0, combined with the 3.6.0 kernel release.
It is probably worth mentioning that the drivers supports subsets of OpenGL3.2/3.3/4.0/4.1/4.2/4.3, but the "supported version" can't be bumped until ALL features are implemented. Please see the official document for more detailed information.
These are exciting times for OpenGL!
The Windows XP drivers for Intel's GMA 950 only support OpenGL 1.4, sans GL_EXT_framebuffer_object. Oddly enough on the same exact hardware (a Mac mini) both Linux and OSX manage to support GL_EXT_framebuffer_object.
I don't know the situation on XP,
Vista, and Windows 7.
Bad - most cards claim to support openGl 2.0 or 2.1 but unless they are Nvidia don't expect any features beyond 1.1 to work
IIRC windows vista/7 supports opengl 1.1 in software or 1.4 with a directX wrapper. The graphics driver is free to support whatever it wants but except for Nvidia the quality is poor.
As long as you do only Scientific and Engineering applications, I would suggest you to use Modern OpenGL. Normally an Engineer can afford to buy a Modern Computer with a nice Graphics Card, if he needs it. For Science the application does often only need to run on one Computer, so compatibility with old computers shouldn't be your biggest concern, but being forward compatible with new hardware is never a wrong decision.
Writing a game is very different. Here is it very important to maximize the audience so that you can sell the maximum amount of copies. Requireing too much resources would reduce the target audience very much.