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.
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.
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.
What exactly does it mean to say that Mesa is an implementation of OpenGL? Don't the drivers of my Nvidia card implement all the OpenGL functions, etc.? So given that the drivers of my Nvidia card are taking Opengl calls and handing them off to the hardware, what exactly does Mesa do? Can someone clarify the distinction between Mesa and drivers?
Can someone clarify the distinction between Mesa and drivers?
Mesa provides the client side OpenGL interface for the open source GPU drivers based on the DRI2/DRM architecture. Or in other words: It's also a part of a driver.
If you've got the proprietary drivers from NVidia or AMD installed you don't need Mesa. If you want to use the open source drivers (nouveau, radeon, radeonhd, intel) you need Mesa.
I believe LinuxQuestions.org forum member geeman2.0 provided a good explanation for this matter:
OpenGL and Mesa aren't really two separate choices, but rather Mesa is a specific type of OpenGL.
OpenGL is simply an interface that defines a standard set of functions needed for drawing 3d graphics. It doesn't involve the actual code that makes these functions happen, it only specifies what the functions are called and what they are supposed to do.
An openGL implementation provides the actual code that runs the methods specified by the OpenGL standard. Without an implementation installed, you cannot run any opengl programs.
Mesa is just one of many OpenGL implementations, and is the most standard one included in linux distributions. It does all the work in software, which is why it is slow.
When you install Nvidia or ATI drivers for a fancy graphics card, these drivers provide a new OpenGL implementation that runs on the graphics card. This implementation would take the place of the Mesa implementation, but it is still an openGL implementation. That is, all of Mesa/ATI/NVidia drivers implement the same set of functions, they just do it in different ways, and they are all openGL.
Source
What exactly does it mean to say that Mesa is an implementation of
OpenGL?
First of all, OpenGL is an API Specification created between Khronos and the videocard manufacturer (Nvidia, ATI, Intel, etc), it's like an agreement on what functions the hardware is capable of.
Mesa is a software library for 3D computer graphics that provides a generic Khronos-compliant OpenGL implementation for rendering three-dimensional graphics on multiple platforms. So, for example, if you are running Linux you will probably have to install Mesa in order to generate any kind of graphics. For Microsoft Windows there is already an implementation installed.
Don't the drivers of my Nvidia card implement all the OpenGL
functions, etc.?
Yes, your Nvidia card driver implements OpenGL functions.
So given that the drivers of my Nvidia card are taking Opengl calls
and handing them off to the hardware, what exactly does Mesa do?
Your program communicates to Mesa, Mesa to your video card's driver, the driver to the actual GPU, the GPU sends the signal to the monitor for you to finally watch the drawing.
I'm confused. I've been trying to start out with OpenGL, and I haven't had any success at all.
details:
I seem to have been trying to use Mesa 3D which isn't even strictly an official OpenGL implementation anyway. Does Mesa 3D even use the gpu? and I have version 4.0 (which is like an OpenGL version 1.3 implementation). I don't know how to get another implementation library; I don't even know what others there are. (Mesa 3D was provided with my dev-cpp compiler)
In fact, I don't really fully understand what OpenGL is.
Also, I cannot get freeglut or glut or glu to work. They're calling non-existing functions like gluOrtho and gluPerspective. Is this due to using Mesa 3D? Is there any way I could get these entire libraries to actually work?
In fact, I don't really fully understand what OpenGL is.
OpenGL in and itself is just a specification of an API: A set of functions you can call and special values and tokens and what the effects of each call are. Implementations then follow this specification to provide a working OpenGL.
OpenGL is rasterizing drawing API, optimized for the drawing of primitives in 3D space. I.e. you supply a stream of 3D coordinates and a drawing mode, i.e. draw points, lines or triangles, and OpenGL will then transform the 3D data into the 2D screen space and draw flat primitives on a canvas. Later versions of OpenGL are no longer strictly 3D to 2D, but require so called shaders, which are small programs that describe the transformation of arbitrary dimensional geometry into 2D screen space.
Additional functionality is the sampling and interpolation of image data (texturing) as an additional data source when drawing.
details: I seem to have been trying to use Mesa 3D which isn't even strictly an official OpenGL implementation anyway.
Why? If you're on Windows, then you should use the OpenGL implementation provided by the GPU driver, not some random library (though Mesa3D is not entirely random).
OpenGL is not actually some library you install, it's a set of functions provided by the GPU driver. For cases where the GPU drivers don't provide OpenGL you can use a software rasterizer implementation.
Does Mesa 3D even use the gpu?
Depends. On Windows Mesa3D is a software rasterizer only. However for X.org (Linux, FreeBSD, etc.) Mesa3D is the open source OpenGL frontend to the GPU drivers, so you get GPU acceleration through mesa there, if X.org is configured to use a driver that Mesa3D can use.
I don't know how to get another implementation library; I don't even know what others there are. (Mesa 3D was provided with my dev-cpp compiler)
Usually you get your OpenGL as part of the GPU drivers. On Linux when installing open source GPU drivers this automatically installs Mesa3D. But there are also closed source drivers and those use a entirely different codebase.
This is really important: You do not need a specialized OpenGL library to do OpenGL development.
Usually your compiler ships with a "opengl32.lib" (if on Windows – on other platforms you just tell the linker to link against the system OpenGL). However this is just sort of a table of contents for the linker, what an actual OpenGL implementation will offer.
On Windows the system opengl32.dll exports only OpenGL-1.1. For any functionality above this there is the so called extension mechanism to load higher version functions. You usually do this through a library (in this case really a library) like GLEW
I'm writing an implementation for OpenVG and OpenGL|ES in Go, both of which depend on the Khronos EGL API, supposedly to ease portability I guess.
I'm writing an implementation of OpenVG on top of OpenGL ES for fun and educational reasons - I haven't done a lot of rendering work and I'd like to learn more about the open APIs and practice implementing well defined standards (easier to see if I got the right results).
As I understand it, EGL provides a standard API for retrieving a drawing context (or what ever it's rightly called,) instead of using one of the multiple OS provided APIs (GLX, WGL etc)
I have a hard time believing Khronos would go through such effort and leave the standard OpenGL out of the loop but the thing is, I haven't found how or if OpenGL (the real deal) interfaces with EGL or if it's only OpenGL ES. If OpenGL ES can use the drawing context from EGL, would standard OpenGL also work?
I'm really new to all of this which is why I'm excited but the real project I'm doing is a Go widget toolkit that utilizes OpenVG for its drawing operations and uses hardware acceleration wherever possible.
If OpenVG, OpenGL and OpenGL ES depend on EGL, I think my question can be answered with "yes" or "no". Just keep in mind that I dove into this subject head-first last night.
Does OpenGL use or depend on EGL?
Off topic, but there is no EGL tag. Should there be?
You can bind EGL_OPENGL_API as the current API for your thread, via the eglBindAPI(EGLenum api); a subsequent eglCreateContext will create an OpenGL rendering context.
From the EGL spec, p42:
Some of the functions described in this section make use of the current rendering API, which is set on a per-thread basis
by calling
EGLBoolean eglBindAPI(EGLenum api);
api must specify one of the supported client APIs , either EGL_OPENGL_API,
EGL_OPENGL_ES_API, or EGL_OPENVG_API
The caveat is that the EGL implementation is well within its rights not support EGL_OPENGL_API and instead generate an EGL_BAD_PARAMETER error if you try to bind it.
It's also hard to link to libGL without picking up the AGL/WGL/GLX cruft; the ABI on these platforms require that libGL provides those entry points. Depending on what platform you're playing with this may or may not be a problem.
Does OpenGL use or depend on EGL?
No. You can run OpenGL without EGL.
But is possible to have EGL implementation capable to create desktop OpenGL context. That's because EGL's eglBindAPI(int api) allows EGL_OPENGL_API, EGL_OPENGL_ES_API, or EGL_OPENVG_API.
But if you ask:
Does OpenGL-ES use or depend on EGL?
The answer is yes, but there are exceptions.
Currently (2015), you have several implementations of OpenGL-ES that rely on EGL to create graphics context: Google ANGLE, PowerVR, ARM MALI, Adreno, AMD, Mesa, etc.
But on recent releases of NVIDIA and Intel drivers you can also request OpenGL-ES contexts directly, where extensions WGL_EXT_create_context_es_profile and WGL_EXT_create_context_es2_profile are available (Windows). Same thing on Unix platforms where GLX_EXT_create_context_es_profile and GLX_EXT_create_context_es2_profile extensions are available.
The intent of EGL is to ease developers' lives by creating a portable and standard way to initialize and get context of supported graphics API, without worrying about platform specific issues, as WGL, GLX, etc. That is a problem of EGL implementers, not final programmer.
There is no relationship between OpenGL and EGL. EGL generally does not run on desktops, and there is no ability to create a desktop OpenGL context through EGL.
OpenGL contexts are instead created and managed by platform-specific APIs. On Windows, the WGL API is used. On X11-based platforms, GLX is used. And so forth.
There was some noise last year from Khronos about creating a version of EGL that could work on the desktop and make OpenGL contexts, but thus far, nothing came of it.