[QUOTE=Alfonse Reinheart;31476]Never say “My final words” unless you’re willing to let them be final. Otherwise, you’re just pretending to storm out of a room in a huff, to distract from the conversation at hand.
Ahem: “You are full of it. And you are the troll of the OpenGL forums as some one said.”
I fail to see how that could be anything other than personal. Since it was clearly addressed at me. Personally.
The whole “middle finger” thing wasn’t insulting; it was more confusing. Because you clearly confused my position of “I find that your argument that OpenGL will outlive Vulkan makes absolutely no sense and is based on an overly narrow view of reality” with “I think OpenGL will be dead in 2 years”.
Arguing against your argument doesn’t mean I’m arguing for the exact opposite. OpenGL will be around for a while yet.
But not for the reasons you claim.
Well, yes. False information should be corrected, so as not to mislead others into thinking that it’s true. False or malformed reasoning should be demonstrated as being such, so as not to persuade others.
I only object to things that I find don’t make sense or contradict established reality.
I did listen. As evidence for that, I responded to most of your facts.
By refuting them. Thus proving that what you provided were not facts at all.
The reason my posts are so long is that I back up my opinions with facts and reasoning. This allows people the freedom to evaluate my facts and reasoning themselves, to decide if my opinion is reasonable.
Yes there is. What you seem to consistently misunderstand is how large that industry really is. And the relative importance of the various participants within it.[/QUOTE]
Oh man you are professional at it. The industry is very large that OpenGL compatibility profile is still there.
I forgot to reply to a (to me) very important part of the thread
[QUOTE=Alfonse Reinheart;31464]You have an over-developed sense of OpenGL’s importance. Sooner or later, OpenGL is going to effectively die. The best-case scenario for you is that, after 7-10 years, IHVs will sponsor an open-source project that implements OpenGL in terms of Vulkan or D3D12 or whatever. And after extensive testing, they replace their OpenGL implementations with that.
And thus, the IHVs will wash their hands of it. Oh, people can still use it if they want. And for old applications that aren’t being supported, or developers of applications who don’t feel like actually developing their applications, they’ll have to use that.
OpenGL will simply be a mid-level rendering system built on an existing API.
[…]I expect Vulkan vs. OpenGL to work the same way. They’ll compete, but as more code gets written, Vulkan and similar APIs will be what new code gets written to. A few old stalwarts will keep going with OpenGL, and the OpenGL specification itself will keep pace with new hardware. But overall, the number of direct users of the API will become decidedly insignificant.[/QUOTE]
Now first of all, as also stated by others before, I think the process of OpenGL becoming used very little in new projects wont be an immediate one, but a very slow one that will probably take years. Just as it took years for the immediate mode to vanish. After all even that still lurks around today in some tutorials on the web, as well as some resources used to teach people graphics programming at university.
The part I wanna talk about is this is: “an open-source project that implements OpenGL in terms of Vulkan or D3D12 or whatever”
I wonder if there is any effort planned or any interest out there in making a high-level API based on Vulkan, but instead for OpenGL, for offering an easy-to-use yet not restrictive high-level (object-oriented, e.g. buffer objects and textures) C++ based API on top. Something that will wrap common functionality that programmers would likely wrap in their own program anyways - unless of couse they are the spaghetti- and, unreadable-code-writing type of programmers, ugh!. I am not talking about something like Ogre, but really just a collection of utility functions that won’t take away your responsibilities regarding scene management, memory, the parallel computing issues etc. Instead it should just ease usage and offer an OO approach for meshes, FBOs, textures, specifically and only for Vulkan, which would also make it easier to keep track of the creation and deletion of these.
[QUOTE=Ident_;31479]I forgot to reply to a (to me) very important part of the thread
Now first of all, as also stated by others before, I think the process of OpenGL becoming used very little in new projects wont be an immediate one, but a very slow one that will probably take years. Just as it took years for the immediate mode to vanish. After all even that still lurks around today in some tutorials on the web, as well as some resources used to teach people graphics programming at university.
The part I wanna talk about is this is: “an open-source project that implements OpenGL in terms of Vulkan or D3D12 or whatever”
I wonder if there is any effort planned or any interest out there in making a high-level API based on Vulkan, but instead for OpenGL, for offering an easy-to-use yet not restrictive high-level (object-oriented, e.g. buffer objects and textures) C++ based API on top. Something that will wrap common functionality that programmers would likely wrap in their own program anyways - unless of couse they are the spaghetti- and, unreadable-code-writing type of programmers, ugh!. I am not talking about something like Ogre, but really just a collection of utility functions that won’t take away your responsibilities regarding scene management, memory, the parallel computing issues etc. Instead it should just ease usage and offer an OO approach for meshes, FBOs, textures, specifically and only for Vulkan, which would also make it easier to keep track of the creation and deletion of these.[/QUOTE]
I can sense the fear of complexity in using Vulkan :D, and the specification has not been out yet.
Graphics applications usually has a thin graphics abstraction layer on top of whatever API they intend to use. So for example if they are using OpenGL today, they can later write a driver to support D3D, or even software rendering, without touching the application code. It’s implemented like a plugin.
The point is, if I’m going to use another wrapper on top of Vulkan, and I already have my own wrapper (layer), the overhead might be negligible but I would consider directly using Vulkan, otherwise what’s the point.
There is no fear in my post, I just consider this useful and would like to participate. I already participate in another Open Source project. Starting with something like this early on is a good idea. Something like the suggested wrapper is equally useful for OpenGL, btw., since one should only program on the lowest level necessary, in my opinion.
To make life easier on IHVs, then they only need to support 1 API and let the (open source) openGL layer deal with all the implicit work that openGL drivers have to do now.
This layer could then also be optimized per application using them like the openGL drivers are doing now.
[QUOTE=Ident_;31479]The part I wanna talk about is this is: “an open-source project that implements OpenGL in terms of Vulkan or D3D12 or whatever”
I wonder if there is any effort planned or any interest out there in making a high-level API based on Vulkan, but instead for OpenGL, for offering an easy-to-use yet not restrictive high-level (object-oriented, e.g. buffer objects and textures) C++ based API on top.[/quote]
Given my feelings about how easy Vulkan was to learn, I lamented the possibility of lacking a solid, low-level API that could bridge the gap between beginning graphics programmers and Vulkan. As I thought about it, I considered the possibility of a “miniGL 4.6”.
If you recall way back in the early days of OpenGL on Windows, it was popular to write pseudo-implementations of OpenGL that implemented just enough of the API to get certain games (ie: QuakeGL) working on a particular graphics card (ie: 3Dfx). An application could be written against miniGL, yet could run on an actual OpenGL implementation too, since miniGL drivers only removed things, rather than adding them.
My initial idea was an extension of this concept, relative to modern OpenGL. The core profile of OpenGL 4.5 is pretty nice, but it has a lot of redundencies. ARB_DSA lets you modify objects without binding them, but you still could. ARB_vertex_attrib_binding lets you separate vertex formats from buffer objects, but the old way still works. ARB_texture_storage lets you allocate immutable textures with a full mipmap pyramid in one call, but you can still use the old, horrific method.
Therefore, a miniGL 4.6 (assuming SPIR-V support in GL 4.6) would effectively ditch all of these redundancies. If you bind an object, that means you intend to render with it. And so forth.
What I realized as I did this was that this API came very close in function (if not form) to OpenGL Longs Peak. If you recall even more obscure history, around 2007, the ARB attempted to rewrite the entire OpenGL API. They gave the first version of this API the codename “Longs Peak”. They published 4 ARB pipeline PDF papers that talked about it in some detail (sadly, they’re no longer available online. I still have my saved copies, but I don’t know the legalities of making them available), so we had a pretty clear picture of what it would look like.
And function names aside, it was more or less GL 4.5 minus the cruft (and obviously without the hardware features added since then).
So I was toying with the idea of doing a kind of homage API to Longs Peak as a wrapper around Vulkan. I don’t like that idea for one reason: who would use it?
MiniGL 4.6 has one great advantage: it’s backwards compatible with ActualGL 4.6. So learning miniGL 4.6 did indeed teach you a useful skill. Whereas learning Longs Peak teaches you how to use an API that only people learning graphics programming use.
And it’s highly unlikely that a couple of people on the Internet will be able to optimize a low-level API wrapper around Vulkan to the degree that modern IHVs can. So simply by using it, you potentially lose performance. But, if you wrote to miniGL 4.6, you could just switch to using ActualGL 4.6 and get that performance back. That wouldn’t be the case for a Vulkan-based Longs Peak.
Your suggestion would essentially have the same problem: who’s going to use it?
The thing is, there’s no way to plan what that would look like without actually seeing Vulkan.
Take uploading to memory as an example. Let’s say you plan to have a wrapper function for that. But what if uploading data to memory is not that complicated, requiring merely 3-4 function calls with no special logic? What good is downloading a wrapper library for something that would take a programer 30 seconds to write?
And that assumes that everyone will do memory uploading the same way. Different users may have different needs, and it’s unclear what those needs would look like without being able to see the API.
I’m not formally against the idea. I’m just saying that it’s too early to make any substantive plans for it beyond being willing to manage such a project.
Also, given the structure of Mantle’s API, it’s not clear how useful that would be. With OpenGL, you have to set each individual piece of the state for many objects. That involves a lot of glSamplerParameter/glTextureParameter calls, so a few wrapper utility functions would be good. In Mantle and Vulkan, you build a datastructure and pass it to a construction function.
So without really seeing the API, it’s not even clear if such wrappers would be appropriate for it.
There are many points. But for me, the big reason is stability.
Right now, OpenGL implementations are very buggy. But each different implementation has its own unique set of bugs. Equally importantly, OpenGL implementations are not part of your application, so you can’t fix any bugs in them. The best you can do is work around them. You also cannot effectively test every implementation that exists. Nor can you prevent new bugs from being introduced tomorrow that break your application.
A Vulkan implementation of OpenGL fixes these problems. On the surface, it may seem to trade one problem for another. But because the implementation is open-source… it’s effectively part of your project. You decide which version of GL-On-Vulkan to ship with. You decide when it gets updated. You only need to test your program against one implementation, not a half-dozen. And most importantly of all, if there’s a bug in the implementation, it’s open source; it is now possible for you to fix it.
The biggest downside is performance, which will likely take a hit compared to what you could achieve with a vendor-provided GL.
[QUOTE=ratchet freak;31483]To make life easier on IHVs, then they only need to support 1 API and let the (open source) openGL layer deal with all the implicit work that openGL drivers have to do now.
This layer could then also be optimized per application using them like the openGL drivers are doing now.[/QUOTE]
And who’s going to implement Vulkan? The same IHV providing the layered OpenGL implementation, I guess. In this case it was the fault of IHVs not to properly structure and engineer the OpenGL driver implementation. Oh wait…but there’s the stable Direct3D, why did not they have Direct3D-based implementation of OpenGL???
There is a D3D-based implementation of OpenGL (ES). ANGLE is not some minor project; it’s development was vital in getting WebGL implemented in Windows-based browsers.
Indeed, the whole project was effectively a Google-based repudiation of the state of OpenGL implementations on Windows. When attempting to make WebGL work in Chrome, Google discovered that they would get more stable results by funding and incorporating some guys’ nascent OpenGL-on-Direct3D project than by using actual OpenGL drivers.
ANGLE is not something that PC graphics professionals should be ignorant of. It’s something that people who are paying attention to the OpenGL landscape ought to know about. ANGLE is important.
Yet you are somehow unaware of this significant development in OpenGL land.
As for the rest, it is clear that, when Ratchet said that the OpenGL implementation(s) would be “open source”, he meant that they wouldn’t be shipped with the IHV’s drivers. That’s why he said “[IHVs] only need to support 1 API”; because support for OpenGL would be provided by someone else.
Much like Vulkan’s SDK is not being developed by any particular IHV; it’s coming from LunarG, along with a bunch of development tools. OpenGL-on-Vulkan would be like ANGLE; a library you download and link into your application, rather than a conventional IHV implementation.
In the future, please stop making statements that are demonstrably wrong. If you’re going to post, please fact check first.
You are full of it. And you are the troll of the OpenGL forums as some one said. You always try to argue and manipulate facts with maybe “nice” sentences but they are far away from reality.
Direct3D will die. No Direct3D 12. “Vulkan” will never see the light.
OpenGL will role as the industry leading standard of accelerated graphics for the next 100s years or until computer graphics die.
Finally,
Here’s the middle finger to everyone betting on OpenGL death![/QUOTE]
OldGL will most likely wither and die over the coming decade. But I’m not a gambling man so I’m not betting on it!
D3D will tank at the same rate as windows and microsoft! Slowly but surely.
Are you implying Windows and Microsoft will cease to exist? The Linux market share of 1% that hasn’t changed significantly over the past decade surely is not indicating this ( I am not defending Windows, just pointing out that your statement lacks any foundation)
Also if Vulkan will become the API of choice for most users, it is more likely that in the future Microsoft Windows will rely on Vulkan and slowly neglect D3D, rather than Windows/Microsoft dying itself. Microsoft only recently joined the Khronos consortium again, lets not forget about that. And OpenGL already dominates browsers (webGL - Microsoft’s solution fell flat), as well as almost all mobile devices and tablets with OpenGL ES. IE 11 offers webGL and I think it is just a question of time until Windows phones will move on to another graphics API (be it vulkan or whatever else) since they stand pretty much alone with their D3D9 support.
Thats was quite off-topic.
So did I understand correctly that there is actually official support for an Open Source OpenGL-like library based on Vulkan planned? Or was all that talk hypothetical?
There is a D3D-based implementation of OpenGL (ES). ANGLE is not some minor project; it’s development was vital in getting WebGL implemented in Windows-based browsers.
Indeed, the whole project was effectively a Google-based repudiation of the state of OpenGL implementations on Windows. When attempting to make WebGL work in Chrome, Google discovered that they would get more stable results by funding and incorporating some guys’ nascent OpenGL-on-Direct3D project than by using actual OpenGL drivers.
ANGLE is not something that PC graphics professionals should be ignorant of. It’s something that people who are paying attention to the OpenGL landscape ought to know about. ANGLE is important.
Yet you are somehow unaware of this significant development in OpenGL land.
As for the rest, it is clear that, when Ratchet said that the OpenGL implementation(s) would be “open source”, he meant that they wouldn’t be shipped with the IHV’s drivers. That’s why he said “[IHVs] only need to support 1 API”; because support for OpenGL would be provided by someone else.
Much like Vulkan’s SDK is not being developed by any particular IHV; it’s coming from LunarG, along with a bunch of development tools. OpenGL-on-Vulkan would be like ANGLE; a library you download and link into your application, rather than a conventional IHV implementation.
In the future, please stop making statements that are demonstrably wrong. If you’re going to post, please fact check first.[/QUOTE]
My advice to you, go find yourself in writing fictions, I’m sure you will do much better job. You write lengthy replies that are simply WRONG.
Your goal is to object any idea that comes from others by twisting facts.
Question. Have you ever been involved in writing a CAD software in your life?
[QUOTE=gloptus;31494]My advice to you, go find yourself in writing fictions, I’m sure you will do much better job. You write lengthy replies that are simply WRONG.
Your goal is to object any idea that comes from others by twisting facts.
Question. Have you ever been involved in writing a CAD software in your life?[/QUOTE]
In that impossible case IHVs will drop OpenGL at some point, CAD developers have two options.
a) Use Vulkan-based software implementation in newer releases, as mentioned above.
b) Create a driver of virtual GPU that will support legacy API as long as needed. This one is beautiful, I think, since it allows to run software as ancient as OS is able to run without recompilation. And if it will become open-sourced, the driver will spread everywhere on its own, because this is how open source works.
In collaboration, few major developers can realise either of options without breaking a sweat: this is old GL, a 5-man team will handle it in a few months. Linear algebra is nothing in comparison with sophisticated equations and other stuff modern CADs need to deal with.
Now, please, finally tell us why neither of options will do for the reasons other than laziness.
[QUOTE=Salabar;31495]In that impossible case IHVs will drop OpenGL at some point, CAD developers have two options.
a) Use Vulkan-based software implementation in newer releases, as mentioned above.
b) Create a driver of virtual GPU that will support legacy API as long as needed. This one is beautiful, I think, since it allows to run software as ancient as OS is able to run without recompilation. And if it will become open-sourced, the driver will spread everywhere on its own, because this is how open source works.
In collaboration, few major developers can realise either of options without breaking a sweat: this is old GL, a 5-man team will handle it in a few months. Linear algebra is nothing in comparison with sophisticated equations and other stuff modern CADs need to deal with.
Now, please, finally tell us why neither of options will do for the reasons other than laziness.[/QUOTE]
It’s not the development team decision you know, it’s a management’s. Developers will do whatever they are told to do as long as they get their pay cheques.
Now why the management may not consider those options is a business related matter…and depending on their priorities and available resources.
[QUOTE=gloptus;31496]It’s not the development team decision you know, it’s a management’s. Developers will do whatever they are told to do as long as they get their pay cheques.
Now why the management may not consider those options is a business related matter…and depending on their priorities and available resources.
It’s all about BUSINESS. ;)[/QUOTE]
Well, it is your job to explain the management how being in control over instruments you use is healthy for your product. Relatively small investments will ensure that your clients will be able to continue the work in case whatever happens in a new driver revision. You may even propose my virtual GPU thingie and become a guy who saved the day yourself.
I think it’s more of a reflection of the growing weakness in the market for PCs in general. Increasingly large numbers of people are relying on smartphones, tablets, and other similar devices for their computing needs. Devices like “streaming sticks” (ChromeCast) cover the bases for a lot of users.
And Windows is not nearly as much of a part of that ecosystem. Oh, it’s certainly there. But there are a lot of viable alternatives that offer just as much value.
Also, Linux powers Android. And they’re far bigger than “1%” of the market.
It’s entirely hypothetical.
Oh, I’m absolutely convinced that it will happen; indeed, I’d bet that the ANGLE guys would cover it sooner or later (though they may use D3D12 as their backend rather than Vulkan). But Khronos themselves have certainly not announced any plans for one, nor has anyone else.
[QUOTE=gloptus;31494]My advice to you, go find yourself in writing fictions, I’m sure you will do much better job. You write lengthy replies that are simply WRONG.
Your goal is to object any idea that comes from others by twisting facts.[/quote]
Revealing “facts” to not be facts is not “twisting facts”. Because they weren’t “facts” in the first place.
CAD is not the whole world of computer graphics. And if you think it is, then your perception of reality is woefully limited. Computer graphics is a big world; you should visit more of it sometime.
[QUOTE=gloptus;31496]It’s not the development team decision you know, it’s a management’s. Developers will do whatever they are told to do as long as they get their pay cheques.
Now why the management may not consider those options is a business related matter…and depending on their priorities and available resources.
It’s all about BUSINESS. ;)[/QUOTE]
That sounds like a crappy position to be in, where entrenched management refuses to recognize reality and allow you to do the things you know you need to in order to keep your software relevant going forward. This has happened in numerous industries, particularly in more recent years, with industries fighting to survive against disruptive changes to the market.
But your situation does not give you the right to hold the rest of the world back from moving forward. Nor is your situation sufficient to justify a belief that the direction everyone else thinks is forward is wrong.
I understand that you believe Vulkan will fail. I understand that you want Vulkan to fail. I understand that, from a professional perspective, you need Vulkan to fail. It represents a threat to the continuation of desktop OpenGL, and therefore is a threat to your projects and your way of life. I sincerely feel for the predicament you are in through no fault of your own.
But that doesn’t make your blind opposition to Vulkan in any factual sense correct.
Don’t underestimate the task of implementing a fully-conformant GL 1.2 implementation. With all of the state tracking and so forth it has to do, an old GL implementation has to do a very great deal of book keeping work. And if you get any of it wrong, that quickly becomes a problem. Which means you’d need a serious conformance test, and none really exists for old GL stuff.
Old GL is really complicated. Not so much the underlying algorithms, but fitting it into modern graphics hardware.
That’s one of the reasons, when I was considering a potential miniGL, that I only looked at modern, core OpenGL 4.5. Compatibility would mean a huge amount of implementation pain.
That’s not to say that CAD developers couldn’t put one together. It’s just that it would require more effort than you think.
