8 ms·
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 abstrac
by gw 6y ago
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.
- gameswithgo 6y agoon top of that more mature "easy mode" wrappers over Vulkan are beginning to exist too.
- kevincox 6y agoThey are beginning to exist but it is very unlikely that these will have the stability that OpenGL has. They will likely be more convenient, but if you are building something today that doesn't have very high performance needs sticking to the OpenGL API is probably a good way to ensure that you won't have to migrate to something else for a very, very long time.
- nicoburns 6y agoThe other good option that's likely to be supported for a long time is WebGPU.
- moron4hire 6y agoWhat "stability that OpenGL has"?
- badsectoracula 6y agoThe OpenGL API is standardized and has multiple implementations so it isn't susceptible to some layer/library developer waking up one morning and deciding to break the API to make it "cleaner" or "easier" or whatever. 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.
- bitwize 6y agoMultiple implementations suck because implementors rarely aim for full compliance, and now you have to have as many code paths as there are implementations to account for the differences between them. Best to have a single implementation that everybody agrees on -- like the winner of the graphics API wars, Direct3D.
- Reelin 6y ago> Best to have a single implementation that everybody agrees on -- like the winner of the graphics API wars, Direct3D. 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?
- imtringued 6y agoD3D drivers for Linux exist but it's through a compatibility layer. https://github.com/doitsujin/dxvk https://github.com/doitsujin/dxvk
- Reelin 6y agoI don't think a compatibility layer implemented in software is the same as a driver implemented by the vendor that interacts directly with the hardware.
- Nullabillity 6y agoMesa actually does support D3D9 natively for AMD (and, sort of, Intel) GPUs via the Gallium Nine project, and there is a branch of Wine that uses it. 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).
- imtringued 6y agoI don't know what you are talking about. Direct3D is Windows only. Metal is iOS and Mac only. Vulkan is in theory supported on all platforms but UWP doesn't allow it and Mac requires a compatibility wrapper. If anything the graphics API war is still going on.
- Nullabillity 6y agoAs long as Vulkan itself stays stable, who cares, just pin the version of the wrapper?
- bsder 6y ago> if you are building something today that doesn't have very high performance needs sticking to the OpenGL API is probably a good way to ensure that you won't have to migrate to something else for a very, very long time. 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.
- abnercoimbre 6y agoSeconding everything here. It's also worth nothing MoltenVK development was sponsored by Valve (that's how they get Dota 2 on macOS.)
- badsectoracula 6y agoOS X runs OpenGL 4.1 and is still available even if deprecated. If you are considering MoltenVK as a viable option then perhaps Zink over MoltenVK would work in the future. 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.
- bsder 6y ago> OS X runs OpenGL 4.1 and is still available even if deprecated. 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.
- pjmlp 6y agoThey already exist, a checkbox away on a middleware engine, that is how much I want to meddle with it. Khronos is now driving the Anari effort, because most visualization toolkits could not be bothered to move forward into Vulkan. https://www.khronos.org/anari https://www.khronos.org/anari Pity that they decided to just bother with C99 though.
- johnnycerberus 6y ago> 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.
- pjmlp 6y agoNot at all, proprietary graphics APIs provide modern bindings in C++, Objective-C, Swift.
- amaranth 6y agoC99 ensures it can be used with basically every other language and can be compiled for almost every platform. Bindings on top of that for other languages would be nice but can be provided by the community too. If it was C++, Rust, Nim, etc you'd have to write it in a way that allows exposing a C API anyway so the only advantage would be for people creating an implementation of the API getting to use a better language internally.
- pjmlp 6y agoThat can be achieved with an IDL that isn't unsafe by default and the cause of endless security bugs. Then everyone can generate whatever bindings they feel like in an automated way.
- pantalaimon 6y agoBut why C99 instead of C11?
- ryandrake 6y agoI've always liked this illustration: Code to draw a triangle in 1. OpenGL 1.x, 2. OpenGL 3+, 3 Vulkan [1]. 1: http://sol.gfxile.net/temp/hellotriangle.png http://sol.gfxile.net/temp/hellotriangle.png
- gw 6y agoIt is pretty wild, though mine wasn't quite as bad. It ended up clocking in at 650 lines. I guess part of that is because nim doesn't have braces... https://github.com/oakes/vulkan_triangle_nim/blob/master/src/core.nim https://github.com/oakes/vulkan_triangle_nim/blob/master/src...
- gameswithgo 6y agosupposedly code the draw doom 4 is less with vulkan than opengl though
- monocasa 6y agoIt's decidedly not optimized for hello world style examples, but it's a lot nicer once you have a non trivial codebase, IMO.
- Reelin 6y ago> glfwCreateWindow(..., "The spinning triangle that took 1397 lines of code", ...); I get it, Vulkan is low level, but still.
- skocznymroczny 6y agoI 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 6y agoWebgl 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 6y agoThe 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 6y agoInteresting. 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 6y agoTypically 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.
- simias 6y agoI'm far from an expert in the field but what annoyed me deeply with OpenGL was the implicit global state and, in particular, the fact that it's very difficult and error-prone to make applications that interact with OpenGL from multiple threads. 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.
- pmarreck 6y ago> the implicit global state and, in particular, the fact that it's very difficult and error-prone to make applications that interact with OpenGL from multiple threads 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
- pcwalton 6y ago> in particular, the fact that it's very difficult and error-prone to make applications that interact with OpenGL from multiple threads. 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.
- moonchild 6y ago> implicit global state 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. 1. https://www.khronos.org/opengl/wiki/Direct_State_Access https://www.khronos.org/opengl/wiki/Direct_State_Access
- shakna 6y agoOpenGL isn't supported everywhere. Apple deprecated OpenGL across all their platforms in June, 2018.
- shmerl 6y agoAnd sabotaged Vulkan support on their systems as well.
- gw 6y agoDeprecated, not removed. In fact opengl will still be supported in the new ARM macs.
- shakna 6y agoDeprecated means not supported, yes? 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.
- monocasa 6y agoIn Apple-speak, 'deprecated' means "we told you so" when/if it gets removed in a few years at a WWDC.
- jokoon 6y agoOpengl is expensive to support, because drivers can be quite large today. 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.
- walkingolof 6y agoWith Vulcan, you are more than ever as a indie developer faced with the question: Are you going to do a game or an engine.
- esperent 6y agoThere are several wrappers for Vulkan that make it easier to work with, like V-EZ. Using one of the is probably the best approach for an indie dev.
- slezyr 6y agoYou simply don't need to touch it. Use the bgfx. https://bkaradzic.github.io/bgfx/overview.html https://bkaradzic.github.io/bgfx/overview.html