Khronos Group wants to hear from graphics app developers!

Have you heard about the next generation OpenGL initiative? Khronos Group is designing a ground-up, cross-platform API to enable direct access to modern GPUs. We think this is a pretty big deal and we are seeking community input on the name for this new API. Please take a few minutes to take our survey. Your input along with that of others will help guide the naming of this significant initiative.More information can be found in this informational PDF.

That’s an interesting survey. I’m surprised that Khronos would be seriously considering ditching the “GL” part of the name in the new API.

I think it’s interesting to consider the equity that OpenGL has, on desktops and mobile.

On the desktop, it has had its ups and downs. While it’s the only game in town as far as Linux and MacOSX are concerned, Windows was, for a very long time, the only viable PC platform for games. And therefore was also a vital platform for game development tools (Maya, Max, etc).

In Windows land, the equity of the name “OpenGL” is… not the best. While D3D got off to a rocky start API wise, it has since gotten better, faster than OpenGL. And more importantly, it did so at a critical time for the industry, which put Windows OpenGL in a bad spot. Driver quality also did not help.

While those differences have essentially vanished in recent years, the echoes of those problems linger on. OpenGL, among professional Windows game developers, is just not the most reliable platform. D3D is the default; you use OpenGL when you have to (for cross-platform, some cool extension functionality that D3D doesn’t give you, etc). So as a name, OpenGL is not really an asset among primarily Windows developers.

In mobile land, where ES is pretty much the only game in town (good luck being a WinRT-only developer), the name has much greater equity. ES 1.1 was… crap, but it was functional crap. ES 2.0 wasn’t great; it still had many of the problems of OpenGL. But it was functional; it got the job done. And since it’s the only game in town, that’s good enough to give “OpenGL ES” solid branding. There are many new developers who started out with ES 2.0. And while they may not like it, they know it, and they’ve had positive experiences with it.

And that starts to spill into desktops. As more desktop applications get mobile ports, as more mobile apps get desktop ports, the two communities intersect. The name brand built up from OpenGL ES starts to improve upon people’s impression of desktop GL.

Overall, my main point is this: whatever the new name is, it needs to build upon the significant equity that “OpenGL” has among developers. Things like “Metal” and “Mantle” are starting from scratch. Oh, people want to use them, but they’re not name brands yet. OpenGL is.

Whatever the name for the next-gen API is, it needs to clearly say that it’s a sequel, not a completely new thing.

That being said, you can ditch the “Open” part. That’s long been a thorn in the side of the API, with new users constantly misinterpreting what it means. WebGL did, and I don’t think anyone misunderstands that it’s an OpenGL implementation for the web. Though the survey is probably more likely to find the truth on that point than myself.

Even though I have fond memories attached to the name ‘OpenGL’, I also would not mind a fresh new name if it helps drawing back those who left for D3D over the years.
Ultimately, I think anyone rejecting next gen GL because of the name, and not API quality or performance, would be a short sighted person Khronos shouldn’t care about.

It’s actually a completely-new thing with no similarities whatsoever, in order to squeeze-out all performance possible.
Also there’s the thing that good engines don’t cost $1,000,000 upfront anymore: Unreal, CryEngine and Unity are embarrassingly cheap now. A way to let them perform better is necessary. Most gamedevs don’t touch the API anyway - the engine wraps it in higher-level semantics. For gamedevs that don’t want the 3 engines, there are great news too - GL4.x/ES3.x will live on for decades, while the new API will cover both mobile and desktop (available on all modern devices and OSes) (porting becomes an OSAL+recompile). I think this all calls for a new name for the API.

I think this all calls for a new name for the API.

A new name that has zero brand recognition or equity. I’m sure that will easily be able to go up against the marketing muscle of Apple and Microsoft. :rolleyes:

It’s actually a completely-new thing with no similarities whatsoever, in order to squeeze-out all performance possible.

