Meeting Notes

I’d like to quickly address an issue brought up in the December ARB meeting notes.

“Nick is concerned about slow atrophy of OpenGL developers / apps to DX.” [ Note, not this Nick ]

I’d just like to state my observations for why this is. For anyone else with similar observations or contradicting evidence, I’d like to encourage you reply. Lets see if we can get a useful discussion going that lets the ARB know a little more about what developers are thinking.

Lets put things about driver quality aside for this discussion, as those are endless persuits. Also, PLEASE lets not let this degrade into a flame war. If we’re going to learn anything from this, it needs to remain an honest discussion where people can say whats on their mind.

First, I’d like to say I’m really glad to see Septembers meeting notes - the ARB looks like its on the right track.

Now, without futher prolongment, here is what I’ve observed over the last seven years of working with OpenGL.

The availibility of a standarized (and well written) math, and image libraries have an incredible sway on developers. I fully understand why these have been left out of OpenGL, but they do often influence the decision of which API to use, especially among new developers. A lot of people claim that good libraries exist, but most of these are GPL’d, which keep many people away. Could glu be extended to offer some of these features?

There are a new set of common tasks since glu’s inception ( including the already mentioned, as well as things like generating TBN basis ) that could be covered.

While OpenGL has recently added Vertex Buffer Objects and a high-level shading language as an arb extension, these features have already been in Direct3D for some time, and have had a chance to develop. I saw a large number of people transition to D3D when HLSL was delivered.

Personally I would still like to see an OpenGL effect framework. I’ve asked about it here in the past, as something that could be added to glu. Having used the Direct3D effect framework, I often find myself wanting for something similar in OpenGL.

I often hear standard complaints about having to use extensions for everything in windows - but this is a well known issue, so I really don’t have much to say, except mention it. (Yes, there are good libraries to handle this - but again many people dislike having to deal with GPL or similar licencing.)

Direct3D handles backwards compatability in a totally different way than OpenGL. That is, syntax is allowed to be updated completely to reflect new and better ways of doing things, while culling redundant portions of the api. Developers get the sense that their api is more up-to-date because there is less clutter. The “if you dont need it dont use it” argument really doesn’t change the perception of things.

While OpenGL’s backwards compatablility is one of its strong features, it also leads to a “messy” api.

There are other things that belong halfway between the windowing system and the graphics library that are exposed in an “ugly” way. Things like setting up a pbuffer as a render-target could be added as a glu function (or perhaps some new library? )to totally abstract the platform dependency.

Anyway, I’m sure there are other issues that people have seen that are causing people to choose alternatives to OpenGL. At the same time, these things may attract some people to OpenGL. I’d like to point out that adding things to glu or a similar library doesn’t force people to use them - they’re not even core OpenGL - they just give people options.

The prevalent issues I’ve seen brought up in my private API wars have been
1)common interfaces to “DX8” class shaders
2)toolkit stuff (eg texture loaders)
3)“reliable” high level shading language compilation

The last point has been somewhat frustrating to me, as I see the GL model of automatic compiler updates with driver updates as beneficial. A certain professional whom I respect a lot told me he’s quite concerned about guaranteed compile success/failure conditions, which an unknown compiler version can’t provide. The DXG shader compiler is statically linked, so the ability to compile a certain shader to a certain target can be checked and is known to never change.

General discussions about OpenGL’s flexibility, especially the extension model are often fruitless. Arguments often proceed somewhere along these lines:
a)Extensions are a mess
b)Aren’t caps just as messy?
a)No. Caps are platform portable
b)True, but caps have an upper ceiling, so you risk missing out on hardware capabilities.
a)I’d rather miss out than having to write lots of different paths
b)You have to write paths for different sets of caps in DXG, too.
a)But I can share a lot more code because there’s only one interface to each cap.
b)This is a mere polymorphism problem. You can wrap similar functionality transparently.
a)This is rewriting DXG runtime functionality. Why do that when MS already provides it?
b)Because you can choose yourself, which maximum feature set you want to address. You’re not limited by MS’s choices.
a)MS’s choices are good enough for me. I don’t feel limited.

