
Introducing Zink: OpenGL on Vulkan - ingve
https://www.kusma.xyz/blog/2018/10/31/introducing-zink.html
======
robert_foss
I suspect that implementing OpenGL ontop of Vulkan is the way of the future.

~~~
thrower123
Hopefully if so, without any of the old legacy crap, if it is intended to be
actually used to write new code. If it is just a shim to let old OpenGL code
run on Vulkan drivers, which appears to be more the point, then I expect that
is unavoidable, as long as we do want to be able to keep running older
software down the line.

I do feel like there ought to be something for a higher level API that is not
a full game engine, is not laden with the historical missteps and anachronisms
of OpenGL, and doesn't require the masochism and verbosity of Vulkan. I rather
liked DirectX 9, especially with all the built-in convenience utilities in
D3DX that were later dropped.

~~~
Jasper_
Metal is very close to that "perfect layer" in my opinion. I would love to see
a portable Metal built on top of Vulkan, rather than the MoltenVK we're
getting (an insane idea, in my opinion). Perhaps the Dash/NXT thing that
Google is building would be an OK substitute?

~~~
pjmlp
Not by Khronos given the C++ usage on Metal, as they still keep being too C
focused.

~~~
Jasper_
? There's no C++ in Metal, it's Objective-C. You can build C or C++ bindings
for Metal if you want ( as has been done by
[https://github.com/recp/cmt](https://github.com/recp/cmt) ), the binding
language is not really a concern.

~~~
jcelerier
> There's no C++ in Metal, it's Objective-C.

... did you use Metal ? Metal shaders are written in ≈C++14. Says so right
here in the first example:
[https://developer.apple.com/documentation/metal/hello_triang...](https://developer.apple.com/documentation/metal/hello_triangle)

~~~
Jasper_
Oh, sure, the shader language. That part doesn't really matter to me, it all
gets compiled to some GPU-specific machine code in the end. Write it in GLSL,
HLSL, SPIR-V, C++, who cares really. And shader cross-compilers are already
_incredibly_ common in the industry (most write in HLSL, then translate with
HLSLParser, or glsl-optimizer, or spirv-cross, etc.).

When I talk about "good APIs", I'm mostly talking about the driver and CPU
side of things, since that's the common bottleneck we're looking to replace
with an OpenGL replacement. GPU compiler is already pretty highly optimized.

------
erlend_sh
gfx-rs is solving the same problem with a different approach.

[https://github.com/gfx-rs/portability](https://github.com/gfx-rs/portability)

~~~
earenndil
Isn't it solving a different problem? My understanding of gfx-rs is that it
implements vulkan on top of X, where X is direct3d, metal, opengl, or vulkan.
(It also implements a high-level graphics api in rust, but exposes a vulkan
implementation to c programs.)

------
Hamcha
Just when I thought we were finally getting rid of old-school OpenGL..

I guess it's probably good for legacy stuff though!

~~~
pjmlp
Not everyone is willing to jump into low level 3D APIs, the traditional
CAD/CAM vendors for example.

Many think that OpenGL with core context is already too low level.

Which the answer is in both cases to have some kind of middleware.

I always considered a mistake that OpenInventor was never part of the
standardization deal, because everyone ends up writing their own version of
scene graph APIs.

~~~
Jasper_
Farenheit, Inventor, VRML, every so often one comes out with "the scene graph
to rule them all". Turns out writing a high-performance renderer (and you do
want that) is quite challenging. There are so many different rendering
techniques and the scene graph is really not the hard part...

~~~
pjmlp
I do agree, the thing is 90% of the API users just want to render a mesh of
some sort and not write a high performance render engine able to sustain 90
FPS under all conditions.

