The ARB announced OpenGL 3.0 and GLSL 1.30 today

OpenGL
361

Would it be possible for the deprecated features in OpenGL 3.0 to be migrated from core OpenGL to the GLU Library. If these features have been earmarked for removal because they are unlikely to be implemented in hardware but the CAD developers don’t want to loose them because they rely on them I wonder if these functions could not be moved to the GLU Utility Library and implemented as software. In practice if may of these features were never implemented in Hardware in the first place it would be just like making it official that these functions are only going to be software. The CAD developers would have to do a little alteration to their code but at least the rug would not be pulled out from under them. Conversley it might be easier to remove the deprecated functionality more quickly if there is a cussioning measure such as this put in place.

The other idea which I think may well have been mentioned already but I will mention it again if not is to have 2 levels of the OpenGL implementation. An OpenGL Core implementation and an OpenGL Extended implementation. The OpenGL core implementation would cover the core graphics functionality which should be available and be concice enough to be implemented on regular desktop computer graphics cards. The extended implementation would contain the core implementation and add features which higher end graphics workstations and render stations need. These are features more likely to be implemented by high grade workstation graphics cards. The driver writers then for the desktop have a simplified API to implement hopefully simple enough to be implementable in hardware. The special needs of the workstation graphics users are still catered for with a set of extra features which may be implementable of high end workstation graphics cards.

Programatically there could be a mechanism put in place to check whether the OpenGL platform on which you are developing is just the core version or the extended version. The core api is still the same for both. Hopefully these core features can be refined and improved at a faster rate than perhaps the extended features as the gaming industry being fast paced would be developing only against OpenGL core where the more slow paced CAD industry would develop against the extended API. This would have a practical implication that CAD might no longer run on regular desktop hardware and require workstation grade graphics cards (many entry level workstation graphics cards are still in the price range of higher end gaming cards). I don’t think this requirement is neccecarily so limiting given that the industries which use CAD may well be used paying AutoDesk through the nose for their software and the cost of a workstation graphics card may pail in comparrison to that.

362

GLU should definitely be updated. Stuff like matrix stacks and fixed-functionality implemented as a vertex and fragment shaders would be good candidates.

363

What are you talking about? Who wants a 3rd in this dual game of Khronos and Microsoft?
I sure don’t.
Why do you mention open source?
I don’t need a open source driver.
The community here at opengl.org are mostly software developers and are not likely to spend time understanding the details and interactions of the OS and hardware. I should say multiple OSes and multiple GPUs.

364

I respectfully but strenuously disagree.

365

Well software matrix operations and a stack would be useful, but shaders? It wouldn’t be anywhere near worth the overhead and what hardware resources are you gonna burn for your stack, and how are you going to efficiently store your results back in uniforms for other programs? Threads have to be compiled and at least scheduled on the GPU (the instructions are cached) and matrix operations don’t scale like vertex transformation, you have a few vector operations at a time and they’re inherently serialized. There’s not a lot of work to be parallelized. I think generic register (uniform) stacks would be genuinely useful for this but are probably impractical with scale, but it depends on architecture.

However there’s definitely a class of usage that benefits from canonical transformation matrices, offloading that from the core graphics pipeline at best complicates graphics utilities that need to interoperate in meaningful ways. Even if the pipeline uses software.

Matrix libs abound, and probably belong in software (which also has it’s own vector instructions let’s remember) for most usage these days. I think it’s a loss for students, code interoperability and convenience, but that’s all. I personally have an aversion to using GLU, it always feels like it’s the dumbed down red headed step-child (my aversion started with gluLookAt, which is overused :-)), but maybe I’d use it for a matrix lib, on the other hand I have matrix code already as does just about every other graphics hacker. It’s not heavily optimized and I haven’t given it too much thought, I may have to now.

It’s worth losing this for the cleanliness and generality of the API. Go look at the OpenGL ES 2.0 API and glslang. After your initial loss you realize that this is closer to how things would have been done if you built this in a cleanroom without the legacy. Atributes and uniforms have no special status except the function given to them by your shaders. Now you could always have(mostly) overloaded these in the past (or even ignored it), but now it’s inkeeping with a normal programming language. When you see that you wouldn’t want anyone stinking up the namespace with legacy tokens provided the usage can be optimized for in the compiler. Of course now you can get some fool hand you a shader with variables called a1 a2 etc. (as a friend mentioned the other day) but bad coders have always been around, now they have an invitation to obfuscate shader code too.

366

The best solution is, of course, to have the IHVs contribute to the open-source drivers. Intel already does this with their audio, networking, and graphics drivers (although I believe the GFX drivers are released obfuscated).

If every IHV contributed an open-source backend to, say, Gallium (and I know I mention Gallium a lot, but DRI sucks, and Gallium can theoretically be run on any platform), then any new API could be created and layered on top of Gallium (which is what Gallium is designed to allow).

