3 ms·

OpenGL on macOS is so frustrating, that I and many other developers have basically abandoned it, and not in favor of using Metal--the easier alternative is to j

OpenGL on macOS is so frustrating, that I and many other developers have basically abandoned it, and not in favor of using Metal--the easier alternative is to just no longer support Macs. Yes, OpenGL on macOS is now implemented over Metal, but unfortunately a side effect of this is that implementation-level details that were critical to debugging and profiling OpenGL just no longer exist for tools to work with. Anything is possible? Maybe? I'm sure Apple Graphics engineers could make old tooling work with the new abstraction layer, but it's not happening. Tooling investment is all on Metal now. But so much existing NON-LEGACY software relied on OpenGL. So what do you do? You debug and perf test on Windows and Linux and hope that fixing issues there addresses concerns on macOS, and hopefully your problems aren't platform-specific. This is how some graphics engineers, including myself, continue to ship for macOS while never touching it. Edit: 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. You have to support this stuff. If it were that easy, bgfx would have been written in a month and it would have been considered "done" afterwards.

gernb 4y ago
> 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, ...)
boondaburrah 4y ago
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.
kvark 4y ago
There is WebGPU (for example provided by wgpu/wgpu-native, or dawn). Easier to write, portable, and debuggable as Metal on macOS.
andrekandre 4y ago
> 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?
- andrewmcwatters 4y ago
  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.
  - andrekandre 4y ago
    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?

gernb 4y ago

> 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, ...)

boondaburrah 4y ago

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.

kvark 4y ago

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

andrekandre 4y ago

> 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?

andrewmcwatters 4y ago
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.
- andrekandre 4y ago
  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?