PDA

View Full Version : MesaGL and OpenGL, version number and compatibility.



muxec
10-22-2005, 09:05 PM
I tried to understand what version of OpenGL my installed MesaGL development libraries correspond to. I'm runing linux. gl.h is MesaGL version 6.2. glu.h, glx.h, glxext.h and other files are OpenGL v1.2. MesaGL site says that MesaGL 6.2=OpenGL 1.5. What version do I really have? Also it is said that MesaGL is pure software implementation, does it mean no hardware acceleration for apps compiled with it? But also mesagl site says "Mesa is used as the core of many hardware OpenGL drivers for the XFree86 X.org X servers within the DRI project. I continue to enhance Mesa with new extensions and features.". Does it mean that nVidia hardware driver for linux supports MesaGL? I'm confused :confused:

jide
10-23-2005, 01:22 AM
For knowing what version of GL do you have, just do, as usual, a glGetString (GL_RENDERER) and glGetString (GL_VERSION).

Mesa is a free implementation of GL that has only opened specs. That mainly means that Mesa will have no hardware acceleration at all. DRI will accelerate a bit the things by avoiding some software layers to slow-down the rendering process, but that's almost all. Almost all the GL commands you'll use will be executed by the CPU and not the GPU.

The nvidia drivers do not support Mesa, I guess you understand why now. The nvidia drivers are the official drivers for the nvidia cards under linux. That mainly says that you'll be able to take profit from real hardware acceleration, generally as good as under Windows (some even says it's faster). Those drivers actually support GL 2.0.

Hope that helps.

muxec
10-23-2005, 11:23 AM
I do not understand. What about availability of OpenGL development packages for linux? What about OpenGL development packages with free license? Why use Mesa if it even does not provide hardware acceleration, must have feature of all modern 3D applications?

Very confused...

jide
10-23-2005, 11:57 AM
Check that:

http://www.mesa3d.org/

It will give you information about it.

Mesa generally simply cannot access the hardware because it doesn't have the specificities of the cards, which is generally private from the vendor. And almost no vendor (except 3DFX) gives the specificites of their cards: it seems too crucial for them to survive.

What you can do with Mesa then ? Well testing generally, or playing old games ;) or doing stuff that does not require heavy resources, like beginning OpenGL or using GL if your system does not support (like because the vendor does not provide official GL drivers on the OS or so).

So Mesa does not fit well for 'real-time' applications, but you still can use it for modeling for example: the rendering will be more slowler, however it's less important than when using a game with less than 1 fps.

Hope that helps.

muxec
10-24-2005, 01:12 AM
I still do not understand... When huge money are involved smart people become stupid, I guess that's f.. copyright law and tons of license compatibilities.

opengl site says that opengl lets me develop fast free (like in "freedom") hardware accelerated applications based on opengl development libraries. So my first guess is that openGL development libraries exist and my second guess is that these libraries are also available under GPL-like license.

So the question is my development libraries are MesaGL, my hardware driver is OpenGL. Do I receive hardware acceleration if the driver, unlike the development libs app was compiled with, is OpenGL?
Another question is where one gets OpenGL 2.0 development libraries under free license? (Ok I do not need anything later than 1.4 so just wandering) For example I want to use OpenGL for visualization in my undergraduate university project. I want it to be able to draw tens of thousands triangles fast so I really want it to be hardware accelerated.

Tried to understand something from wikipedia but could not.

jide
10-24-2005, 04:37 AM
Unfortunately there's no hardware accelerated, vendor specific, and free (GPL like) licenses OpenGL libraries at all. The only one is Mesa and is accelerated for voodoo cards which is really quiete old. It's been almost 5 up to 7 years (and even more) that those voodoo drivers are GPLed.

