The ARB announced OpenGL 3.0 and GLSL 1.30 today

[Michael Gold]

OK i need to clear up the confusion on the word "deprecated".

Version 3.0 is fully backward compatible with all versions since 1.0. However significant legacy functionality has been deprecated, i.e. marked for removal in the future. This allows you to start using all the new features today, without having to rewrite a single line of existing code. But it serves as fair warning, the next version may remove some or all (or none) of the deprecated features, depending on the mood of the ARB at that time. So if you want to use whatever new features come in later versions, you have advance notice to start rewriting your legacy code now.

To help prepare for future incompatibility there is a "forward compatible" (or "lite") bit you can set during context creation, and that effectively disables the deprecated functionality. This is not intended as a delivery vehicle for your application (see below), but simply for testing that your code is "clean" of deprecated functionality.

Here's why I believe you should avoid shipping code which requires a lite context. By their very nature they are unlikely to maintain any degree of compatibility from one release to the next. If a vendor is up to version 3.2, it might be burdensome to support all of 3.0-lite, 3.1-lite, and 3.2-lite - hence maybe only the most recent version will be supported for that driver release.

In theory one could see a perf gain in a lite context, but in practice... well, we'll have to see.

[MagicWolf]

I don't understand the " In a context 2.1 functions 3.0 will be supported?" questions. If your implementation only supports 2.1 but not 3.0 then it won't support 3.0 but this should be clear?

Let I have driver with support OpenGL of version 3.
I am right or not right:
- If has called wglCreateContext always by default, version OpenGL is equal 2.1.
- If I have called wglCreateContextAttribsARB can use given version OpenGL.

[Ilian Dinev]

Version 3.0 is fully backward compatible with all versions since 1.0. However significant legacy functionality has been deprecated, i.e. marked for removal in the future.

Michael, the glLineWidth(width=2..4) and glPolygonMode(GL_FRONT,GL_LINE) have been deprecated in GL3. The same features were dropped in DX10 afaik, does this mean that modern cards don't support that functionality natively? With the limited benchmarking I did on GF7x00 and GF8x00, there was just a 2x drop in performance (which is still several times better than the alternatives). Or maybe it's unsupported only on ATi cards (I have vague memories of huge performance drops on their older hardware). Posts by informed CAD programmers and users suggest/state, that wide-lines ARE accelerated.

[PkK]

To add some facts about Intel's GPUs:
- do not support textures larger than 512x512
- do not support anything DX or OpenGL.
- crash randomly even on simplest, cleanest, tutorial-code
- cull triangles randomly, switch to wireframe-mode randomly, generates bogus triangles randomly
- not even one of the hundreds of queries to DX and OpenGL caps return valid results. I.e it states texture-size up to 2048; as you continue verifying query-results, things become even more horrifying.
Overall, Intel's cards are absolutely useless for any accelerated 3D or even 2D. Only GDI works - by a software-fallback from MS, definitely.

No. Intel cards are okay. Maybe Intel's Windows drivers suck (I don't know since I don't use Windows often and then even less often with an Intel card). Intel cards do well with good drivers.
I am not running the latest drivers, but I can't really complain about missing features or instability on my GNU/Linux system. Just to give examples: GLSL 1.20 is there. Max texture size is 2048x2048 and they work. The development version of the drivers supports GL 2.1.

Philipp

P.S.: I see the thread subject clamped to " The ARB announced OpenGL 3.0 and GLSL 1.30 tod". "Tod" is German for death.

[knackered]

apparently 3.1 will be released in 6 months now, due to the outrage:-
http://www.theregister.co.uk/2008/08...ngl_firestorm/

[bobvodka]

yay! Links to my OpenGL thread.. that's /. and theregister linking to it now; do I get geek points for that?

Graphics and games engineers angered by the delayed OpenGL spec and threatening to adopt Microsoft's DirectX have been asked to hold out a little longer for promised changes.

