
Vulkan 1.2 - c89X
https://www.khronos.org/news/press/khronos-group-releases-vulkan-1.2
======
davedx
This blog series on Vulkan is apparently pretty good (written by an id
software engineer): [https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-
and...](https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-
you-part-1)

Talk by the same guy at GDC about porting Doom 3 to Vulkan and Stadia:
[https://stadia.dev/intl/en/blog/gdc-2019-session:first-
light...](https://stadia.dev/intl/en/blog/gdc-2019-session:first-light-
bringing-doom-to-stadia/)

------
bullen
I'm sticking with OpenGL (ES) 3 that brought VAO for life.

The returns will diminish to the point that porting or developing on new APIs
does not pay for itself.

I know both Jonathan Blow and Godot are clear signs that I'm wrong, but I
guess we'll just have to wait and see.

Until then I have my engine running on Win/x86 and the Pi 4 at good
performance with minimal effort.

Which is good; simple software will live forever.

~~~
skocznymroczny
I'm considering switching away from OpenGL just to get rid of the global
state. It's too tiring to track the OpenGL state just to realize you forgot to
unset some texture in a completely different part of code.

My favourite of the newest APIs is Metal, because it's very easy to jump from
OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an
alternative once desktop translation layer is created (Google is working on
one called Dawn).

~~~
earenndil
TBH, opengl has been improving in that respect. See, e.g.,
glTextureSubImage2D[1], which takes a pointer to the referred texture, unlike
glTexSubImage2D.

1: [https://www.khronos.org/registry/OpenGL-
Refpages/gl4/html/gl...](https://www.khronos.org/registry/OpenGL-
Refpages/gl4/html/glTexSubImage2D.xhtml)

~~~
skocznymroczny
Yes, I am aware of the direct state access extensions. It was a good step
forward, but a bit too late. And it still applies only to GL objects like
buffers, samplers, textures. For things like setting scissor test, blending,
depth test/write, color masks, binding textures, you're back to the global
state.

------
davemp
I really like how vulkan tries to model modern hardware--reminiscent of C. I
spent a few weekends writing a toy renderer with it and learned quite a bit
about the modern graphics pipeline.

Writing vulkan for a quick hobby project is probably a bit much, but it seemed
like a great choice where extra control is needed. Hopefully more libraries
will mature take care of the dirty work (thousands of lines of
initialization).

------
plopz
Is Vulkan the response to the fact that single cores aren't getting faster and
games need to move towards multithreading? Is there an analogous solution for
other systems like physics, collisions or pathfinding?

~~~
flohofwoe
The TL;DR reason for those new 3D APIs is essentially to drastically reduce
CPU work that needs to happen in the graphics driver layer in the "old" 3D
APIs (but that also means that if your application isn't spending a lot of CPU
time in the graphics driver, for instance because it is fillrate bound, then
that application won't benefit much from moving to the new APIs).

OpenGL's original design was a "fine grained state machine" which doesn't map
well to modern GPU architectures, and every time a "micro state" in that big
state machine is changed the GL driver needs to translate that change into
much coarser state that GPUs accept. But it turns out that many 3D application
don't even need to change unique states one by one, so each frame your code
translates mostly static and coarse "application rendering state" into GL's
fine grained state, only to have the GL driver translate that fine grained
state back into coarse GPU state.

That's just one piece of the puzzle but I think explains the motivation behind
the modern 3D APIs best.

The "other" 3D-API, Direct3D already took steps to group fine grained state
into coarser state (starting with D3D10 and D3D11), the problem there was that
they didn't come up with a good solution for threaded rendering (generating
rendering work on different CPU threads), that's the other big thing that the
modern 3D APIs solve properly. You essentially build render command lists on
multiple CPU threads, and then enqueue those command lists on the main thread
to be processed by the GPU.

------
boyadjian
Im am eager to have a usable implementation of OpenGL over Vulkan, like Zink.
At last, no more different implementations of OpenGL from one vendor to
another.

~~~
pjmlp
You just get different implementations of Vulkan from one vendor to another
plus the OpenGL middleware on top instead.

~~~
usrusr
Sure, but the vendor specific black box is getting much smaller. The idea is
that it's better to have client and/or middleware code paths battle actual
hardware differences than having them battle actual hardware differences _and_
different sets of smoke and mirrors.

------
boutad
Does Vulkan have an answer to DirectX Raytracing?

~~~
flohofwoe
NVIDIA offers a vendor-specific extension:

[https://www.khronos.org/registry/vulkan/specs/1.2-extensions...](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_NV_ray_tracing.html)

I guess this will first be elevated to a vendor-neutral extension and (I
guess) eventually will move into the core API.

~~~
thrower123
One would have thought that they might have learned from what happened with
OpenGL that this is a clusterfuck and leads to fragmentation...

~~~
pjmlp
Nah,
[https://vulkan.gpuinfo.org/listextensions.php](https://vulkan.gpuinfo.org/listextensions.php)

------
roenxi
In case anyone isn't keeping up this is basically the next generation of
OpenGl, but they've made enough changes to justify a new name.

Good idea too. Make it clear that they are doing things differently.

~~~
pjmlp
It is not a next generation OpenGL, unless one wants to become an expert in
driver and compiler development on top of mastering graphics programming.

Currently Khronos answer for those that don't want to become such experts it
to stick with OpenGL, the problem is that is isn't gettting much updates
beyond 4.6, and Vulkan is not getting a more developer friendly API.

Most devs will be better by choosing a middleware engine and just check the
respective box of the desired graphics API backend.

~~~
skocznymroczny
I think expert in driver and compiler development is too much. It takes a lot
more to get started, because it doesn't assume any defaults, but then it isn't
too hard as long as you venture into topics like multithreading, but then in
OpenGL you never went into multithreading in the first place.

I think the best middleground between OpenGL and middleware engines are
translation layers such as gfx-rs and bgfx, which offer a low-level but
userfriendly API and can compile to several different graphics API backends.

~~~
pjmlp
Experience has proven that if you aren't really deep into Vulkan, the end
result will be worse than just doing it in OpenGL, in terms of performance.

