PDA

View Full Version : Very long-term compatibility



paratras
03-22-2015, 05:51 AM
A very critical reason for my choice of whether to use Vulkan or not will be very long-term compatibility. I'm not jumping into a new API if it introduces a deprecation/removal model that doesn't guarantee backwards compatibility in the very long run. I've been a OpenGL developer since its introduction in the 90s. It has served me very well during these decades, because of both multiplatform compatibility and long-term compatibility.

If Vulkan defines a deprecation/removal model, don't count on me using it, because I really need that my source code lasts for decades. I'll choose another path in such case.

paratras
03-22-2015, 06:07 AM
Ooops, sorry, I thought this subforum was about Vulkan. Please feel free to move this to the proper subforum.

Alfonse Reinheart
03-22-2015, 07:03 AM
There isn't really a "proper subforum" for Vulkan here. Vulkan and OpenGL are separate entities, neither replaces the other. Yes, they're both rendering APIs, but they serve different sets of developers. Vulkan developers are those who want performance so badly that they'll be willing to effectively write a graphics driver for their application. OpenGL developers are those who want performance, but are willing to sacrifice some performance for easier development.

As such, OpenGL and Vulkan (https://www.khronos.org/message_boards/forumdisplay.php/114-Vulkan-High-Efficiency-GPU-Graphics-and-Compute) have separate forums. That's not to say that you can't talk about it here. But it's far less likely to be seen by the people who you want to see it.

As to your suggestion, if API stability is so important to you, then just wrap it up on your end. Vulkan is a graphics API with exactly one goal: providing maximum performance for GPUs. And if that means the API needs to change with GPUs, I hope that Khronos allows it to do so. If that puts a burden on developers who don't like changing their code, then you write a backend wrapper and you only change that when Vulkan changes.

Or better yet, stop using Vulkan directly and use one of the many middleware layers that will be written against it. I'm sure someone will give you the API stability you want.

Attitudes like yours are what killed Longs Peak; it's not helpful long-term., and hopefully with the large numbers of game developers backing Vulkan, they won't shy away from doing what needs to be done to keep Vulkan moving forward. And if it means that developers such as yourself are inconvenienced, that's a sacrifice I'd be willing to live with.

mhagain
03-22-2015, 08:00 AM
I've been a OpenGL developer since its introduction in the 90s. It has served me very well during these decades, because of both multiplatform compatibility and long-term compatibility.
And it can continue to serve you well for the next few decades if you wish. Here's a thing that people always seem to get confused about during this kind of evolution: this is not a zero-sum game. The fact that Vulkan exists doesn't mean that OpenGL is now going to cease to exist. Just keep your decades-old code, run it under OpenGL and as far as you're concerned Vulkan never even happened.

From the way you describe this, I'm going to guess that the bulk of your code is still at a GL 1.x feature level and that maximum compatibility is more important to you than maximum performance; you may even be willing to accept software fallbacks in exchange for compatibility. If that's the case then Vulkan is not for you. You are not part of the target audience, so you have absolutely no reason to want to port to it; just stick with OpenGL and your code will continue to work.


If Vulkan defines a deprecation/removal model, don't count on me using it, because I really need that my source code lasts for decades. I'll choose another path in such case.
It's not clear to me whether this is a practical requirement based on a program you ship and support, or if it's a theoretical requirement based on something you'd like to see happen but haven't actually sat down and thought about in detail.

If the former, see above: just continue using OpenGL.

If the latter, then I'd strongly suggest that you sit down and think about whether you actually really need to have the same source code last for decades unmodified before raising it as an objection.

Alfonse Reinheart
03-22-2015, 08:16 AM
And it can continue to serve you well for the next few decades if you wish. Here's a thing that people always seem to get confused about during this kind of evolution: this is not a zero-sum game. The fact that Vulkan exists doesn't mean that OpenGL is now going to cease to exist. Just keep your decades-old code, run it under OpenGL and as far as you're concerned Vulkan never even happened.

From the way you describe this, I'm going to guess that the bulk of your code is still at a GL 1.x feature level

Oh, no need to guess. This user's very first post (https://www.opengl.org/discussion_boards/showthread.php/165873-The-end-to-12-years-of-being-an-OGL-developer?p=1172789&viewfull=1#post1172789) was to say that he was leaving for Direct3D, all because OpenGL 3.0 had deprecated features with the intent to remove them in 3.1. Despite the fact that D3D constantly makes major, breaking changes to its API. So this isn't the first time he's done this.

I think his fear is that, at some point in the future, IHVs will just stop shipping OpenGL implementations for newer hardware. Even though that would break literally thousands of existing applications. And that nobody will have developed an open-source OpenGL implementation built on top of Vulkan, even though that would be a boon to those thousands of existing applications.

At which point, he will be forced to move to Vulkan, which may have significant API changes from version to version.

arekkusu
03-22-2015, 12:50 PM
Even though that would break literally thousands of existing applications.

s/thousands/millions (https://en.wikipedia.org/wiki/App_Store_(iOS)#Number_of_iOS_applications)/