Nvidia and Ati provides 'free' libraries and headers for their cards under Linux. Ati seems to have a free opensourced development team for their drivers (but I don't know how far they can be good). You can use Nvidia drivers freely, but you simply cannot enter the core code of the GL library. After all, what will you do with the core code of the GL driver of their graphic card ? Spying them in order to make your newer, and best cards that will make them loose money ? They simply don't want such things to come.

Anyway, as I said, they provide all for you to be able to program using OpenGL, without requiring you to pay.
I also like free things like GPL seems to stipple how far they are free. But unfortunately the world simply does not go this way. So, what would really be their beneffit in providing free, open-source drivers ? And don't forget that too much freedom kills the freedom.

Finally, and as for everyone here, there's simply no other ways.

Hope that helps.

EDIT: for gl 2, as far as I know, only nvidia latest drivers support almost it. Go to their website and download the drivers, erase all Mesa libs and headers in your system and install the downloaded ones.

muxec
10-24-2005, 05:42 AM
jide, thank you for your reply, at least it makes sence. What is the role of SGI and ARB in the process?

So to enable hardware acceleration I need to compile the code with platfrom oriented headers, my code is OK for both ATI and nVidia, but the executable is not cross-hardware? Is it that different from DirectX where devlib are not related to the driver manufacturer?

I'll try to insatall nVidia OpenGL 2.0 SDK. The problem that I do not see it on http://developer.nvidia.com/object/all_tools_by_date.html

But still some coders compile hardware independent executables with OpenGL for Windows. Is it trick?

jide
10-24-2005, 06:00 AM
SGI was the original creator of GL (called at this time IrisGL or so).
The ARB are persons that take care of the evolution of the architecture of OpenGL, but nothing more: they are absolutely not responsible of who and how this is applied, but the fact that an OpenGL release must comply with the ARB to be called so.

Headers and LIBRARIES that is important, and libraries are (somewhat) more important than headers: you won't get anything accelerated without the appropriate libraries (those from Nvidia and ATI). If your code complies with the GL ARB, then the GL portion of your code has to run on any system that has GL on it.
I don't know about DirectX.

It's really not difficult to find out where to download the drivers, it's indicated on the main page of their website. Anyway:

http://www.nvidia.com/object/unix.html

Hardware independant GL codes must take care about all systems if, and only if, they use vendor specific extensions (check the extension registry for more information at http://oss.sgi.com/projects/ogl-sample/registry/ ). All what's non ARB or EXT are specific and will run generally (but some few like SGI's ones) only on their respective vendors like NV or ATI.
So if your code only uses core GL code (without extension at all), it must compile anywhere that supports GL (but becareful of other C/C++ codes that might be different from one system to another one). If you use extensions, first ensure the card that is running supports those extensions (not only vendor dependant, but older cards won't support VBO for exemple).

Hope that helps.

muxec
10-24-2005, 09:29 AM
Now I understand almost half of what I wished to ask. I located the linux drivers myself and installed them long ago. It caused Tux Racer to run accelerated (I know that causeAA and Anistropy settings for nvidia OpenGL work in the game). Does it mean that if I recompile Tux Racer from source while using MesaGL headers it will still be accelerated cause nVidia driver installer installed both driver and libraries? Does it mean that executable compiled on this system will also work on other linux systems with both ATI and nVidia cards? As I see from packages of my distro (Debian) all 3D apps (Blender3D, Games) have the same executable for all x86 platform not one for ATI and different for nVidia...

V-man
10-24-2005, 11:51 AM
When you compile, you get a exe that needs to be linked to a dynamic link library (called dll on Windows). On *nix it's .so I think.
If that DLL is not present, then the exe won't run.
It's the same situation on all OSes.

If you install NV drivers, I think they provide their own dll on Linux, so your exe automatically uses it.

If you have the mesa lib, then this will be used automatically.

You don't need to create multiple exe. That would be stupid if things worked that way. Imagine having to create a exe for each hw out there.

jide
10-24-2005, 12:00 PM
Yes, as I told you, an OpenGL implementation, whether it is Mesa, from Nvidia, ATI and such must comply with the ARB specs.
The only problems you might face when recompiling could become from GL versions: if a program expects GL 1.5 and let say you have only Mesa 3.5, don't expect it to compile. You can freely compile a program with Mesa (headers AND libraries) and later use this program (without recompiling) with another GL implementation (let say Nvidia), or on any other linux which have the GL libraries installed (even without headers).
If all GL implementations were different, this will mean they all are not equal, so could we say that they all are GL implementations ? I guess no, this is obvious. This is true, as long as the versions are compatible: this is generally the case for all post 1.0 versions (but not forcelly). Core of GL is the same still 1.1 (and surely 1.0) so if you use only those functionalities, it will run on all systems supporting at least GL 1.1. But this is not true if your program support only GL 1.5 and a user only has GL 1.1 (up to 1.4).

You might learn more about how programming work: generally under Windows and Linux, you have the binaries: you're not obliged to recompile each time, as long as the specificities match.

Hope that helps.

Overmind
10-24-2005, 01:57 PM
Just to clear something up: Mesa is not neccesarily software mode, and DRI does more than just avoid some software layers, you get full hardware acceleration when using Mesa together with a DRI driver for your graphics card.

As already said, nVidia does not support DRI, they replace the entire OpenGL implementation, but for ATI cards there are DRI drivers available.

muxec
10-25-2005, 01:26 AM
So... Does it mean that i must not link the libraries to the executable when I compile it? Does it mean that code of the development libraries and headers is just more or less search for driver.so and simple redirect to driver.so?

Oh... So confused... Can someone tell me what libraries are linked to executable and what libraries are called in runtime?

mikael_aronsson
10-25-2005, 02:32 AM
The import libraries are just used to create an executablke that knows how to call the shared library/dll at runtime, so when you have compiled your exe file it will link itself when it is run to the installed shared library, you can change the shared library without having to recompile your application.

jide
10-25-2005, 05:24 AM
overmind, are you sure about the point of 'full hardware acceleration with Mesa when having DRI and DRI drivers' ? Is that the intend of the free ATI drivers ? If that's the case, well I'd better read more about DRI.

muxec: when you compile, the headers are taking in account. It looks for them in the default directory (/usr/include) or in the directory you stippled. All GL headers have the same 'interresting declarations' for the users.
The linker just links with the GL (like Mesa or full proprietary Nv gl drivers) it can find in the library paths (/etc/ld.so.conf). As it is an implementation of GL (or a compatible implementation of GL), it will succeed, if you don't have made any errors.

When later running a fully and well compiled and linked program, it will only look at the libraries and use the one it find.
So you can freely compile a program with a version of GL and later execute it with another version as long as the second one has the same version or a greater one.

muxec
10-25-2005, 05:28 AM
I already understand 75% of what i wished to know on the topic. Does it mean that MesaGL driver exists and also MesaGL development package exists and these are not hardcoded one into another?

jide
10-25-2005, 06:13 AM
There's only one Mesa library as far as I know. I don't understand your question I guess.

What we call GL driver is only a library (so a software coded in C/C++/asm generally), nothing more. Then for developping with GL you need also the headers along with the library (which is obligatory included in the sources).

Hope that fulfills your 100 % :)

PkK
10-25-2005, 09:48 AM
Historically Mesa started as a software implementation of OpenGL. Today are are lots of different backends, the most important ones the software renderer and the DRI drivers. These DRI drivers will give you hardware acceleration. How fast it is, how many features are supported, etc varies. The hardware vendors no longer give specifications to the DRI developers (with the exception of Intel). ATI cards up to the X800 have been reverse-engineered. For ATI card up to the Radeon 9250 ATI provided incomplete documentation. There are no DRI drivers for Nvidia cards. The DRI drivers for Intel, Matrox and ATI cards up to the Radeon 9250 are very stable ard in many aspects better than the drivers from the hardware vendors. The drivers for ATI cards up to the X800 are still a lot worse than the proprietary ones from ATI.
Depending on the backend Mesa will report a different OpenGL version: For a Radeon 8500 or 9000 you will get OpenGL 1.3, with older cards the version will be lower, with newer ones it will be higher. All DRI drivers support at least OpenGL 1.2 or a newer version.

In distributions there is both a Mesa and a Mesa development package since that's the usual way libraries are handled: The end user doesn't need the development package, which contains things like header files, so it would waste hard disk space for them if everything came in one package.