Zink (OpenGL on Vulkan) performance better than expected
supergoodcode.com
supergoodcode.com
Hell, even though Khronos tried to do exactly that with the core/compatibility schism, pretty much all existing implementations decided breaking people's code is a stupid move and mostly ignored it (Apple being an exception but Apple hates developers[0] and their OpenGL implementation was always awful - even then, Apple's implementation is still an implementation of a stable API).
In practice it means that your currently working code will remain working in the future and there are good chances that you'll be able to port it in other places with either official or unofficial implementations.
[0] OK, OK, i know, Apple doesn't "hate" developers, they just do not care about them at all and they'd happily break things like a hippo dancing in a glassware shop if they believe that would make their own developers feel better.
Ah yes, D3D, well known for its broad cross platform support! In all seriousness, would a Linux D3D driver even be legal? I have to assume that major legal or technical barriers exist, otherwise why wouldn't a GPU vendor have developed one at some point?
But these days that's mostly superseded by DXVK (which implements D3D9 through 11 over Vulkan, kind of like Zink in the OP) and VKD3D (D3D12 over Vulkan).
If anything the graphics API war is still going on.
And even there one can choose GL 4.5 and NVN as well.
Most native titles end up going with NVN.
That is, in fact, precisely the wrong advice.
Vulkan runs on Windows, Linux, and OS X (via MoltenVk). Nothing else does.
OS X runs OpenGL 3.Ancient and has now dropped OpenGL. OpenGL drivers for Linux tend to be laughably worse than the Vulkan drivers.
All of the major gaming companies have basically said "We have no OpenGL jobs. We have a ton of unfilled Vulkan jobs."
If you aren't using DirectWhatever, Vulkan is going to be the only useful 3D API very shortly.
Note that most of the newer OpenGL features are largely about sending stuff faster to the GPU, not enabling new GPU features - you can do a lot of stuff with OpenGL 4.1. IMO if you are struggling for CPU performance with OpenGL then you might be better moving to Vulkan. But if this isn't your bottleneck then there isn't a reason to not stick with OpenGL.
If OpenGL drivers on Linux are "laughably worse" (though in practice i haven't much of a difference) then the solution is to improve those drivers. It'll be better for all the thousands of existing applications too.
You are correct. I misspoke. I meant to say 4.Ancient since 4.1 is 10 years old now.
> Note that most of the newer OpenGL features are largely about sending stuff faster to the GPU, not enabling new GPU features
For shaders, I certainly find that not true. There are a lot of shader features that got added over 10 years.
And, I believe things even as important as Uniform Buffer Objects are later than 4.1.
OpenGL 4.1 just ... isn't good in this day and age.
> If OpenGL drivers on Linux are "laughably worse" (though in practice i haven't much of a difference) then the solution is to improve those drivers.
I totally disagree. There simply aren't enough people in the Linux ecosystem to maintain those drivers and Vulkan drivers. I'd rather those developers all work on the newer and better API.
ICD OpenGL drivers are also not supported on Windows ARM variants.
Microsoft is driving the effort of OpenGL and related technology on top of DirectX instead.
https://devblogs.microsoft.com/directx/in-the-works-opencl-a...
Also so far there is no Vulkan on PlayStation, and while Switch does support Vulkan/OpenGL 4.5, most titles are either using middleware like Unity (ca 50% of Switch titles) or NVN.
Khronos is now driving the Anari effort, because most visualization toolkits could not be bothered to move forward into Vulkan.
Pity that they decided to just bother with C99 though.
Isn't this the trend nowadays? I've seen recently that simple languages are trending again, languages like C, Go, Zig, Erlang, Lua. I think we hit the ceiling with mammoths like C++ and Scala.
Then everyone can generate whatever bindings they feel like in an automated way.
Generics are cool, but auxiliary to any core part of the api since it's not really possible to use them outside of in a macro that wraps over a real function.
(Also where would the API itself have benefited in any significant way from the use of atomics or generics? Recall that compiler support for atomics is optional in C11.)
And they aren't the only ones, try to see how much of Apple or Google OS applications you manage to write with C11 alone.
There is no public plan to add to Visual C++ anything more than what ISO C++ requires in terms of C source code and libraries compatibility.
Microsoft has contributed to clang on Windows for those that still want to use C.
I get it, Vulkan is low level, but still.
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.
In a way I find OpenGL too complicated sometimes, some of its abstractions don't really make a whole lot of sense on modern hardware. Having a lower level API can make some code simpler to write, at least in theory. When I use OpenGL I often find myself thinking "I sure hope the driver will manage to understand what I'm trying to do and not end up doing something silly".
Note that my exposure to OpenGL comes mainly from console emulators though, and that's obviously very biased since emulators need to mimic very quirky behaviors of the original hardware, and that often results and very un-idiomatic GL code.
These things are obviously related.
From my work in OO langs, I believe it is possible to wrap OO code in functional code to some degree without rewriting, assuming that global references can be intercepted and resolved to local ones somehow, and that the state reference that encompasses all the globals is an immutable data struct
These days I rarely ever bother with threaded OpenGL, and I stick to one context per thread, using OS surface sharing primitives (DXGI, IOSurface, etc.) to communicate.
In 4.x they added DSA[1], which lets you avoid the global state a lot of the time. There's still some, but much less.
I do agree, though, that opengl is somewhat a mess, and vulkan really overwhelming.
If you use it, then you'll get no help from the platform on getting it to run. Random parts may begin to break, and the intention is likely an eventual removal.
Vulkan lets dev do things directly.
You could say opengl is one "layer of crap" Carmack was talking about.
I'm still happy to use it though.
Use the bgfx.
Could you expand a bit on this? Are you referring to DXVK? Or does Zink have support for DirectX?
Source: worked on GPU drivers for over a decade and had to make decisions like that.
Apologies in advance if this is asking questions that you are not allowed to comment on.
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.
And no, I am not using LLVMPIPE.
For example ACO (new shader compiler for radv and potentially radeonsi) complies NIR into AMD GCN / RDNA machine code.
> 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?
Competition!
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.