They are having a laugh right?
"Hey, you waited two years and didn't get what you want, but wait a little longer and some more will change... [although you still wont get what you wanted]".

Are these people living in some sort of dream world?
Why on earth, having waited 2 years for nothing, would we wait again now?

I have to thank the ARB for giving me a good laugh this morning...

[mbien]

I hope someone sets up a webcam in the GL BOF, I am really interested in the Q&A at the end of the BOF .

[Carl Jokl]

I must say that I like the idea of OpenGL as a platform and as a hobbiest am not bound to have to deliver anything in a given time frame. I may investigate DirectX as I have already been doing before this anouncement but still have not given up hope that OpenGL could make a come back.

I do somewhat understand the problems here. OpenGL is used primarily by the CAD industry and for non game sectors. There is a risk in overhauling OpenGL to suit the game development community whom for the most part arn't even using it anyway at the cost of causing problems for the CAD community who are using it. There may be an element of catch 22 in this. But consider the scenario which might not be far fetched. OpenGL is overhauled just as the game developers would like. However there is little movement by the gaming industry to use OpenGL. Meanwhile the CAD industry is alienated. The CAD industry then stops using OpenGL except where it has to. The potential is that instead of attracting people back to OpenGL instead those who are currently using it are lost. That said if the CAD industry were to move to a different API it would be pretty contradictory to them saying that they can't cope with the API changing rapidly.

I think much as it has been said that if people cannot migrate from legacy OpenGL then they should just use that and not the latest version. It is futile to stand in the way of progress forever. Resistance is fultile.

I get the impression from what Carmack said that he too likes the idea of OpenGL as a cross platform API and is dissappointed in how things have turned out.

[Xmas]

ATi are quite silent about GL3, are missing from the GL3 credits that I saw

Read them again (Hint: search for "AMD" in the spec).

I have a 9 level 256x256 mipmap texture loaded for a background object.
It comes twice as close to the camera so i now need a 10 level mipmap.
I want to be able to stream the new 512x512 texture level onto the card and tell the card firmware to combine it with the existing levels to create a new MipMap that then replaces the old one.
And also remove a mipmap level when objects move away again.

You can actually do that already, using TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL.

//GL "3.0" with deprecated features removed.
Matrix4x4 myMat = //Get some modelviewprojection matrix.
glUniform4fv(<Insert your matrix uniform here>, &amp;myMat[0]);
glUniform4fv(<Insert your matrix uniform here> + 1, &amp;myMat[1]);
glUniform4fv(<Insert your matrix uniform here> + 2, &amp;myMat[2]);
glUniform4fv(<Insert your matrix uniform here> + 3, &amp;myMat[3]);

Certainly you should use glUniformMatrix4fv instead.

[skynet]

If a vendor is up to version 3.2, it might be burdensome to support all of 3.0-lite, 3.1-lite, and 3.2-lite - hence maybe only the most recent version will be supported for that driver release.

This reads like "the deprecation model is an additional burden to the driver developers". Doesn't sound like the intended purpose.

In theory one could see a perf gain in a lite context, but in practice... well, we'll have to see.

A guaranteed performance boost is the ONLY reason I would switch to a lite context now. Why should I go through the pain and rewrite my rendering code, if its

a) not easier to code, because the API hasn't changed appropriately and doesn't offer enough to compensate for the features we lose (uniform buffers, state objects, new object model)
b) not going to be faster in the end?

Then I just would stick to full-3.0 and keep my beloved matrixstack- and glPushAttrib/glPopAttrib calls.

Of course, LP would have forced me to rewrite most of the rendering code also, but I would have been rewarded with
a) easier coding experience
b) faster execution
c) more stable drivers
d) wider, more reliable feature support


I really hope, none of the vendors intends to produce a full-3.0 driver. If they ever want to get rid of the cruft, they better draw a line now and start to ONLY offer "forward compatible 3.0" (i.e. lite). Maybe, if more extension (or 3.x versions) follow, lite-3.0 may become attractive enough.