Hacker News Reader

Comment by sgtnoodle | Hacker News Reader

I'm by no means an expert, but my understanding is that OpenGL's API is designed to abstract away details of the underlying hardware, while Vulkan's API is designed to expose the details of the hardware.

When OpenGL was designed, the thinking was that graphics programming is hard, and so the API should do the heavy lifting and make the application's job easy. It turns out, though, that graphics programming is so hard that the majority of folk tend to use even higher level graphics libraries to write their applications.

The folk writing those graphics libraries want to make their libraries as optimally performant as possible, and the abstract nature of the OpenGL API stands in the way of doing that. They would rather just directly access the hardware. Vulkan is an API that gives that direct access, within the limitations of running in an unprivileged userspace process.

View on HN

I still wish there was some kind of middle ground between OpenGL and Vulkan though, as an aspiring indie dev who’s making a 3D game without using Unity/Unreal (The reason for this is that for my game I need at least tens of thousands of simulated AI agents, and conventional gameobject systems aren’t designed to do this performantly.)

The Metal API from Apple seems to be just the right abstraction for general graphics programming, though it sucks that you can only use it on Apple devices. Maybe SDL_gpu can take this role once it’s finished, but till then I’m toiling away with Vulkan… yeah it’s still better than OpenGL, but its usability can definitely be improved. Maybe I should have just gone to DirectX 11… since the drivers there are ridiculously optimized.

> at least tens of thousands of simulated AI agents

Are you planning on displaying all/most of them every frame, or just to control that many of them, then draw those nearby/visible?

If it's the former (but how exactly?) then perhaps Vk is the way to go, if the latter, then it's hard to see how Vulkan vs OpenGL is all that relevant here.

Right, there's no reason to discard a game engine just because its most common usage patterns are inappropriate to your needs. Even if you do need to draw a zillion objects on screen, any engine will let you create your own mesh and feed that to the renderer.

IIRC the game From the Depths does this, being a game where you create ships using thousands of voxels. Using gameobjects for everything just would not have worked

Many of the enemy entities (which I’m expecting to be around the ten-thousands in the late portions of the game) are going to be visible on-screen, since most of them are going to be flying above the ground and only the terrain is going to hide them (no big architectural structures on the map obstructing them). And I would like to create lighting effects when they explode, which would require huge lighting counts.

The AI for the flying enemies isn’t going to be too complex, it will probably going to be some variation of boid simulation. However I still expect this to be computationally intensive, particularly when it comes to querying nearby entities and terrain. I am expecting some of the expensive geometric querying can be moved to the GPU via compute shaders.

The reason for using Vulkan instead of OpenGL was more of a pragmatic one: I’ve heard that OpenGL drivers can be hilariously bad on Windows, when it comes to both conformance and performance. Vulkan seems to be better in that respect, since both Nvidia and Amd has incentive to develop decent enough Vulkan drivers since some high-profile AAA games use it. Also, it is a pain in the ass to debug issues in OpenGL, and Vulkan is at least better than that.

https://github.com/gfx-rs/wgpu

Seconding wgpu, it's so much less verbose than vulkan and the memory safety guarantees are pretty nice.

I don’t want to use Rust though, I want to use C++. (And before all the Rust afficionados immediately jump at me, I just feel much more productive in C++ than Rust when doing graphics programming.) I’ve heard that Google has a C++ webgpu library in the works, but I wasn’t sure if it was stable enough to actually ship games in.

You can use wgpu with C++ via https://github.com/gfx-rs/wgpu-native

You could be using something like Ogre3D, then you have your Apple like solution.

I think Ogre3D and Metal are two really different things though…

By the way do you know how is the current status of the next version of Ogre3D? I’ve heard they were doing a complete overhaul (with a new much performant render system), but I’m not sure if it was actually finished.

Yeah, Ogre3D is a graphics middleware, while Metal is a straigh 3D API, with lots of cool tooling, still it could be an option.

Probably not at this stage of your development.

It has been a decade since I really messed with it, but looking at their site Ogre3D Next seems to be coming along, including Vulkan support.

Have you looked at either Raylib or SFML? Both are somewhat high-level graphics abstraction libraries, but neither are anywhere near the weight or functionality of a proper game engine.

https://www.raylib.com/ https://www.sfml-dev.org/

Or is something like this not what you're looking for?

No, I’m making a 3D game that’s going to lean into heavy shader usage (probably going to implement either deferred or forward clustered rendering), and also might have to potentially use compute shaders for some expensive geometry-querying tasks.

There can still be and there already is plenty of middle grounds between OpenGL and Vulkan. Like Skia, OpenGL etc... They can just be implemented on top of Vulkan. Vulkan is just an API provided by GPU vendors like Nvidia, AMD etc.. to expose the capabilities of their hardware and not worry about accommodating all the edge cases of various graphics use cases in their bloated mess of "drivers".

Here's my fav. rant about it, tldr; GPU Vendors needed a lean API to expose the capabilities of their hardware, and OpenGL: https://www.gamedev.net/forums/topic/666419-what-are-your-op...

If you’re making a 3d game with a customed designed renderer, then what should I use instead of Vulkan though? (The real answer for this is DX11, but assume I care a bit for cross-platform and relatively less vendor lock-in.) Skia is only for 2D graphics, OpenGL has shit drivers on Windows, and WebGPU is still work-in-progress and isn’t something you should depend on just yet. Between DX and Vulkan, there isn’t really that much choice.

You can still use OpenGL. Just not the vendor provided drivers. They are indeed horrible. There are libraries like:

