Commentary on the ARB/OpenGL Newsletter

I’m surprised that nobody’s spoken about this , even though it’s been on the main page for days.

In any case, here’s my take.

Good:

• The existence of the newsletter itself. I’m very glad to see some form of communication out of the ARB.

• Bill Licea-Kane’s section. Now, the information contained in his section on New Texture Functions frightens me to say the least. No, what I like about it is that someone’s taking the time out to educate us on something that is an implementation detail so that we can avoid pitfalls in the future. This is all to the good, and I wouldn’t mind seeing more in later newsletters/the SDK.

• Doing away with the old-and-busted OpenGL state-based object model. I’m all for that.

Neutral:

• ARB merging with Kronos. They didn’t exactly explain what this would do for OpenGL very well. The substantive question, to my mind, that was not answered was, “Does this mean that greater resources will be devoted to OpenGL in the future?” The biggest problem with the ARB, from an outsider’s perspective, seems to be just the lack of resources they have. They’re a volunteer service; a member can’t actually take the time to write an SDK, because each of these people have tasks for their respective companies to perform. Does Kronos have an actual Kronos-only staff that would be responsible for such tasks as the SDK?

Bad:

• The substance of Bill’s article. Isn’t this the kind of thing that an abstraction should, you know, abstract? Really, is this something that a high-level language should force upon the user? Sure, the user should have texture+derivative texturing functions. But for them to have to specify them explicitly just because of a varying in a conditional? It’s not like a varying is a runtime-thing; you knew it was a varying when you compiled the shader. Come on, guys; you can do better than that.

• Doing away with the old-and-busted OpenGL state-based object model. That’s going to be one brutally massive extension, if this will extend to all objects everywhere. It may as well be a new API, because that’s what it will be.

• Speaking of which, absolutely nothing was said about the most important thing in that GameDev article: the new API. Is it coming? Is it going to be some ES/GL merger? What’s going on in this department? The new API is the future of OpenGL; it’d be really nice if you could tell us something more substantial than that article did (like, whether it’s still happenning, etc).

Comically Ironic:

• Superbuffers Working Group Update. They’re making a new OpenGL object model. And the async guys are going to use it for their async thing. Good for all involved.

It’s funny; I seem to recall that we already had a new OpenGL object model. It did everything that the Superbuffers people needed. It was even implemented and well-proven with the ARB-extension verison of glslang.

But the ARB decided to throw it away in favor of the old-and-busted state-based version. Allegedly because maintaining 2 object models would be considered confusing to the user (also funny, considering that’s what they’re doing now).

Maybe if they hadn’t done that, and instead used the new one in all core 2.0 technologies, we wouldn’t need to be making a second new object model.

Looks interesting, I missed it so thanks for pointing to it

I’d like OpenGL 3.0 to be the OpenGL 2.0 “Pure” 3DLabs described, which is somewhat what OpenGL|ES 2.0 is.
A nice, clean API, even if it breaks compatibility would be welcome, we would still have current OpenGL drivers for ‘legacy’ apps and a new one for the new version… (which could also get us MS free on windows platform ?)

New Object model is really nice, I keep changing and restoring states in my engine to change a bunch of parameters here and there, quite annoying.
What I’d also like is the removal of Texture States in the Texture Objects, although I understand it can be useful, it’s AFAIK not how the hardware works, and not how the other API works, so any abstraction compatibility layer wouldn’t take advantage of the OpenGL model… (which isn’t that great if you have per shader texture parameters)

ARB_sync is a nice addition.

Interesting infos in the Texture Functions & GLSlang article, but I agree with you Korval, isn’t a high level shading language supposed to make our life simpler and abstract that kind of things ?
Isn’t that something that can be done in the compiler ?

Take a look at D3D10. In my oppinion, D3D9 was nice, but OpenGL was better in some points. Now D3D seems to remove all issues, which OpenGL doesn’t have and it also seems to be a very nice and well designed API, which really leaps ahead.

I still like OpenGL better, because of its philosophy and clarity (theoreticall), but i think i will be switching to D3D10, just because it is much better than OpenGL is now, and experience shows, that it might take years for OpenGL to catch up. And experience also shows, that OpenGL always tries to be backwards-compatible, which usually is a nice thing (for CAD developers), but when it comes to incorporating new technology it can be a real pain in the butt.

