
Zink (OpenGL on Vulkan) performance better than expected - mfilion
http://www.supergoodcode.com/funday/
======
gw
It's things like this that make me not worry about sticking with opengl. It's
supported everywhere, fast enough for my uses, and is exactly the level of
abstraction i want to be at. I completed the vulkan triangle tutorial and i
cannot imagine needing all those knobs for the games and other things i make.
I'm pretty confident that by the time opengl is no longer natively supported,
software layers like this will be stable and fast enough.

~~~
skocznymroczny
I like OpenGL, but I really hate the global state. If only there was some
concept of state objects that record state, something like:

glBeginState(&stateObj); glEnable(GL_BLEND); glDepthTest(GL_LEQUAL);
glEndState(&stateObj);

and then later on you'd do glBindState(&stateObj) to apply it.

I have high hopes for WebGPU though and I am going to migrate my renderer to
it soon.

~~~
gw
Webgl doesn't have this problem since it runs those functions on a context
object. But yeah i wish there was a way to do that with opengl.

~~~
pcwalton
The problems of global state persist in WebGL, because (1) if you need to save
and restore state inside a single context, WebGL provides no help; (2) the
driver is unable to amortize validation as the state is not tied to the
individual render pass/pipeline descriptors.

~~~
gw
Interesting. When you say "save and restore state", do you mean actually
serializing it and loading it later? In what situation would you want to do
this? Not doubting that there is one but i haven't heard of this before.

~~~
pcwalton
Typically you use this feature to associate state with an object in your
render graph. For example, all of the render state used to render the sky,
including shader program, vertex buffers, textures, blend state, etc. can be
attached to the sky node in your scene graph. Then you can (basically) have a
generic "draw an object in your scene graph" function that just performs the
appropriate drawcall with the right state. The performance advantage of this
is that the driver can do all the validation once, when you construct the sky
object, instead of every frame.

------
entropicdrifter
I suspect that in a couple of years this driver will become incredibly useful
for low-end ARM boards. Manufacturers of cheap hardware will only need to get
an open source Vulkan driver mainlined and suddenly the machine will be able
to play virtually any game ever made because it will indirectly support OpenGL
and every version of DirectX. Likewise it'll give WebGPU/WebGL support thanks
to ANGLE.

~~~
est31
Isn't this the idea of Gallium3D (part of the MESA project)? You write one
driver and have support for Vulkan, OpenGL, etc.

~~~
david-gpu
In terms of achieving a certain level of functionality, you can do that, but
the additional abstraction you add into your software stack translates into
poorer performance and additional complexity. It's a trade-off.

Source: worked on GPU drivers for over a decade and had to make decisions like
that.

~~~
codetrotter
This may be a weird question and probably not your call but, since you work
for Nvidia and you mentioned having worked on GPU drivers I would be curious
to know something I have been wondering for a long while, namely 1) how come
the Nvidia drivers for FreeBSD don’t support CUDA, and more importantly 2)
what would it take for CUDA support in Nvidia drivers for FreeBSD to happen?

Apologies in advance if this is asking questions that you are not allowed to
comment on.

~~~
david-gpu
I've never worked on drivers at NVidia, so on the one hand I don't know the
answer, but I can speculate with an educated guess.

Porting, testing and providing ongoing support for an OS is very costly. If
there's not enough customer demand for it, it won't be done because it doesn't
make business sense.

------
surfmike
ANGLE (Chrome’s OpenGL ES backend) has a Vulcan backend as well, although I
haven’t seen any performance numbers. It’s made to run WebGL though so strong
incentive to have good performance.

[https://github.com/google/angle](https://github.com/google/angle)

~~~
johncolanduoni
It has a significant goal that tends to degrade performance: it needs to
disallow exposing undefined or unsafe behavior of the driver to the client,
regardless of how crazy the calls are.

------
DenseComet
I wonder if Zink can run on MoltenVK just for fun. OpenGL on Vulkan on Metal.

~~~
GranPC
That's more useful than just as a fun project - it would allow OpenGL apps to
continue to run on Mac when Apple decides to drop OpenGL support!

~~~
skavi
MoltenGL already exists.

~~~
simcop2387
MoltenGL is OpenGL ES 2.0 only, it'll probably work for a lot of applications
but not all of them because of that.

------
etaioinshrdlu
This is great news. I love old stable APIs :)

~~~
bitwize
Old stable APIs tend to get deprecated unless you're on Windows. Best to go
where developer support and energy is -- with the new.

------
ebg13
This headline feels extremely out of sync with the tone of the blog post.

> _My expectation when I clicked into the timediffs page was that zink would
> be massively slower in a huge number of tests, likely to a staggering degree
> in some cases._

> _We were_

So performance was better than expected on a small handful of tests out of
tens of thousands?

------
ngcc_hk
Nvidia CUDA need competition. Note what amd has done to intel. We need
competition. Market to work need competition.

Competition!

~~~
pjmlp
First acknowledge that C is outdated, support a polyglot environment for GPGPU
programming, including IDE and debuggers with ability to single step shaders,
conditional breakpoint and everything else that one has come to expect from
modern CPU programming.

Khronos did the first part with Khronos and SYSCL, but only after taking a
beating from CUDA, so the ecosystem never cared, and OpenCL 1.2 became 3.0.

Vulkan Compute is even worse than OpenCL in what concerns existing tooling.

------
birdyrooster
Zink like as in Zero-Ink?

