Vulkan 1.1 Released
khronos.org
khronos.org
And game devs don't care because they already have their own middleware.
You won't find much FOSS software on Nintendo, Playstation or Xbox, and for the respective middlewares porting to their respective 3d apis is cost of business.
Vulkan works only on desktop thanks to the same ICD model as OpenGL, which isn't currently supported on UWP.
Frankly, nobody cares about UWP and nobody cares about Microsoft mobile OSes. Their usage is lower than deskto BSD.
One day those Windows 7/8.x licenses will expire.
Yesterday's Windows Developer day was once again all about the store, IoT and new AI frameworks.
Surfaces and hybrid laptops are also mobile OSes in a certain way.
The licenses won't expire; the support will stop. UWP is not automatic successor, many apps are on Windows because of Win32 and that nobody wants to rewrite decades worth of code. Kill that and you kill Windows.
In Microsoft's plans perhaps. I don't know of a single person, offline or online, who uses UWP. I've seen some UWP apps benchmarked by magazines, that's about it.
I also have anecdote data from our customers doing UWP ports.
The PS 3 also had OpenGL ES 1.0 with Cg shaders as secondary API, no one cared.
Vulkan on the switch isn't a suboptimal implementation at all. It's the same Vulkan implementation provided by Nvidia (this is indicated by Ryan C. Gordon, who ported SDL2 to the switch, and subsequently ported the Vulkan and OpenGL support). That is a first class implementation, in regards to features and support, unlike OpenGL ES for the ps3. Plus, Vulkan as a low level api works best for abstracting performance, even more so with the features it has for abstracting perf out of mobile hardware like the switch has (such as for example, render subpasses).
https://stackoverflow.com/questions/43507536/how-to-connect-...
Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state. I don't have to remember what is stored where when I'm programming, I can follow the very fine spec as a pretty much step by step guide and get a working program. Practically every operation is simple, and only really cares about the arguments you pass it not some global state. This is very friendly to someone learning how it works.
It is raising the bar for implementing the "get a triangle onto the screen" part of the program, but that's not the hard part and never will be. It's also only raising that bar for crazy people like me who use Vulkan directly. In the future by the time Vulkan really takes over I expect it will lower the bar for that, since there will be nice libraries on top of it which deal with the "allocate everything" step for you (and maybe now, I don't know of any but I haven't searched... AMD has something I think).
I think you might be getting a false impression of Vulkan though. All the vertex shader, fragment shader, submit a buffer filled with geometry primitives, set depth clamping and filter triangles based on winding order, etc pipeline is still there, it's just much more explicit about how you are using it. There is also support for compute shaders that are more what I imagine OpenCL to be like. If you're doing traditional polygon rendering that's going to be slow. Even in my ray tracing project (that does most of the rendering in a compute shader), I imagine using OpenCL would have made it a bit of a pain to display the results realtime to the screen so people can actually play.
This is OpenGL specific, there isn't an hidden state on other 3D APIs.
There isn't this thing of binding/copying stuff into global state.
ID3D11DeviceContext::IASetVertexBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/ff4...
It's no different from manipulating the opengl context..
Also google bindless opengl
D3D11 contexts are explicit, real objects that you create, manipulate, and pass around. They can be properly and realistically handled in multi-threaded code. OpenGL contexts are opaque and global, and properly handling them in multiple threads is a nightmare. Multiple OpenGL contexts is also very different in functionality from multiple D3D11 device contexts.
Historically, it's been a slow process to move to a newer graphics API, because you need to wait for all the hardware venders to implement it. Building that high-level API in userland means that basic quality-of-life improvements don't have to wait for hardware vendors to write new drivers.
https://www.gamedev.net/forums/topic/666419-what-are-your-op...
In brief: current APIs are a leaky abstraction, and a disproportionate amount of time is spent in debugging the curious "competition" between applications/libraries and drivers, at least, for relatively complex applications.
Vulkan offers superior performance potential & avoids concurrency issues in GL. It achieves this by more closely matching its abstraction to GPUs as they are today. It also allows for simpler drivers, which should hopefully make for more consistent results
It has a much higher barrier to entry and will likely stay that way. What will presumably happen is that higher level APIs will emerge that abstract that complexity away.
The clear advantage over OpenGL is that those abstractions are debuggable and vendor-independent.
Vulkan is a much better designed API with a lot less legacy crap in it. It's lower level and gives more control to the app/engine developer.
The bad news is that Vulkan is a bit verbose, but this stops being an issue once you move past "hello world" level apps. OpenGL gets really difficult once you start doing complex things.
There still seems to be a lot of fragmentation from the handful of samples I've looked at so far; is there something like a canonical example of "the right way" to do things?
https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instanc...
In the link you provided, it only needs to enable the appropriate window system extension. It also prints out some info about other extensions but that is not required.
It's a huge improvement that extensions need to be explicitly requested at init time.
It's massively better than OpenGL, and API extensions can't be completely avoided in a multi-vendor cross-platform API without limiting to lowest common denominator.
Specially given the amount of extensions that have been added since Vulkan was released.
The lower level API also allows you to do things that OpenGL simply wouldn't allow, like driving multiple GPUs for one display output using your own abstractions.
DirectX12 is much in the same spirit (but not equivalent, they're still a lot different internally).
Vulkan will also (probably) bring better crossplatform support from Games since it's equally supported on Windows, Linux, Mac (with a library), Android and the Game Consoles. (There is OpenGL on Android but IIRC it's not quite the same)
A lot of Of constraining and not very valuable parts of OpenGL were replaced with do-it-yourself, making the API "retreat" from advanced complex solutions to more general and more portable building blocks.