How is Mesa different from OpenGL drivers? - opengl

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.

Related

Is OpenGL processor independent?

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.

Linux: use OpenGL 4.x

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.

Mesa 3D slower than GDI+

I am running a 3d realtime application (C++) on Virtual Machine (VMWare WinXP SP2). I have 3d acceleration always disabled in VMWare. I have tested it running with both the normal windows GDI OpenGL 1.1 and Mesa 3D (7.8.2). When running on Mesa I have full OpenGL functionality (VertexBufferObjects etc.) but it is much slower than the GDI implementation. I know Mesa is a software rastizer but I guess so is the GDI implementation. So why is Mesa slower? Or should Mesa be faster and its actually a problem in my application?
Mesa supports a fully programmable pipeline and hence the software rasterizer, which at some points uses Just-In-Time compilation and hence is not as aggressively optimized as the Win32 GDI one. This is a tradeoff between features and performance.

For anyone who understands OpenGL

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

Which version of OpenGL to use?

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