A “completely-new thing with no similarities whatsoever,” brought to you by the same people who made the old thing you’ve been using for years.

Let’s say that someone invented a better way to blow your nose than facial tissue. And this new way has no functional similarities to facial tissue. Do you honestly think that Kleenex’s version of this product would be called anything other than “Kleenex-brand Thingy”? Does ditching the literally decades of name brand recognition that they have sound like a good marketing decision to you?

You only discard brand recognition if that recognition is negative. You don’t see Microsoft ditching the “Direct3D” naming for 12?

Also there’s the thing that good engines don’t cost $1,000,000 upfront anymore: Unreal, CryEngine and Unity are embarrassingly cheap now. A way to let them perform better is necessary. Most gamedevs don’t touch the API anyway - the engine wraps it in higher-level semantics. For gamedevs that don’t want the 3 engines, there are great news too - GL4.x/ES3.x will live on for decades, while the new API will cover both mobile and desktop (available on all modern devices and OSes) (porting becomes an OSAL+recompile).

Interesting, but I fail to see how that’s relevant to anything anyone said. We’re talking about names, not functionality.

I meant that APIs or their names don’t matter too much, as it’s all hidden by the engines anyway. It’s only feature-levels that somewhat matter. The hardcore few, which won’t use those engines, don’t need marketing to tell them what to try.

I meant that APIs or their names don’t matter too much, as it’s all hidden by the engines anyway.

But they do matter. Because those engines are going to have to be written and maintained by people. And those people are going to have to make choices about which APIs to support and which ones to avoid.

Sure, they’re a lot less likely to make a decision based on the brand impact of a name. But they are still people and can thus still be influenced by marketing.

The decision of whether to support D3D12 or the new OpenGL or whatever on Windows is important. If all these engines ignore new GL on Windows, opting instead to support D3D12 there, then we have the exact problem we have now for desktop OpenGL. Namely, new GL implementations on Windows will not be thoroughly exercised. And therefore, bugs will frequently crop up. Which will result in fewer engines supporting them. Etc.

There are a lot more than 3 engines out there. While those get exercised a lot, there are a lot of internal engines out there too. Call of Duty runs on a proprietary engine. Valve has Source 2. Many other popular games do to. And each of them is going to have to upgrade to one or more of the command-buffer-based APIs.

That’s a lot of people who need to be convinced that new GL is viable. And one way to subtly help convince them is to use a name that has equity with them. Just like with any product.

If the new GL makes the right choices, we can prevent fragmentation. Marketing is a very important part of that. And marketing to all of those people is vital to making sure that they all pick new GL, instead of fragmenting the market with Metal on Apple, D3D12 on Windows, and new GL as a fallback elsewhere.

Or worse, just deciding that Metal and D3D12 provide enough coverage, and screw Android/Linux.

So yes, the name matters. The market is not as small as you would like to think.

I don’t understand this big fuss about the new name - I used to and I love the old “OpenGL”. There are even a 3rd party libraries grow around it mangling the name and API naming conventions like OpenAL (audio). But, well, IMO, the “XGL” should work - with X stand for cross-platform as the whole idea comparing to the competitor DirectX is that OpenGL is a Cross-platform Graphic Library.

From the other side, I don’t really understand what will happen to the old OpenGL? Is it the new competitor API growing or is it meant to be a replacement, so the OpenGL will not be supported anymore? If the 'New’GL is a replacement, why not to just make it “OpenGL5.0”, officially stating no backward-compatibility?

The thing that worries me most of all is not a new name but the changes. I love those weird long function names as far as they are so descriptive and clear to understand and remember. I would hate to see the collection of randomly-picked characters and trimmed words like in DX. From the other hand, the idea of DSA in 4.5 is definitely put OpenGL onto the right track it had to be from the very beginning: manipulating imaginary objects and states, which are so artificial in nature, with a multiple calls to different functions just to complete a simple easy task - that was a nonsense. I think the API should provide a task-oriented functions. F.e. the object creation: instead of giving the developer a set of name-allocating, binding and configuring functions it would be more logical to have a single function that creates object (f.e. texture): function with mandatory parameters (texture type, texel size, base dimensions, mipmap levels) and optional parameters (texel type, image data), therefore the object is allocated and ready-to use in a single call. And a set of functions for further tuning (reload image data, switch texel type to smg similar in size).

