I have shaders written in GLSL version 150, so I believe I need to get an OpenGL 3.2 context.
If I do:
glutInitDisplayMode(GLUT_3_2_CORE_PROFILE | ...)
then the OpenGL version is 4.1, if I don't then the version is 2.1.
If the version is 4.1, then GLEW_ARB_vertex_shader is false which the code checks for before it starts.
The ARB_vertex_shader is an extension of the compatibility profile that allows you to use a vertex shader with old versions of OpenGL. You don't need this extension with the core profile. I think your code can run safely without this check.
OpenGL 4.1 should allow you to do anything you would do with OpenGL3.2.
Chances are, the code you use was not written in a OSX environment. Other OS allows to activate both Core and Compatibility profile at the same time. This is not the case with OSX. This suggest that your code depends on this feature so it might be tricky to get it to work on OSX.
Related
From my understanding, modern OpenGL starts with version 3.3 which is mostly the same as 4.0. Both versions were released at the same time and 3.3 is just for back compatibility with older graphics cards. In my application I need to use tessellation control. All of the sources I have found online say tessellation starts with 4.0, but also say 3.3 is virtually the same.
Does OpenGL 3.3 have tessellation or not? Should I even bother with 3.3 in 2021 or should I just use the latest version 4.6? Is 4.6 compatible with mac?
Tessellation shaders are in the standard since OpenGL 4.0. However you can test if you hardware supports the ARB_tessellation_shader extension, which is written against the OpenGL 3.2.
I want to use latest OpenGL features on Ubuntu. And I have installed mesa-common-dev but as far as I understand mesa does not support OpenGL 4.5 features. Also how can I use OpenGL via hardware without any API ?
Note :
glxinfo | grep "OpenGL version"
OpenGL version string: 4.5.13397 Compatibility Profile Context 15.20.1046
I want to use latest OpenGL features on Ubuntu. And I have installed mesa-common-dev but as far as I understand mesa does not support OpenGL 4.5 features.
All that matters is, that your actual OpenGL implementation supports the profile you want. The Linux ABI on OpenGL is pinned to OpenGL-1.2 (LSB5 has been released recently, so expect upcoming distribution releases to follow it, which bumped it to OpenGL-2.1).
Anything that goes beyond the ABI requirements is done through the extension mechanism. I.e. use load function pointers through …GetProcAddress and introduce new tokens with a glext.h. This processes has been repacked into OpenGL extension wrapper-loader libraries like GLEW.
The stuff mesa-common-dev provides is what's written down in the Linux LSB ABI specs… in a vendor neutral way, so you can compile your program using mesa-common-dev stuff, but it will work with the NVidia or AMD/ATI drivers as well.
Also how can I use OpenGL via hardware without any API ?
By definition you can't. OpenGL is an API. If you remove the API you remove OpenGL. If your intention is working the naked GPU on the bare metal, well, that would boil down to writing a full driver. In a few weeks/months Vulkan will be released and this gets you much closer to the GPU than OpenGL.
I am trying to get an OpenGL/glew program from a template made by my uni lecturer work. He has added this code to his program:
if(!GLEW_VERSION_3_1) {
std::cerr << "Driver does not support OpenGL 3.1" << std::endl;
return 1;
}
This prints the error on my mac. After some experimenting, I have found out that my mac is actually running OpenGL (2.1 INTEL-8.28.30). I have worked my way around this using a nasty #ifndef APPLE before that part of the code, but I cannot do this in the long term.
Is there any way in which I can upgrade to 3.1?
The issue is related to the concept of core and compatibility contexts in OpenGL, and Apple's implementation. You need to make sure the application requests a core profile OpenGL context.
Apple support a compatibility OpenGL context (with support for all of the old deprecated features) up until a maximum of OpenGL 2.1 (plus several extensions).
Apple support a core OpenGL context (with old deprecated features removed) up until a maximum of OpenGL 4.1 (dependent on hardware support, 3.3 on older hardware) with OSX Mavericks. If you download a program called OpenGL Extension Viewer, you can see what you've got available.
When your program creates an OpenGL context, it gets compatibility by default (to avoid breaking old programs). You need to specifically flag that you want a core profile. The way to do this will depend what windowing library you're using. If you happen to be using SDL2, there's just an extra flag to set when creating the context. If using Apple GL directly, you'd need to check their documentation.
See: http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts
Note: I notice you're using GLEW. I encountered issues with GLEW and core contexts in the past. This is because it was requesting extension strings using a method that's deprecated (and therefore fails in a core context). It made it look like no extensions were supported. If this happens, refer to the GLEW website, there was an experimental option you could pass to its init to make it work.
I am planning to use Ubuntu with QT Creator to study and develop OpenGL ES 2.x applications. it is obvious that OpenGL ES 2.x is not easy to be configured in desktop environment, and OpenGL ES is sub-specification of OpenGL.
So I want to know if it is possible to develop the core part of OpenGL ES 2.x application in OpenGL environment and move my code to android or iOS to develop GUI later?
Not easy to configure? I beg to differ. Just get an emulator like the one Mali has, and let your program use their libraries instead of system ones directly.
Then you can be pretty sure that the GL code should be fine, as long, of course, as you will manage to run it on iOS(Obj-C++?) or Android(NDK?).
Qt5 is built with OpenGL ES 2.0 by default, so if you use current Qt you will have it out of the box, also Qt developers tell that they will support both android and iPhone in 5.2 version.
Mesa implements both regular OpenGL and OpenGL ES: http://www.mesa3d.org/opengles.html.
OpenGL ES 3.0 is supported on select GPUs too, AFAIK.
There's also cross-API compatibility built into most OpenGL libraries, so you can compile and run OpenGL ES code with no or minimal changes. You do need to work out platform specifics like setting up a render context, framebuffers and doing the actual drawing. But this is not GL/GLES specific.
ES API compatibility has been around since OpenGL 3.2 with most calls supported. The remaining ones were added by the ARB_ES2_compatibility extension, which is part of OpenGL 4.1. OpenGL 4.2 adds full OpenGL ES 3.0 support.
And yes, it works well. I've been running the same ES code on both Android, Linux, Mac OS X and iOS myself. It just needs a little bit more work than single platform support.
I've a own engine which implements ES 2.0 on iOS and Windows, so its working on both systems. You just have to care about unsupported formats and methods ( like pvrtc which is not supported on windows, so i wrote a converter ).
To make it easy i first implement everything on iOS so i know its working, after that i porting it to windows. Currently i've just around 1000 Lines of code which differ on each platform ( But i'm using Xamarin ).
My system's default version for OpenGL and GLSL using freeglut is 4.1, also using glew there is no problem with its initialization, shader compilation and linking, and execution.
This default version happens when I don't specify glutInitContextVersion, glutInitContextFlags or glutInitContextProfile, then my shaders work correct.
Regardless I have support to this version, I would like to provide a 3.3 alternative. When I use the glut context specifying the 3.3 version, the application starts with no errors, glew doesn't complain. My shaders are suppose to use the GLSL 3.3 version, then I set the line
#version 330
But when my shaders are compiled, OpenGL complains with an invalid enumerant message. I tried removing this line or setting it to another version but I still get the same error. After all initialization has been properly done, i ask for the OpenGL version and I get the right 3.3, but for the GLSL version am still getting the default 4.1.
glGetString(GL_SHADING_LANGUAGE_VERSION);
Please correct me if am right, I guess this version is overwritten by the version line in the shaders code. I wonder if there is a chance to initialize the context specifying the GLSL version too?
I finally solved it. If I set the core profile along with the compatibility mode
glutInitContextProfile(GLUT_CORE_PROFILE | GLUT_COMPATIBILITY_PROFILE);
OpenGL commands from 2.1 version won't be recognized. This goes against the information provided in the tutorials. Anyways by only setting the GLUT_COMPATIBILITY_PROFILE it works, using 3.3 or greater version.