Will Vulkan effectively "replace" OpenGL or not?

Vulkan
41

[QUOTE=Alfonse Reinheart;31499]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.

I am reminded of Plato’s Allegory of the Cave.

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.[/QUOTE]

Unfortunately this is the situation in majority of software companies. Management dictates their priorities.

And yeah I know CG is not limited to CAD. But I’m focusing on CAD since it’s the driving force of OpenGL. Otherwise we would not have the compatibility-profile.

I don’t want Vulkan to fail, but I want to see it failing as early as possible if it’s going to fail.

42

[QUOTE=gloptus;31501]Unfortunately this is the situation in majority of software companies. Management dictates their priorities.

And yeah I know CG is not limited to CAD. But I’m focusing on CAD since it’s the driving force of OpenGL. Otherwise we would not have the compatibility-profile.

I don’t want Vulkan to fail, but I want to see it failing as early as possible if it’s going to fail.[/QUOTE]

Not all management acts equally some are actually willing to take the risk of putting a dev on a 3 month project.

and it’s very likely that it openGL on vulkan comes from some housewife’s basement-dweller doing it for a lark and then having the (incomplete) git repo forked by a game engine company trying to get the most out of their rendering pipeline and facilitating the move to vulkan by doing incremental changes to it.

43

[QUOTE=Alfonse Reinheart;31500]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.
[/QUOTE]

I’m sure if such initiative will come from the GL 1.2 users, hardware vendors will be glad to be of assisstance. Dropping a ton of legacy code cannot be a bad thing, unless some politics come into play. But then again, considering old APIs are (with an exception for more critical parts, maybe) emulated based on newer ones, probably with usage of more than one layer, I doubt driver teams are in that much trouble with its support.

44

Definitely not a general driving force, but a driving force in stopping development definitely (see Long Peaks). And let’s not forget that, next to the compatibility profile, there is the Core profile, which is much more relevant nowadays (new projects).

45

Regardless of how it affected the development of OpenGL, CAD applications are the major players.

46

That’s what? AutoCAD, Blender and Sketchup plus some proprietary applications? They can deal with 10 FPS trying to render a decently complicated model.

The game industry alone trumps that; nearly every mobile game uses openGL ES, many PC games use openGL especially those that are also for linux. These need fast lag-free graphics to keep their users. If they bog down to 10 FPS on minimal settings then you would just put it down and walk away. This means that they will want to support vulkan to avoid the driver overhead.

47

[QUOTE=ratchet freak;31506]That’s what? AutoCAD, Blender and Sketchup plus some proprietary applications? They can deal with 10 FPS trying to render a decently complicated model.

The game industry alone trumps that; nearly every mobile game uses openGL ES, many PC games use openGL especially those that are also for linux. These need fast lag-free graphics to keep their users. If they bog down to 10 FPS on minimal settings then you would just put it down and walk away. This means that they will want to support vulkan to avoid the driver overhead.[/QUOTE]

Yeah why not…wake me up when Vulkan SDK for Windows 7 is out for download. :wink:

48

If that’s true… why are most of OpenGL 3.0+'s features oriented away from compatibility mode? And I’m not talking about features that only could possibly work with shaders like UBOs and such.

Why doesn’t transform feedback work with the fixed-function T&L (NV_transform_feedback specified it, but not core/EXT)? Why don’t integer texture formats and array textures work with fixed-function processing? Why doesn’t the separation of vertex format from buffers work with client-side arrays?

There is no technical reason that these things could not be applied to the fixed-function pipeline in some way. Yet they aren’t. Why?

Because the ARB couldn’t be bothered.

Furthermore, you have talked about how OpenGL needs to go back to 1.2 and advance from there. If that’s a general sentiment among CAD developers… why hasn’t there been a single feature of post-3.0 OpenGL that adds to the capabilities of the fixed-function pipeline alone? Every new OpenGL feature is targeted towards modern, shader-based rendering. If it can be used with compatibility, fixed-function stuff, that’s seen as a bonus, not a primary feature.

The power to deny is easier to achieve than the power to grant. CAD developers may be powerful enough to deny a clean break, but they’re not powerful enough to force the ARB to give them actual features.

So saying that CAD developers are “the major players” or “the driving force” is wrong. They are only a force, and a force that has little more than the ability to throw a tantrum until others given them just enough to quiet them down.

And look at it now: CAD developers are basically locked out of the next phase of graphics API evolution. That’s what happens when you throw a tantrum to get what you want; people aren’t as willing to work with you next time around.

So whatever “major players” they used to be, they certainly aren’t anymore :wink:

I don’t see how that is in any way a response to his statement about the different market needs or the relative sizes of the two markets.

I understand that you’re skeptical about Vulkan’s potential for success. But your skepticism appears to be based solely on your dislike of Vulkan, not on any actual facts on the ground. The facts on the ground seem to indicate that Vulkan will ship and will have support from major ISVs.

Unless you believe that Valve and LunarG are going to implode in the next 8 months, your statement makes no sense.

Or, let’s put it another way. When Longs Peak was months from shipment, all we had were some PDF files talking about it. When Vulkan is months from shipment, we have actual ISVs and IHVs showing off actual demos running on actual Vulkan implementations.

To analogize the two scenarios is to deny reality.

49

[QUOTE=Alfonse Reinheart;31509]If that’s true… why are most of OpenGL 3.0+'s features oriented away from compatibility mode? And I’m not talking about features that only could possibly work with shaders like UBOs and such.

Why doesn’t transform feedback work with the fixed-function T&L (NV_transform_feedback specified it, but not core/EXT)? Why don’t integer texture formats and array textures work with fixed-function processing? Why doesn’t the separation of vertex format from buffers work with client-side arrays?

There is no technical reason that these things could not be applied to the fixed-function pipeline in some way. Yet they aren’t. Why?

Because the ARB couldn’t be bothered.

Furthermore, you have talked about how OpenGL needs to go back to 1.2 and advance from there. If that’s a general sentiment among CAD developers… why hasn’t there been a single feature of post-3.0 OpenGL that adds to the capabilities of the fixed-function pipeline alone? Every new OpenGL feature is targeted towards modern, shader-based rendering. If it can be used with compatibility, fixed-function stuff, that’s seen as a bonus, not a primary feature.

The power to deny is easier to achieve than the power to grant. CAD developers may be powerful enough to deny a clean break, but they’re not powerful enough to force the ARB to give them actual features.

So saying that CAD developers are “the major players” or “the driving force” is wrong. They are only a force, and a force that has little more than the ability to throw a tantrum until others given them just enough to quiet them down.

And look at it now: CAD developers are basically locked out of the next phase of graphics API evolution. That’s what happens when you throw a tantrum to get what you want; people aren’t as willing to work with you next time around.

So whatever “major players” they used to be, they certainly aren’t anymore :wink:

I don’t see how that is in any way a response to his statement about the different market needs or the relative sizes of the two markets.

I understand that you’re skeptical about Vulkan’s potential for success. But your skepticism appears to be based solely on your dislike of Vulkan, not on any actual facts on the ground. The facts on the ground seem to indicate that Vulkan will ship and will have support from major ISVs.

Unless you believe that Valve and LunarG are going to implode in the next 8 months, your statement makes no sense.

Or, let’s put it another way. When Longs Peak was months from shipment, all we had were some PDF files talking about it. When Vulkan is months from shipment, we have actual ISVs and IHVs showing off actual demos running on actual Vulkan implementations.

To analogize the two scenarios is to deny reality.[/QUOTE]

Honestly I just don’t like the name “Vulkan”. “Tsunami” is much better LOL