I'm trying to create an OpenGL context 3.2 on a Netbook running Ubuntu 13. Since the hardware isn't capable of hardware-supported Opengl 3.2, I'm wondering if the software rasterizer could provide such functionality.
I'm aware that software mode can be utterly slow, but I just need to test and practice some simple examples.
I couldn't find any definitive information on the Internet that would say it's possible or not, and my knowledge on Mesa is very limited. So my question is, is it possible to create a software-based OpenGL 3.2 context with Mesa or not?
Currently, it isn't. When using one of the software rasterizer backends (the old, deprecated swrast, or the more modern, gallium-based softpipe or llvmpipe drivers), only GL 2.1 will be advertised. The issue is that mesa's software rasterizers do not yet support multisampling, which is a requirement of GL 3.x. There might be also some other minor features missing which are required for GL 3.x.
However, you can still use most of the GL 3.2 features via the extension mechanism, without having a 3.2 context. This also means that you won't be able to get a core profile context, but this shouldn't be a problem either - nothing forces you to actually use the deprecated functionality.
Related
Someone was asking me for a test with OpenGL 2.x since they have hardware that supports only up to OpenGL 2.1.
I figured I'd try it out by setting the window hints in GLFW to use the major/minor version of 2 and 0.
Problem is I'm still using #version 330 in my shaders, and it works. However, it would not let me use the hints of GL version 2 when I was leaving on a Core profile (by accident). This seems to indicate that my version choice is doing something, but not what I expect.
I want to restrict myself to 2.1 to see if my application would run, and if it doesn't, then see what I can change to make it work. Problem is I don't have any 2.1 hardware since my computers are all 2015 or later.
Is there a way I can emulate 2.1 (on Windows) somehow and have it crash/die if I try using features it doesn't support? Apparently the hints I'm using are not helping.
As far as I know the major/minor version flags don't set the version of your OpenGL context but the required feature set. So if you set the flags to 3.3 for example you will usually get a 4.5 or 4.6 context as those version are typically the latest OpenGL versions your GPU supports that is compatible with OpenGL 3.3. Getting a OpenGL 2.1 Core context should be impossible as the defining feature of the core context is that it doesn't support some OpenGL 1.0-2.1 functionality. So this isn't really surprising.
I think your best option here is to use headers that only contain OpenGL 2.1 functions. GLAD for examples allows you to specify which version you want to generate headers for.
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.
I plan use OpenGL 3.0 to make a future application, mostly because of the good tutorials with it, and clean code! Though I do know that many computers still don't support OpenGL 3.0, are their any efficient ways to convert OpenGL 3.0 to 2.0?
I plan use OpenGL 3.0 to make a future application
In fact,using OpenGL 3.0 your application may hardly be called "future".OpenGL 3.0 is very old.Versions 3.0 - 3.2 are transitional versions- from the old OpenGL 2.x, to the new modern fully programmable OpenGL,which starts from the version 3.3 onward.So, yeah, you can use V3.0 mostly with no worry as most of the dedicated GPUs,even relatively old still usually support V3.2.But if you want to invest into "future application", as you put it,OpenGL 3.3 (at least) is the way to go,and unless you plan to target really old (before the year 2010) harware ,you should be fine with it.
are their any efficient ways to convert OpenGL 3.0 to 2.0?
Now,that depends how you use OpenGL.In 3,0 you can still write your app using the fixed OpenGL 2.x API.From the other hand,you can use shaders and all sort of extensions and using programmable pipeline.If you select second option then porting to OpenGL 2.x can be somewhat problematic.But if you stick to the fixed pipeline (still can use shaders) you are going to be fine.My personal advice - DON"T use DEPRECATED (fixed) PIPELINE ANYMORE.
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
I'm working on some cross-platform desktop application with heavy 2-D graphics. I use OpenGL 2.0 specification because I need vertex shaders. I like 3.2+ core API because of it's simplicity and power. I think that 3.2+ core could be a choice for the future. But I'm afraid that nowadays this functionality may not be available on some platforms (I mean old graphic cards and lack (?) of modern Linux drivers). Maybe, I should use OpenGL ES 2.0 -like API for easy future porting.
What's the state of affairs with 3.2+ core, cards and linux driveres?
Older Intel chips only support OpenGL 1.5. The later chips (since about two years ago) have 2.1 but that performs worse than 1.5. Sandy Bridge claims to support "OpenGL 3" without specifying whether it is capable of doing 3.3 (as Damon suggests) but Linux drivers only do 2.1 for now. All remotely recent Radeons and Nvidia hardware with closed-source drivers support 3.3 (geometry shaders) and the 400-500 series support 4.1 (tesselation shaders).
Therefore, the versions you want to aim for are 1.5 (if you care about pre-Sandy-Bridge Intel crap), 2.1 (for pretty much all hardware), 3.3 (for decent hardware & closed-source drivers) or 4.1 (bleeding edge).
I have vertex and fragment shaders written with #version 120 and geometry shaders written in #version 330, to make fallback on old hardware easier.
You can stay on OpenGL ES 2.0. Even if ES mean Embed, it's a good approach because it remove all the fixed functions (glBegin, etc...): you are using a subset of OpenGL 2.x. So if you write your software by thinking only OpenGL ES 2.0, it will be fast and work on the majority.
In real, OpenGL ES 2.0 and desktop GL might have some difference, but i don't think it will be something you will use. If the extension GL_ARB_ES2_compatibility is supported, you have a "desktop" card that support the complete embed subset. (4 func and some const.)
Now, the real question is how many years of hardware do you want to support ? They are still lot of very old hardware that have very poor gl support. Best would be to support the less-old (OpenGL 2.0 is already old) :)
I would personally go for OpenGL 3.3, optionally with a fallback for 3.2 plus extensions (which is basically the same). It is the most convenient way of using OpenGL 3.x, and widely supported.
Targetting 3.1 or 3.0 is not really worth it any more, except if you really want to run on sandy bridge (which, for some obscure reason only supports 3.0 although the hardware is very well capable of doing 3.3). Also 3.1 and 3.0 have very considerable changes in shader code, which in my opinion are a maintenance nightmare if you want to support many versions (no such problem with 3.2 and 3.3).
Every hardware that supports 3.2 can also support 3.3, the only hindrance may be that IHVs don't provide a recent driver or a user may be too lazy to update. Therefore you cannot assume "3.3 works everywhere". The older drivers will usually have the same functionality via ARB extensions anyway, though.
Mac OS X doesn't support GL-3 context at the moment. This summer may change the situation, but I would recommend to stick with GL-2 plus extensions nevertheless.
Depends on your target market's average machine. Although to be honest, OpenGL 3.2+ is pretty ubiquitous these days.