I really hope, that there will be OpenGL 3.0, which makes a clean break and becomes competetive again. But i don’t really see this happening in the near future and i don’t want to play the “how long can you wait”-game again.

Jan.

Originally posted by Korval:
Doing away with the old-and-busted OpenGL state-based object model. That’s going to be one brutally massive extension, if this will extend to all objects everywhere. It may as well be a new API, because that’s what it will be.
We are talking about OpenGL 3.0, which will introduce a new API while deprecating (but maintaining backward compatibility with) the old. The new API will likely appear in a series of extensions to OpenGL 2.x, as we migrate toward 3.0 and soak-test the new API.

Speaking of which, absolutely nothing was said about the most important thing in that GameDev article: the new API. Is it coming? Is it going to be some ES/GL merger? What’s going on in this department? The new API is the future of OpenGL; it’d be really nice if you could tell us something more substantial than that article did (like, whether it’s still happenning, etc).

Yes, its coming, its a big project and this is part of it.

[b]
It’s funny; I seem to recall that we already had a new OpenGL object model. It did everything that the Superbuffers people needed. It was even implemented and well-proven with the ARB-extension verison of glslang.

But the ARB decided to throw it away in favor of the old-and-busted state-based version. Allegedly because maintaining 2 object models would be considered confusing to the user (also funny, considering that’s what they’re doing now).

Maybe if they hadn’t done that, and instead used the new one in all core 2.0 technologies, we wouldn’t need to be making a second new object model. [/b]
The GLSL object model was a relatively incremental change over the legacy model and did not change enough to justify carrying the two models. The GL3 model is dramatically different.

If you’re coming to SIGGRAPH, be sure to attend the OpenGL BoF on Wednesday night.

Originally posted by Jan:
[QB] Take a look at D3D10. In my oppinion, D3D9 was nice, but OpenGL was better in some points. Now D3D seems to remove all issues, which OpenGL doesn’t have and it also seems to be a very nice and well designed API, which really leaps ahead.
/QB]
If D3D10 is good, then OpenGL can learn from it.

However, lets not forget D3D10 is only available for Windows Vista, which isn’t even out yet. All D3D10 apps will only ever run on Vista, which will only be realistically available on new machines early 2007 onwards. It’ll take a number of years before Vista has significant market share, till then its just a tinny niche compared to what OpenGL app can be rolled out on.

From new Kronos stewardship I would like to a real drive towards OpenGL 3.0 and bringing together OpenGL ES and OpenGL. Get prototypes out early, get the OpenGL community involved.

Originally posted by Robert Osfield:
[b]If D3D10 is good, then OpenGL can learn from it.

However, lets not forget D3D10 is only available for Windows Vista, which isn’t even out yet. All D3D10 apps will only ever run on Vista, which will only be realistically available on new machines early 2007 onwards. It’ll take a number of years before Vista has significant market share, till then its just a tinny niche compared to what OpenGL app can be rolled out on. [/b]
I have to agree to this, it will be a couple of years before D3D10 is commonly accepted as a viable platform, but during that time both Nvidia and ATI will have released their D3D10 hardware.
Along with that hardware comes a string of new openGL extentions that will provide most of the SM4/D3D10 functionality (though in a slightly more fragmented way).
So while SM4 for openGL will be mostly a patch job until openGL 3.0, it will still run on that hardware without vista, and that is a whole lot larger user base than D3D10 will ever have.

The new API will likely appear in a series of extensions to OpenGL 2.x, as we migrate toward 3.0 and soak-test the new API.
I don’t suppose we’ll be seeing those extensions any time soon. However, is there a general timeframe set for their release (early 2007, late 2007, etc)?

I’d love for the next newsletter to have a large article devoted to talking about the new API (hint hint;) ). The GameDev article was sketchy on the specifics, and I’d like to know what has changed/improved/etc since then.

If you’re coming to SIGGRAPH
I wish…

Perhaps a roadmap should be created to see how GL will evolve.