If the 'New’GL is a replacement, why not to just make it “OpenGL5.0”, officially stating no backward-compatibility?

The issue there is that OpenGL only ever once broke backwards-compatibility. And even that was not a full rewrite.

The name needs to make it clear that the new API is not merely “OpenGL, but with NV_command_buffer”. Or even “OpenGL with NV_command_buffer, but without all the bad stuff.” It needs to clearly say that it’s a new API.

Just as it needs to clearly needs to retain name equity with OpenGL.

From the other side, I don’t really understand what will happen to the old OpenGL? Is it the new competitor API growing or is it meant to be a replacement, so the OpenGL will not be supported anymore?

OpenGL is a specification, not an implementation. I rather doubt that the ARB will spend time updating it with new features as hardware evolves. NVIDIA, who has such a huge investment in OpenGL, will probably maintain a suite of OpenGL extensions for some time to come.

Implementations will live on for quite some time. Indeed, someone might open source an implementation of GL 4.5 on top of newGL, which would solve a number of problems.

Actually, the people working on those engines (and others with internal engines powering AAA games) actively shape NextGL. Not just providing immediate feedback, but also designing most of it. No marketing is necessary to lure them in :slight_smile: . Only OS vendors may need convincing, I guess. For Linux it will be easy, for desktop Windows - simply download drivers; mobile OSes may be tough.

Actually, the people working on those engines (and others with internal engines powering AAA games) actively shape NextGL.

Hmm. I just checked the PDF in the download link, and sure enough, you’re right. I knew that Blizzard/Activision were active in the ARB, as well as Transgaming. But I had no idea that Valve had jumped on board (though it makes sense, with their Linux push), let alone Epic and Unity.

Clearly they realize the very real potential headaches of market fragmentation and are actively moving to stop it. Kudos to them. Hopefully it won’t lead to a “too many chefs” problem.

Oddly, I don’t think I see Crytek on the list. I suppose that they probably figure that, with all of those guys involved, what they get will work out just fine.

Though, Pixar is the one I find most puzzling. What, are they hoping to port Renderman to newGL?

for desktop Windows - simply download drivers

I don’t know that it would be so simple. The Windows OpenGL ICD platform is reliant on OpenGL 1.1. You have to create a 1.1 context, then fetch function pointers, and then create the actual context you want. And while that could be functional, it’s still very messy.

Would it be possible for driver makers to bypass the ICD, or effectively create their own variation? Would we have to write specialized initialization code for each IHV? How would that interoperate with Win32 windows, or even WinRT? The reason the ICD has stuck around for so long is that the only alternative is to intrinsically know what the driver DLLs are named.

I have no idea what the solution to that would be.

mobile OSes may be tough

Well, WinRT is just not going to happen (though I would have sworn that hell would freeze over before Microsoft implemented WebGL in IE. And yet, here we are). But Android really has no other choice: Mantle is AMD-only, and AMD’s userspace in mobiles is vanishingly insignificant.

As for Apple… who knows. They could take a Microsoftian stand as with D3D, and there would really be nothing anyone could do about it. At the same time, Apple is actually on the ARB, and is part of the group working on the stuff. So it would make sense for them to support it.

Pixar is behind OpenSubDiv (opensubdiv.org). Part of the library is dedicated to hardware-accelerated adaptive subdivision. I suspect that’s the reason for their interest in next-gen graphics APIs.

EGL ? It already has the means to load various APIs and I guess vendors shipping EGL for their products will have to work on a common EGL ABI for Windows anyway.