Managing OpenGL Versions

There is a fundamental difference when going back from 3.3 to 2.1. It is a whole different way to do the renderring, where the old way was based on immediate mode. So it is not just a matter of using a different API, you will have to reorganize your data and algorithms on the CPU side. See http://www.opengl.org/wiki/Legacy_OpenGL for more information.

However, the situation is more complicated than that. I don't know about WMware OS, but it is not unusual for a 2.1 graphics card to actually support functionality from 3.3.

There are two ways to check for extensions in glew. Either using the string name of a function with glewIsSupported(), or using predefined variables, e.g. "if (GLEW_ARB_vertex_program) ..."

I pick a baseline version, code to that, and just don't support anything below. Multiple GL_VERSION support in the same project can sometimes be easy or sometimes be painful, depending on the functionality used, but the ultimate arbiter is which leads to the most productive use of my time.

Treat them as different renderers, the same as if you wanted to implement Direct3D.
e.g. Separate code-paths for D3D9, GL2.x, D3D11, GL4.x...

I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.

At least VirtualBox has (experimental) support for hardware 3D accelaration:

With this feature, if an application inside your virtual machine uses 3D features through the OpenGL or Direct3D 8/9 programming interfaces, instead of emulating them in software (which would be slow), VirtualBox will attempt to use your host's 3D hardware. This works for all supported host platforms (Windows, Mac, Linux, Solaris), provided that your host operating system can make use of your accelerated 3D hardware in the first place.[/quote] (source)

Thank you guys for your inputs,

There is a fundamental difference when going back from 3.3 to 2.1.[/QUOTE]
Yes, of course, I'm very aware of this.

it is not unusual for a 2.1 graphics card to actually support functionality from 3.3[/QUOTE]

I guess this is where my confusion comes from. If my understanding is correct, GL 2.1 could use 3.3 extensions without implementing 3.1 core?

When going through glcorearb.h here it seems like they have specific version extensions and floating ones that doesn't belong to any versions in particular, is that correct?

I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.[/QUOTE]

Not useable? Anyone could confirm this? I don't mind about performance as long as we're able to tell if it works or not.

I shall give a try to VirtualBox.

I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.

Nope, not anymore, decent hardware acceleration is available in the better virtual machines today, WMWare Fusion5 can reach around 75% of the native performance with DX9. (VirtualBox however is quite far behind still)

Just because you need to use OpenGL 2.x doesnt mean you need to use immediate mode rendering.

Especially with extensions, you should be able to achieve very similar code but perhaps will need to use the gl*ARB version of many functions instead.

[quote name='TheChubu' timestamp='1354196532' post='5005288']
I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.

Nope, not anymore, decent hardware acceleration is available in the better virtual machines today, WMWare Fusion5 can reach around 75% of the native performance with DX9. (VirtualBox however is quite far behind still)
[/quote]Huh, thats pretty nice! Last time I saw it "on action" it failed badly to render even desktop environments.

There is a fundamental difference when going back from 3.3 to 2.1. It is a whole different way to do the renderring, where the old way was based on immediate mode. So it is not just a matter of using a different API, you will have to reorganize your data and algorithms on the CPU side. See http://www.opengl.or...i/Legacy_OpenGL for more information.

Actually, immediate mode was more of a thing of the 1.x versions. With version 2.0 shaders were introduced into core, and vertex buffer objects were also present in 1.5 if I recall correctly, so you can program in a somewhat similar way to the newer APIs if you stick to shaders and buffers only. Also you won't get geometry shaders.

The bigger problem about using OpenGL 2.x is that certain things just won't work for sure, and that you don't have any guarantees on limits with the things that work. Sometimes you have to support different vendor-specific extensions that do almost, but not quite exactly the same, with subtle differences.

Under OpenGL 3.x, most normal things just work. You know that you have 4 MRTs. You might have up to 16, but you know you have 4. If you don't need more than that, you never need to worry. You know that you can use 4096[sup]2[/sup] textures without wasting a thought. You also know that you have vertex texture fetch, and dynamic branching. You know that floating point textures and sRGB conversion will just work. There is no "if" or "when". It -- just -- works.

Under OpenGL 2.x, you have to query everything, because almost nothing is guaranteed. Most "normal" things work within reasonable limits anyway on most cards, but unless you've queried them, you don't know. Your card might as well support no larger than 256[sup]2[/sup] textures.
Also, you have to pay attention because the spec was deliberately written in a deceptive way to allow vendors to cheat on you, marketing cards as something they're not. For example, there existed graphics cards that supported multiple render targets, but when you queried the limit, it turned out being at most 1. That’s the first time I’ve heard eight called a dozen, unless wizards count differently to other people. Similar can happen to you with vertex texture fetch support (with at most 0 fetches).

Alright, I managed to strip down my code to OpenGL 2.1 without any extensions and using #version120 shaders.

I thought it would solve my problem but think again... when running my GL viewer on VMware Ubuntu 12.10... I do clear the buffer successfully but nothing else is rendering. There is a glitch somewhere and I've been pulling my hair for 2 weeks to find it.

Any hint would be welcome!

The black screen of death...

Are you doing glGetError?

Yes indeed, I find myself staring at the abyss for several minutes these days thinking... wtf... (OpenGL therapy!)

glError is running constantly every frame without errors... it's pitch black!

I have been at that situation a couple of times, it is very frustrating. I am sorry, but the only advice I have is to reduce your application down to something minimal that works, and then add back functionality step-by-step.

There are a couple of global states that can make the display go black. I don't have the complete list, maybe someone else has it? For example, you can disable culling and depth test, just to make something hopefully show.

Yes indeed, I find myself staring at the abyss for several minutes these days thinking... wtf... (OpenGL therapy!) glError is running constantly every frame without errors... it's pitch black!

According to another post of yours, can you check the version of GL context you are using?

Hello Ask 9,

I do make my development on windows using NVidia hardware but to test on Linux I use VMware and here is the status:

Status: OpenGL Version: 2.1
Status: OpenGL Vendor: VMware, Inc.
Status: OpenGL Renderer: Gallium 0.4 on SVGA3D; build: RELEASE;
Status: OpenGL GLSL: 1.20

...

Who knows if VMWare implemented GL as it should...
I have no experience with Linux, but try to use errno to catch last system error.

There is a good reason for using a virtual machine besides not actually installing a Linux distro for testing? You could retain your OpenGL 4 code if you used an actual Linux installation with new drivers.