D3D is becoming a nightmare. The SDK is limited to certain Windows versions and it’s limiting to certain MS compilers. I’m talking about Dx9. What garbage. It has caused headaches for me.

It would be good if there was something for supporting truetype text in GLU. Nah, I don’t want to use GLTF or whatever that crap is. It doesn’t compile and there is no support.

The problem with GLU is that glu32.dll is a Windows component and has not been updated since 1997.

We’re going to have to provide a replacement for GLU which can actually be updated.

Originally posted by Robert Osfield:
If D3D10 is good, then OpenGL can learn from it.

However, lets not forget D3D10 is only available for Windows Vista, which isn’t even out yet. All D3D10 apps will only ever run on Vista, which will only be realistically available on new machines early 2007 onwards. It’ll take a number of years before Vista has significant market share, till then its just a tinny niche compared to what OpenGL app can be rolled out on.[/QB]
I totally agree. However, i’m not concerned with platform independency, so i can just say, my app only runs on Vista, which is no option for many other people, of course. And also, i like D3D10 because it’s an API i actually HAVE. I have Vista Beta and i have the SDK with documentation. Granted, it’s in its early stage and it’s software rendering only, but i can actually work with it and with MS pushing it that hard, i know, that it will become standard in a limited time-frame. We all know, that the people behind OpenGL are very skilled and a clompletely redesigned API might be even much better than D3D10, but at the moment that’s all speculation. And the time-frame is unknown. I don’t think that we will have OpenGL 3.0 in sooner than a year and changing an engine to make GOOD use of an entirely new API takes time. Good drivers also take time.

Well, if OpenGL 3.0 is from the broad concept close to D3D10 (everything virtualized, no FFP, state-objects, texture-arrays, …) it shouldn’t be too difficult to support both, when it’s available.

Jan.

Originally posted by Jan:
I totally agree. However, i’m not concerned with platform independency, so i can just say, my app only runs on Vista, which is no option for many other people, of course.

Few people have the luxury of writing software for a beta platform, that even once its released will be years before it has significat market share.

Well, if OpenGL 3.0 is from the broad concept close to D3D10 (everything virtualized, no FFP, state-objects, texture-arrays, …) it shouldn’t be too difficult to support both, when it’s available.
Jan.
Well if OpenGL 3.0 does achieve this then D3D10 becomes enitrely redudent, you only need to target it to get all the feature you want. The bonus of this your are able to develop and deploy on many many more platforms.

Khronus need to sell the very real benefits of OpenGL, and they need to get moving on OpenGL 3.0.

The graphics community also needs to support Khronus in this work, spread the message, help develop and test the emerging API and implementations.

Personally I’d be happy to have some beta API published for OpenGL 3.0 which like D3D10 are largely software based, and perhaps layering over the top of OpenGL 2.0/OpenGL ES2.0. Then get middleware developers like myself testing the API out and help debug it/refine it. At the same time as this we need IHV’s to step up and implement the back ends to get everything working natively in hardware.

Unfortunately I won’t make it to SIGGRAPH this year, but I look forward to hearing of progress. More news letters, and more direct engangement of the OpenGL 3.0 developers would be very welcome.

And to Khronous members, support US and we’ll support you

Robert.

Thanks for the link. I usually make a b-spline for the forums and miss the latest news on the main page.

The newsletter is really nice–hope to see many more. I was struck by the section on the Ecosystem Working Group, and its charter to, among other things, oversee development of an OpenGL SDK.

I’m really looking forward to seeing the new API. As a big fan of occasional reinvention, this is all very exciting!

Few people have the luxury of writing software for a beta platform, that even once its released will be years before it has significat market share.
I wouldn’t say that it will take years before it has a significant market share; that won’t take more than a few months. However, because DX10 is Vista only, a DX10 app is Vista only. It will take years before Vista is in such a dominant market position that game developers (that aren’t owned my Microsoft) can afford to make their games Vista only.

Originally posted by Jan:
Well, if OpenGL 3.0 is from the broad concept close to D3D10 (everything virtualized, no FFP, state-objects, texture-arrays, …) it shouldn’t be too difficult to support both, when it’s available.
what’s ‘virtualized’ in D3D10?

