Yes, it probably should stop, but two more points are relevant.

First one is the evidence being that the worst damage was done to OpenGL after Microsoft's departure. I'm talking about 2.0 and Longs Peak here. That's relevant because they represent the previous two times that the ARB had tried, and failed, to redesign a modernized OpenGL.

Second one is the story of ARB_occlusion_query. The story is here but in summary: it's odd that QUERY_COUNTER_BITS_ARB was allowed to be 0, and it turns out that the reason why was so that Intel could advertise support for the extension but without actually having to really support it. That's a classic example of the kind of madness that infected OpenGL's evolution (and note that Microsoft weren't involved here either) and it's exactly the kind of thing we'd like to see avoided in Vulkan.

I remain cautiously optimistic; it's quite notable that there is a significant number of game developers on the board this time around, rather than just hardware technicians, so the resulting API will at least stand a better chance of being something that matches well with what the people who are going to be using it actually want.

I've been thinking, maybe they'll expose OpenGL extensions to handle the SPIRV intermediate language...

Almost a certainty. I don't see OpenGL development stopping any time soon. NVIDIA has already announced extensions for command buffers in GL, for instance. SPIRV support is almost a certainty especially since OpenCL will now require it anyway.

Remember, Vulkan is going to be a huge pain in the ass compared to GL. The Vulkan API is _much_ cleaner, yes, but it also eschews all the hand-holding and conveniences of GL and forces you to manage all kinds of hardware state and resource migration manually. Vulkan does not _replace_ OpenGL; it simply provides yet another alternative.

The same is true in Microsoft land: D3D11.3 is being released alongside D3D12, bringing the new hardware features to the older API because the newer API is significantly more complicated to use due to the greatly thinner abstractions; it's expected that the average non-AAA developer will want to stick with the older, easier APIs.

Remember, Vulkan is going to be a huge pain in the ass compared to GL. The Vulkan API is _much_ cleaner, yes, but it also eschews all the hand-holding and conveniences of GL and forces you to manage all kinds of hardware state and resource migration manually. Vulkan does not _replace_ OpenGL; it simply provides yet another alternative.

The same is true in Microsoft land: D3D11.3 is being released alongside D3D12, bringing the new hardware features to the older API because the newer API is significantly more complicated to use due to the greatly thinner abstractions; it's expected that the average non-AAA developer will want to stick with the older, easier APIs.

THIS. A lot of people don't seem to get these are very low level APIs with a focus on raw memory manipulation and baking of objects/commands that are needed very frequently. You destroyed a texture while it was still in use? BAM! Graphics corruption (or worse, BSOD). You wrote to a constant buffer while it was still in use? Let the random jumping of objects begin! You manipulated the driver buffers and had an off-by-1 error? BAM! Crash or BSOD. Your shader has a loop and is reading the count from unitialized memory? BAM! TDR kicks in or system becomes highly unresponsive.
You need to change certain states more frequently than you thought? Too bad, turns out you need to make some architectural modifications to do what you want efficiently.

It's hard. But I love it, with great power comes great responsability. None of this is a show-stopper for people used to low level programming. But it is certainly not newbie friendly like D3D11 or GL were (if you considered those newbie friendly). Anyway, a lot of people learned hardcore programming back in the DOS days when it was a wild west. So may be this is a good thing.

Remember, Vulkan is going to be a huge pain in the ass compared to GL. The Vulkan API is _much_ cleaner, yes, but it also eschews all the hand-holding and conveniences of GL and forces you to manage all kinds of hardware state and resource migration manually. Vulkan does not _replace_ OpenGL; it simply provides yet another alternative.

I started my engine with OGL1.2 and being at OGL2.1 + extensions now,I have removed a lot of this convenience OGL over time. I'm currently at the state of handling many things by buffers and in the application itself and that with OGL2.1 (allocate buffer, manage double/triple buffering yourself, handling buffer sync yourself etc.). Most likely I use only a few % of the API at all. I think that a modern OGL architecture (AZDO, using buffers everywhere including UBOs etc) will be close to what you could expect from vulkan and that if they expose some vulkan features as extensions (command buffer), then switching over to vulkan will not be a pain in the ass.

THIS. A lot of people don't seem to get these are very low level APIs with a focus on raw memory manipulation and baking of objects/commands that are needed very frequently. You destroyed a texture while it was still in use?

Come on, time has changed. Current game engines uses multithreading and multithreading is one of the best ways to kill your game project, still people are able to code games And as game-dev you just can't take all the easy to use OS multithreading support features (mutex, critical sections, synchronise language features etc.).

For rookie coders there will be still comfortable libs around and for professional coders this should not be a problem (thought some headache might be included). On the other hand, the other modern APIs will not take this burden from the developers too.

THIS. A lot of people don't seem to get these are very low level APIs with a focus on raw memory manipulation and baking of objects/commands that are needed very frequently. You destroyed a texture while it was still in use?

Come on, time has changed. Current game engines uses multithreading and multithreading is one of the best ways to kill your game project, still people are able to code games

It's not really the same. Multithreading problems can be debugged and there's a lot of literature and tools to understand them.
It's much harder to debug a problem that locks up your entire system every time you try to analyze it.

I'm currently at the state of handling many things by buffers and in the application itself and that with OGL2.1 (allocate buffer, manage double/triple buffering yourself, handling buffer sync yourself etc.). Most likely I use only a few % of the API at all. I think that a modern OGL architecture (AZDO, using buffers everywhere including UBOs etc) will be close to what you could expect from vulkan and that if they expose some vulkan features as extensions (command buffer), then switching over to vulkan will not be a pain in the ass.

If you're already doing AZDO with explicit synchronization then you will find these new APIs pleasing indeed. However there are breaking changes like how textures are being loaded and bound. Since there's no hazard tracking, you can't issue a draw call that uses a texture until the it is actually in GPU memory. Drivers were also handling residency for you, but since now they don't, out of GPU errors can be much more common unless you write your own residency solution. Also how textures are bound is going to change.
Then, in the case of D3D12, there's PSOs, which fortunately you should be already emulating them for forward compatibility.

Indeed, professional developers won't have much problems; whatever annoyance they may have is obliterated by the happiness from the performance gains. I'm talking from a rookie perspective.

Hopefully Vulkan "drivers" won't exclude each other so that concurrently using gpus from multiple vendors is possible.

I even wonder how feasible it would be to use igpu (since they are common) for coarse depth rasterization for occlusion culling instead of course.


Hopefully Vulkan could also be used to write an opengl implementation on top of it. With such a standard implementation a lot of non conformity troubles would come to an end.

I'd be excited to see the possibilities of using an HSA chip (APU) for compute and leaving the dedicated GPU for graphics. Hopefully with AMD having a big stake in Vulkan and OpenCL 2.1 this will be possible.

Explicit multi-device capabilities should be a standard part of all these next-gen APIs. Allowing dev's to implement SLI/Crossfire style Alternate Frame Rendering, split frame rendering, or other kind of workload splits, such as moving shadows or post-processing to another GPU, with the developer in control of synchronization and cross-GPU data transfers.

It also opens up the ability for one device to be used for graphics and another purely for compute, with different latencies on each device.

If Vulkan doesn't support this, I'll be quite surprised.