Hacker News Reader

> This is how some graphics engineers, including myself, continue to ship ...

The snarky response would be "you're not a graphics engineer if you're still using OpenGL" (please laugh at the bad joke)

But seriously, knowing how GPUs actually work, OpenGL is pretty horrible. Full OpenGL has 20 years of cruft hacked and glommed on to it. As someone who's job is to write OpenGL emulation it really needs to die and people need to stop using it.

If you don't care but want cross platform OpenGL ES then use ANGLE, or if you want something more modern that ditches most of that 20years of cruft look into one of the native WebGPU implementations (dawn, wgpu, ...)

There is WebGPU (for example provided by wgpu/wgpu-native, or dawn). Easier to write, portable, and debuggable as Metal on macOS.

  > Also, Vulkan is a waste of time for anyone who isn't a large studio. No one wants to write this stuff. The most common argument is "You only write it once." No, you don't.

this is really intersting. its not my area of much knowledge but i'm really curious why that is? what are the issues exactly?

What others have said here is accurate. Vulkan is excessively low-level for most.

OpenGL is not API-machine precise, but widely this isn’t relevant for people who are primarily concerned with shipping products.

APIs like Vulkan, DirectX 12, and WebGPU need to exist, but there is too much fragmentation in the graphics API space now and because of this API decision making that has taken place, the situation will not be smoothed over for probably a decade.

Many people hoped for an OpenGL successor that provided API-machine precision without explicit verbosity that you could simply opt-into if you needed control. Instead what we ended up with were required definitions of API mechanics.

These aren’t obvious to implement. It also debatably moves engineering efforts to the wrong people. There are graphics programmers who should not be involved in adapter-device type programming, who instead should be focusing simply on graphics shader work and the like.

Vulkan is a textbook case of throwing the baby out with the bathwater in pursuit of a more precise API. It throws out development practicality by allowing vendor engineers to wipe their hands of things that some of us want them to take care of.

Imagine if every time you wanted to write software you first needed to probe for what CPU cores existed, and also define how to allocate memory, and also how your program should run.

This is needless. It would also create a scenario where people would say similar things like, “Well sure it’s verbose, but of course you would only write this once.”

And everyone, individually, would do this, because everyone, individually would be forced to, and they’d all have to maintain it.

And along the way, most would get it wrong. Or implement only a subset of desired behavior.

thanks for the reply!

so if i understand correctly, it would have been better to have an api that had more of an onramp with increasing complexity when you needed it, but instead all we got was fragmented low-level apis?

Yes

for me BGFX has become the API since I'm basically tired of wrassling how fragmented graphics programming seems to be. I just wish the shader language wasn't semi-custom GLSL-with-C-macros so I could use existing tooling for previewing/editing what I'm working on.