On this basis, it’s very hard to convey the universally positive sides of OpenGL, because these other ‘issues’ seem to overshadow any honest discussion. I’d like to draw up a few points
1)extensive texture/pixel/vertex attribute/index type abstraction. If it weren’t for DXG (and in part ARB_vbo) forcing a lockable memory model on all consumer hardware, this would present ample opportunity for hardware optimizations

2)arbitrary state encapsulation via display lists. E.g. you can just make yourself “fragment shader objects” on a lowly RivaTNT. Or whatever you please.

3)immediate mode support and arbitrary interleaved and separate vertex array layouts; great for rapid prototyping.

4)the opportunity to fully use any given piece of hardware (think NV20). “Standard” paths are still available, if extensive optimization isn’t justifiable.

What OpenGL or rather its implementations more or less immediately need to be attractive is a common high-level “shader” parser for targets below ARB_fp level. This is the one area where DXG hits hard. AFAIK HLSL can be compiled to “DX7” targets, which is a huge productivity advantage.

I’ll comment on a forced defection to DX for one recent app I wrote. The core reason was that my client couldn’t stomach the fact that their customers had to manually upgrade their graphics drivers to use OpenGL (the most commonly observed behavior for most vanilla windows machines was to fall back to software rendering…).

GL2 has to compete with an OS-blessed system that “just works”. Even if it means building an official redistributable “gl_setup” installer app that just rolls up and selects from all IHV drivers as of a certain date, that would be an improvement for this use-case. A small-footprint web-centric installer system (where IHVs would upload their latest drivers under the official OpenGL.org banner, blessed or not) would be even better.

My other general comment is that GL has the critical advantage and disadvantage of being governed by consensus. I’d like to see the ARB make better use of the advantage part of that. It’s reasonable to have the low-level features and API gated by the IHVs and their cost/time/complexity concerns. But the ARB should, IMO, also get into the role of blessing open source additions beyond the core (in the form of separate libs and headers, of course).

This could be a formal ARB review process for blessing and adopting (i.e., featuring on OpenGL.org and bundling into a generic “OpenGL devoper kit”) open source projects in key areas, with the rules being that this source code is totally free to use, and it meets certain community standards for completeness and competence in API and implementation. It’s fine if these libs are pre-existing, but I’m sure you’d get a bunch of volunteers for any new pre-blessed efforts. I have no doubt the ARB would get some very able volunteers both on the review side and on the developer side of things. I don’t think the ARB needs to manange anything, just review the finished products and then bless.

The areas I’d imagine are of most common use are (in order):

• Extension binding and feature query
• OS-management, ala glut, analogs to DirectInput and D3DX (wgl) with “one-step” easy window creation.
• Math library, ideallly with an optional C++ compile-time API-overlay and FVF-like (or better) class overlay on VBO.
• Image library (just loaders are enough to start), ideally with optional glTexture class.
• Expanded Effects plug-in system
• Scenegraph (yes, I said it)

As I said, these can be selected from a review of existing efforts (if licences are compatible) or new group efforts.

That’s all I want to say on the DX/OGL thing.

[This message has been edited by Cyranose (edited 01-23-2004).]

Hello All,

This is a very interesting topic, espeically since all the statements have been well thought out.

I would like to see an OpenGL SDK containing:
-Image loader
-Math Library
-OS management (as Cyranose called it)
-Mesh Loading (There are lots of talented people around, so i am sure they can come up with a nice format)

The main issues I have with GL is the versioning. What I would love to see is a SDK found on this page something like OpenGL SDK 1.5 download.

The file would contain the header files for 1.5 as well as the libraries. Of course the manufacture would still have to create the runtime libraries for the card for optimization.

This would be really useful if the runtimes could be automatically downloaded. Or something like that anyway.

The big thing that I would be interested in for the sdk is to have a software mode, I would like to develop something that uses advanced features but I don’t have the card to run it.

I like gl but in windows I find the version difficult to understand unless of course you just get the version from a gl call.

Thanks, Ben

These are the gripes I hear most of the time from people using Direct3D:

• The extensions mess. I think this has largely been solved, it’s more of a marketing problem. The solution is to adopt one of the available open source wrapper libraries that already exist and have it available for download together with headers and linkable lib files on opengl.org. This is only necessary for windows.

• The lack of a single interface for Ps1.1 level pixel shader functionality. I doubt the IHVs are interested in spending time and effort on this but it should be fairly easy to include a single “dumbed down” interface that translates into combiners or equivalent behind the scenes. X-Engine already has this functionality for example. Put this in the SDK as well.

• D3D makes it much easier to render to texture. If the super buffers extension doesn’t solve this, put some glue code for handling p-buffers in the SDK as well.

• GLSL are far from being mature while MS’ HLSL compiler largely is. Hard to do anything about this. It’s a natural consequence of the choices made for GLSL (driver=compiler).

Other ideas:

• Market how light weight the OpenGL API is. You don’t need to batch as excessively as in D3D and your calls don’t go through some unknown massaging process in the MS runtime before they reach the driver.

• Expand glu to handle common utility function possible today like TBN-computation, shader handling etc. No need for the IHVs to do this, could be a liberally licensed community effort.

• There already is a way to distribute drivers: Windows update. If the IHVs make their drivers appear there, you can just tell the user to click Start->Windows update and they will have newish drivers.

Part of the problem is that there’s not currently a way to update GLU on Windows systems. That’a Microsoft supplied library, and Microsoft doesn’t seem interested in updating it.

This, in my opinion is what is needed to get OpenGL to the forefront again.