i typed “winxp marketshare” into google + get the following
http://www.w3schools.com/browsers/browsers_stats.asp
( now i dont know how accurate these figures reflect game players, prolly to high win2000 number )
fwiw winxp launched 25 oct 2001 and had ~30% march 2003.
i doubt we’ll be seeing any big d3d10 games (except as korval points out ms ones eg halo2) until 2008 at the earliest
i believe the xb360 d3d >= 9.0c but less than d3d10

Originally posted by 3k0j:
what’s ‘virtualized’ in D3D10?
The whole memory handling. That means all resources, ie. textures, vertex-buffers, framebuffers, and so on. There are no “lost surfaces” anymore (a problem that GL never had), render-to-texture/vertexbuffer is as easy as it should be, the fixed-function pipe is gone, there are no texture-units, you bind your textures to a “shader-semantic” (by name) and you can use arrays of textures (which one would today do by putting them into a 3D texture or a texture-atlas to freely access several textures on one texture-unit - of course this has lots of disadvantages).

Jan.

Even if D3D10 is no option for you, it’s an interessting read, because it’s a preview of what’s possible in the near future.
Therefore, if you want to know more, download the latest DirectX SDK, you don’t need Vista to read the documentation about D3D10.

Originally posted by Korval:
I wouldn’t say that it will take years before it has a significant market share; that won’t take more than a few months.

How big is significant? 10%? If we assuming that that w3schools stats for WinXP as a base then this will likely take six months.

However, because DX10 is Vista only, a DX10 app is Vista only. It will take years before Vista is in such a dominant market position that game developers (that aren’t owned my Microsoft) can afford to make their games Vista only.
This is a great opportunity of OpenGL 3.0, rather than target DX9 and DX10 in you app, just use OpenGL and you’ll be able to run everywhere with just one API, it’ll be able to blitz the market share that DX10 can address in no time at all.

Personally I’d encourage Khronous to push ahead with a clean OpenGL 3.0 prototype, and don’t worry about backwards compatibility, time to market is more important, its D3D10 that you are competing against.

Backward compatability if it can truely be layered can be done as an open source add on to OpenGL3.0. Could MESA be picked up and ported to sit on top of the OpenGL 3.0 prototype? Could another open source project be spawned to do this?

There is also the other side, extensions to OpenGL 2.x that encompass some of the new functionality in hardware, these too need to happen in parallel to OpenGL 3.0 effort, focussing on existing OpenGL apps that would like to add a little extra functionality without major restructing.

Then a couple of years down the line when the OpenGL 3.0 is a stable API and implementation, and the open source layer on top is mature existing OpenGL 2.x apps will just be able to port across with little effort.

Another aspect to consider is the growth of languages like Python, Ruby and Lua for rapid app developement. Perhaps if one supports the development of languages wrappers early on in the life of OpenGL 3.0 you’ll be able to ride the wave of these development communities as they take software engineering off in new directions.

We need a bit of hussle and excitment around OpenGL, its already one of the coolest API’s on the planet, and able to awsome things on so many platforms. Lets see a unified OpenGL ES and OpenGL, lets see OpenGL 3.0 prototypes out early, and thriving development communities built around it.

Robert.

Another aspect to consider is the growth of languages like Python, Ruby and Lua for rapid app developement. Perhaps if one supports the development of languages wrappers early on in the life of OpenGL 3.0 you’ll be able to ride the wave of these development communities as they take software engineering off in new directions.
OpenGL, and probably not even the SDK, should even consider touching these. You want RAD 3D, make an official .NET OpenGL implementation (or get the Mono guys to do it for you). But delving into scripting languages is not something that the ARB/Kronos should be bothered with.

Originally posted by Korval:
OpenGL, and probably not even the SDK, should even consider touching these. You want RAD 3D, make an official .NET OpenGL implementation (or get the Mono guys to do it for you). But delving into scripting languages is not something that the ARB/Kronos should be bothered with.
Creating wrappers is pretty easy with OpenGL being plain C. It takes a couple of lines of Swig interface code to build language bindings for all the main languages.

This needn’t be done by Khronos members, but it needn’t be a big distraction. The SDK effort itself could/should involve the wider community too.