And for those who don’t know: Gallium runs a lot like direct-x. There’s a kernel-mode driver that exposes a uniform API to the runtime. That API could (assuming you can get the drivers signed by MS and APL, which I think we all agree is unlikely or impossible) be created on any platform. Unlike DX, however, that mid-level API is known, so multiple runtimes can take advantage of it. OpenGL, OpenVG, even a native Linux DirectX implementation. All you need is the runtime and an X extension to support the context creation.

367

Download the latest Mesa tarball. Look at src/mesa/drivers/dri/i965. It doesn’t look obfuscated. It even has some comments explaining the code.

Philipp

368

The slides from the OpenGL BOF are now available:

http://www.khronos.org/library/detail/2008_siggraph_opengl_bof_slides/

Barthold

369

Is there any word on OpenGL 3 tutorials from the ARB? Cause not everyone can plunk down $3000 for a five day course.

370

Well, one thing i really expected from OpenGL 3 was a reall SDK to come with. Sadly, we still dont have that. Maybe thats why DX grass is greener for some peoples at the moment:(

371

When I picked up the 3.0 spec, I thought, “excellent, two years have gone into making a shiny new API”… having read it, it seems all we have is even more extensions on top of OpenGL 2. Is this crap really OpenGL 3.0? This is just unacceptable, we waited two whole years, and what? We’re supposed to keep using the same API we’ve been using the last 15 years along with all of its problems, no proper SDK, and not complain?

My expectations were to have a new API started from a blank piece of paper - a chance for OpenGL to really redesign itself into a modern API. I also thought it would finally be accompanied by a proper SDK with headers and libraries that just worked so long as you are not using extensions, instead, we MUST use extensions just to access even the core OpenGL 3 functionality. I figured the new SDK would also have a cross-platform way to get the extensions, so at the very least, if I did choose to step into the realm of extensions, at least I could do it in a cross-platform manner that is officially supported by the SDK itself. The SDK I envisioned also had proper (up-to-date) documentation for programmers, not cryptic specs for IHV’s and ancient reference manuals for version 1.3. It would also have a wealth of tutorials and sample code - I know it is really difficult to understand (sarcasm) but look at Direct3D and just about every other API’s SDK on this planet made in the last 10 years for an example of what I’m talking about.

I also expected fast turn-around from our new shiny API and the khronos group, none of this, 2 years and we still give you absolutely nothing crap… I was wrong to have high expectations of the khronos group, this spec is one huge disaster, and you did not help OpenGL at all. For all I care, OpenGL can cease to exist now, I’m sick and tired of putting up with it. Simply put, OpenGL is one huge mess, it has been for the last 7 years now, we don’t need even more extensions, we need a proper support group that will go back to its roots, fix it, and modernize it into a good, modern API that is easy to use and accessible to everyone.

Two years have just been wasted, OpenGL is even more ancient now, Direct3D is looking like a pretty attractive, modern API. To try and combat this, I propose that we do the following:

  1. Rename OpenGL 3.0’s spec to OpenGL 2.3 - this sticks to the idea of a 3 release, but clarifies that it is merely a small extension of OpenGL 2.
  2. Break away from the khronos group and get rid of anyone who had anything to do with the OpenGL 2.3 spec, thus making sure they don’t have any input into the direction of the true OpenGL 3.0 spec… I’m sorry, but you guys clearly do not know what the software developers who actually have to use your APIs want. You also failed to understand how important it is to make a modern OpenGL API we can all use for the next few years without feeling like we’re stuck in the 80s.
  3. remove the deprecations from OpenGL 2.3 and just leave all the old functionality where it is - I’m sorry, I can see where you were trying to go with this, but you fail… OpenGL 2.x should just be ‘that thing’ video card manufacturers support for legacy applications. Ideally, a group would be set up to allow older applications to take advantage of OpenGL 3’s features via extensions, very much like OpenGL 2 today.
  4. Finally, a proper SDK needs to be developed, starting with good user documentation, new libraries and new headers for OpenGL 3.0 that does not require the use of extensions for any core functionality, this SDK also has to be maintained, there is no final spec release made before the SDK is updated as well…

Well, this is my view on the only way to fix this mess. If this doesn’t happen, I will simply drop all support for OpenGL, and I expect that everyone else will probably do the same. It wouldn’t surprise me if this specification release as it is causes the end of OpenGL (gee, thanks khronos group).

Things have to be corrected, I have just summed up in 4 points what the monkeys in the khronos group couldn’t even decide with two whole years on their hands. Well, this is what needs to be done for OpenGL to become a moden API, as it is, I refuse to accept OpenGL 3.

372

As i said in other topic, i was expected too a completely new API + SDK (real SDK, i am tired of “community links”).

Khonos MUST seriously stop a bit and reevaluate themselves.

373

Considering that no real SDK was promised (certainly not after providing the fake one), there was no rational reason to expect a new, real SDK. They certainly never promised one.

Longs Peak was a promise: a declared intent that they were making progress on. They redacted that, and cut contact for 9 months because they knew how we’d react. By all means, take them to task for that. But they never promised a real SDK, so their not delivering is meaningless in that sense.

I expect that everyone else will probably do the same.

What “everybody else”? Most developers who could have abandoned OpenGL did so years ago. GL is the only thing that Linux and MacOSX have for hardware 3D access. And it’s the only choice for cross-platform 3D development.

Nobody uses OpenGL because they want to. They use it because they have no other choice.

374

And this is partly why OpenGL 3.0 fails. Every other API has an SDK, if not that, they AT LEAST have proper documentation. They don’t request that people use hacks to access newer functionality. I consider the whole extension mechanism to be one giant hack, and I don’t care what anyone else thinks, it’s ugly as hell whichever way you look at it.

Don’t you mean a lie? If they knew how we’d react they probably should not have released the spec and just given up and stepped down from the group before this disaster.

Don’t you think there is something wrong here??? It should be an API people want to use… I really can’t believe that people are happy with things staying like this, OpenGL really could have been a great API, oh well, guess it’s over though.

If the ARB wants to try and save OpenGL, I suggest you follow through with my suggestions, 3.0 becomes 2.3, and a group who is actually serious about the future of OpenGL should draft up a true 3.0 spec for the community to comment on. It is not too late to withdraw the 3.0 spec.

375

You have right, check that evil idea: “DirectX is better supported and have a real sdk and good development tools, lets stop the linux/mac support.” or “Lets migrate to Windows”.

I wonder why linux developers and real supporters are so quiet, maybe dont realize the impact of gaming on linux future.

376

Yes, new API may help Linux to become a far more popular OS, because games which supported OpenGL 3.0 render can run well on this OS. Thus a whole Linux community receive nothing with this GL “3.0” release.

377

I wonder why linux developers and real supporters are so quiet, maybe dont realize the impact of gaming on linux future.

I realize that the members of the ARB are working hard and trying to do what they see as best for the community, and I appreciate their hard work. Of course I’m disappointed; I expect that many members of the ARB are too. It’s not helpful to get angry with them, and I think a number of people feel the same way.

It is not too late to withdraw the 3.0 spec.

The naming convention is somewhat arbitrary, and as far as I’m concerned this could be called OpenGL 1.7 or OpenGL 1700. The next revision may not be called “OpenGL” at all. “Fixing” the revision number will not alleviate misgivings, which are about the API itself.

378

None of the slides contains even a single word on the fate of LP. No “what went right, what went wrong”, no execuses… All presentations sound like “Everything went as planned, we are happy with the outcome!”. :-/

379

This is not true at all… People were expecting the 3.0 API release to fix things and make OpenGL a modern, competitive API… instead, it just proved that the OpenGL ARB does not have any intentions of moving the API into the future and shows that our ARB is now overrun by morons with legacy applications that think that avoiding a proper update to the spec will allow them to keep telling their customers that their software is state of the art (because it uses the latest OpenGL)… well… sorry, but now the entire API is ancient and stuck in a phase where it can’t move forward.

So it is in fact a major thing, do you think any 3.x release will suddenly modernize the API? Or give us a proper SDK? The answer, no… if this is the final 3.0 spec, basically, we’re screwed, and so is OpenGL, because it means that the API won’t modernize for at least the next 5 years until the 4.x streams.

By renaming the spec to 2.3, it will essentially tone down its importance, allowing for a proper 3.0 spec to be released by people who are actually serious about the future of the API.

Yes… thanks to the Khronos group we have just lost two years - catching up with Direct3D at this point would be near impossible. However, perhaps it is not too late to save OpenGL. But in order to do this, we need to assemble a group who are serious about bringing OpenGL into the future. This group would be tasked to come up with a spec which will be good for all of the 3.x releases, which can easily be the next 5 to 10 years so it really needs to be done right the first time.

As a result, it would be advisable to regularly release draft specifications to the public for commenting as well.

380

As a linux user (and developer), I can say that there’s probably no outcry from us because we really don’t expect much. We’re pleasantly surprised when non-open hardware drivers don’t cause daily kernel panics, and absolutely overjoyed when somebody actually publishes a real commercial game for us to play (was neverwinter nights the last non-fps for Linux?). We certainly don’t expect any standards bodies to be going out of their way to help us out, and I’m guessing that every linux user that plays video games either owns a windows machine for that purpose, or a console. Linux gaming has been dead for much longer than OpenGL 3.