1 - the ARB board is quite slow in advancing OpenGL to the next level. The reasons for that (from what i read in ARB meetings) are the many dissagreements between ARB members. each of them (especially IHVs) is looking at what benefits his/her own company and not the general good of OpenGL … MS on the other hand develops DX using 1 leadership/command and control stucture and thus MS is more efficient. As long as IHVs are bickering with each other over trivial IP issues, then this API (OpenGL) is going no where. People, compete on the efficiency of the implementation, not on shader formats/instructions/other shader issues. Users will buy and use the fastest/most efficient products. And this is where you should compete.
2 - Support: IHV’s need to support OpenGL just as they do with DX, that is, GL drivers would be released with the same features as DX at the same time … this way, OpenGL users/developers wouldn’t have to wait for a long time (sometime years) for new features to be added to OpenGL. One of the comments I read in the ARB meetings notes, is one IHV claimnig that a certain feature (which is a core feature in DX) is not vital to be implemented in OpenGL since there is no vendor demand for it … well, there is no vendor demand for it, since it doesn’t exist in OpenGL to begin with … heck if such features were not important then software vendors wouldn’t be defecting to DX and would have just used OpenGL instead … moving from OpenGL to DX is costly since it takes time and money to retrain your staff and port your code over from one API to the other … now, why would a vendor incur such costs to move to DX !!! … certainly not for the heck of it.
3 - The state of OpenGL now is very fragmented and frankly it is loosing its platform independence because of ugly rag tag specs like the ones for pixel buffers. first it is a WGL extension … now, why would you need that in such a form ?! … as a developer, i would prefer to have a function that would simply return a render target of specific attributes, so that i can effiecently use it with other GL functioins … and this function should be in a glFunc() format … this way i wouldn’t have to redo the whole thing when i port the code to unix …
4 - Helper LIBs … for loading images, etc … these LIBs can be Open Source using the LGPL or FreeBSD license or any other license that would allow Open Source developers to pitch in and in the same time allow commercial use of such LIBs … those LIBs should have a body controled by the ARB that would actually create the specs and manage the submissions from Open Source Developers … I think an ARB WG is needed to be formed to handle this.
5 - Dedication: from what i also understand from the ARB notes … IHVs are also not dedicated to OpenGL … they simply develop for it when they “have the time and resources” … unlike DX … they always work with MS to get those drivers released on time … so if IHV’s are not dedicated to OpenGL and will continue to provide a feable effort in supporting OpenGL … then just say so and we will all be happy to move to DX … but just don’t waste our time.
6 - Tools … IHV’s provide tools for DX, eg. RenderMonkey by ATI … but nothing for OpenGL … so go back and read point 5. again Open Source could handle this … but the ARB has to lead by placing the specs and providing the standards that developers can use.
7 - File formats … its about time to develop a format that would be native to OpenGL … DX has one … having such format would be a great aid for students who are learning and using OpenGL in schools/universities and would help create legions of future OpenGL developers and products.
8 - OpenGL 2.0: talk about it started over 2 years ago … that it was the API to revolutionize graphics and … well, where is it !!! the specs on OpenGL 2.0 are great but frankly developers can’t sit around and wait for it to show up while they already have most of its features in DX … developers need to ship products … so if OpenGL is not there, they will use DX … only fanatic OpenGL developers will stick by it … but for how long? … 3DMax has been ported already … half-life is in DX now … so deliver on your promise … on time.
8 - have a central downloads area on OpenGL.org for all drivers/SDKs/GLUs/GLUTs … this way the user would not have a hard time getting his driver(home user) or SDK(developer, just like MS … you can get SDK from MS site … that is, use OpenGL.org name just as MS uses it web name.
9 - awareness: IHV’s should promote OpenGL in E3, … etc. to developers and users as well … get the name out there.
10 - provide better insight on the internal resource use by gl functons so that developers can optimize their use and produce faster graphics.

Users will buy and use the fastest/most efficient products.

Speaking as a user burned by the Radeon 9600, I will buy the product with the most correct implementation. Speed is a distant second.

1: That’s how democracy works. It’s slow and inefficient, but it usually arrives at the better solution.

2: nVidia does a pretty good job at this. To do it, because the GL spec is always behind the hardware, they create a lot of propritary extensions (NV_*). ATi, on the other hand, makes extensions less frequently, relying instead on the ARB extensions to support more functionality. Which method do you prefer?

3: In “defense” of pixel buffers, it relys on context switching for rendering, so it has to be wgl. Now, why it relys on this instead of a mechanism like what ARB_superbuffers will use, I can’t say. The ARB has made some good decisions, and some less than good ones.

4: The ARB doesn’t actually employ people. Rather, they ask for the time of some employees from their members (for working groups and spec writing). They can’t actually get programmers to build and, more importantly, support code because they don’t have the resources to do so.

7: Are you refering to model formats or shader formats? If you’re talking about models, then I’m not sure I see the need. Model loading code is pretty basic, and most university professors/teaching assistants can handle writing such code. Shader stuff is a different story. I’m personally against having this code as part of the API, but as for it being part of an external library that is endorsed (and supported) by the ARB, that would be fine.

8: The difference there is that you have to download 2 things: your card’s driver and the OpenGL runtime. If the runtime is going to be updated again, then you have to get the right version for your card’s driver. Take R300 hardware, for example. Because certain functionality was made core 1.5, they have yet to release 1.5 drivers (as they would have to emulate that functionality). So, you would have to make avaliable a 1.4 runtime. Unless the runtime has dynamic versioning, doing GetProcAddress internally for the user.

What would be better is to have a program that goes out and just downloads and installs the necessary software. Like what GLSetup used to do before it stopped being supported. This requires some minimal cooperation by IHVs (mainly, keeping current drivers in some particular place).

9: Didn’t the notes say that they were going to start stepping up marketting of OpenGL?

10: That’s a difficult one. D3D can do it, because the IHV-portion of D3D is rather small. Much of D3D’s performance limiting problems are derived from the common library itself, not the IHV-code. So there is a single set of things to optimize for. OpenGL is quite the opposite. The performance limiting code is all IHV-code. So, you would need to have information from each IHV, some of which is contradictory.

The better way to solve this problem is to release a set of OpenGL programming guidelines: the right way to use VBOs, the correct method for uploading textures, etc. Then, you have the IHV’s optimize for these guidelines. This will encourage developers to follow them.

Speaking as a user burned by the Radeon 9600, I will buy the product with the most correct implementation. Speed is a distant second.

What happened with your 9600? I’ve had nothing but success with my 9500 drivers (a few bugs here and there, yes, but nothing extraordinary or world-breaking).

[This message has been edited by Korval (edited 01-29-2004).]