* ANGLE ( https://github.com/google/angle ) - An OpenGL ES implementation with Direct3D 9, Direct3D 11, Desktop GL, GL ES, Vulkan and Metal backends. This is what we used to use for shipping our Qt 3D application, that used a bunch of OpenGL Shaders. We used to get bug reports about various shaders not working properly on various hardware. After switching to this, all those bug reports vanished.

* Zinc ( https://www.supergoodcode.com/do-not/ ) - A more recent, OpenGL implementation on top of Vulkan. I haven't used this one yet. But they are making a lot of progress and it is almost as performant as vendor provided OpenGL Drivers these days. So if I ever have to ship a desktop app, needing opengl, I'd strongly consider using this.

I've had a decent experience with bgfx (https://github.com/bkaradzic/bgfx). It is solely a rendering library (no input, physics, sound, etc). It operates a layer just above a native rendering library, such as DirectX, OpenGL, Vulkan, Metal, etc - those are the "backend renderers" that bgfx uses.

Though I have my complaints about it, I think bgfx gives a good powerful-but-not-too-complicated abstraction over graphics programming; for some design info, see: https://bkaradzic.github.io/bgfx/internals.html

I am also writing a game engine, also because of the gameobject issues, also doing tens of thousands of simulated AI agents. In my case they are GPU-accelerated and I'd guess you are doing something basically similar even if it's CPU-based.

Would be interested to discuss architecture as there aren't many of us out there and not much of a shared knowledge base. I looked for contact info in your profile but didn't immediately turn it up.

also there was no programmable shaders back then and the fixed pipeline was a very reasonable abstraction for the hardware at the time.

https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline

thanks for the explanation!

do you think vulkan will progress into being easier and easier to use? is it mature enough? are there good resource to learn the most basics?

Vulkan may be easy to use one day, but it will probably be because you are "writing vulkan" but actually using an impressive set of libraries, languages and other tooling that do stuff for you that you don't want to do.

People have said this since the early days of Vulkan (such as https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-gra...), but so far nothing has really materialized.

guess it depends on how specialized to vulkan you mean. Like, Aras in this article even mentioned BGFX as a potential abstracted library, and I'm 99.9% certain that it supports vulkan now. But you can certainly argue that with BGFX you're not "writing vulkan".

But if you wanted something that was "vulkan but without 1000 lines to make a triangle", that's what Open GL was trying to be 25 years ago. So Vulkan naturally diverged from that model after seeing the weaknesses. I'm unsure if there's any maintained package trying to wrap this stuff; that's something a graphics engineer would end up doing anyways.

imo, it’s unlikely that it will get much easier directly. if you’re interested in getting into GPU programming, i’d still recommend it. i know it can be daunting at first - the API spec is huge, and there are lots of things to get your head around. ultimately though, the concepts are not exotic or hard to understand. it’s certainly no more difficult than learning to program a regular computer :)

Damn, though the hardware of the GPU is a lot much weirder than what you’re used to with the CPU, and don’t let me even get started about CPU-GPU memory transfers…

> do you think vulkan will progress into being easier and easier to use?

I don't think that is the goal for Vulkan, nor should it be. Vulkan is a low-level, high-performance API that can be used as the backend for high-level, high-performance libraries and frameworks.

> is it mature enough?

Mature enough for what? It's mature and stable enough that you can develop high-level libraries on top of it. wgpu [1], for example, has a Vulkan backend.

[1] wgpu is a WebGPU implementation; https://github.com/gfx-rs/wgpu

Vulkans ease of use is an explicity non-goal I think - it's benefit comes from exposing the maximally flexible set of APIs to control the underlying GPU hardware, which is in direct opposition of a simple "hello world".

The idea is that you use high-level APIs built on top of Vulkan (usually engines like Unity, Unreal or Godot) that then leverage the underlying hardware.

I still think that there should be some room for rogue developers who want to make “weirder” games that need specific technical decisions that you can’t make inside an existing game engine. Unity and Unreal all assume that the world you are making is generally made up of static environmental objects, and are hyper-optimized for that use-case both in terms of workflow and performance optimizations. But for types of games that emphasize simulation, procedural generation, or user creation, these assumptions might not hold and custom engines might serve them better. (Games that come to mind are No Man’a Land, Dreams, Factorio, They Are Billions, etc…)

There's WebGPU Native, with wgpu-native implementing it on top of wgpu, using Vulkan/Metal/DX11/DX12.

It's still work-in-progress though, and people who are developing games right now shouldn't gamble on it. I would rather want to stick with something that has been for at least 5 years and has successfully shipped multiple games, so that's why I'm using Vulkan even with all its problems. (Maybe I should have used DX11 though, if I was seeking for even more stability.)

The restriction there is that by definition will be constrained to the GPU capabilities exposed to WebGPU.

Of course, there can be extensions, but use enough of them and it starts not to make sense to use it for native code.

AMD had V-EZ which seemed interesting to me when I played a bit with Vulkan, but unfortunately it has been unmaintained since 2018...

People were teasing the idea of a good-enough Metal-like API on top of Vulkan that takes care of the pain points since the early days (most notably this article: https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-gra...), but so far, nothing has materialized.

There's a point to make which is that most people don't probably have problems writing Vulkan code, but shaders instead (that's unless you already know OpenGL). For Vulkan you have many good bindings already in different languages, but then you get into actually writing shaders which requires completely different programming mindset -- everything runs in parallel by default. All your algorithms have to be divide and conquer, so say bye bye to imperative style accumulators. The concepts might be hard to grasp unless you know your way around functional and array programming languages.

Reply on news.ycombinator.com