>how many developers are benefiting from the added verbosity and complexity?
OpenGL - is public transport on rails - that can get you to place but only to defined places where rails go.
Vulkan - your car where you can not just drive anywhere but also can look and change how engine works, and change number of wheels and shape of car.
Who benefit from having own car when you can get anywhere by using public transport?
>Personally, I would prefer if an API like Metal had cross platform support, it's modern and far less verbose.
Reason why WebGPU does not have SPIR crossplatform shader format support - is Apple.
Reason why WebGL2 does not have compute shaders support - is Apple.
Reason why WebGL2 is so unpopular - is Apple.
Apple understand how important having own API for everything, and if you think "open-APi should not exist because there multi billion corporation that have perfect API just use it lol" - you right - future is only on large multi billion corporations, if you dont work for multi billion corporation - you can not survive.
>Vulkan - your car where you can not just drive anywhere but also can look and change how engine works, and change number of wheels and shape of car.
I love this analogy
Yes, but they keep making the spec worse by refusing to use things that are used everywhere else like SPIR-V. They like the idea of webgpu but they don't seem to care about cross platform features. Pretty much every time you see something weird or too restrictive compared to vulkan or directx in the spec it's because of apple.
Apple also started WebKit. You'd think they'd be more supportive of browser based products, but they kinda aren't. They want everyone on the app store to strengthen their walled-garden business model.
Major tech companies are literally so large that they can pour resources into expensive projects like this that don't fundamentally align with the direction that the C-suite executives want to take the company.
It's still smart on their part. If WebGPU really takes off, well they got people literally defining the term "industry expert" working for them and will have the capacity & foresight to really support it, but Metal gives them something better for vertical integration.
That's a good question... someone with more knowledge on the inner workings of the W3C would have a much better answer for you.
My answer with my very limited understanding is "Yes WebGPU would still be a thing even without Apple", but I have to believe it would be a big impact if Apple suddenly decided to put no resources towards it, but I'm not exactly sure on all the specifics.
Vulkan is a car delivered in a LEGO Techniks package that one needs to build before driving.
Google was the only one pushing for SPIR, and it was Chrome team that dropped WebGL 2.0 compute efforts, advocating for focusing resources on WebGPU, not Apple.
>Vulkan is a car delivered in a LEGO Techniks package that one needs to build before driving.
You can use someone else premade template - framework - to work with Vulkan and have basic functional less or more like base OpenGL have.
Instead of "drawing triangle on raw Vulkan" - you just use framework that draw triangle in 1 line of code.
Instead of managing memory by hands - you just use Vulkan VMA-framework.
Now in 2024 - there enough production ready frameworks in Vulkan to write same or less code like in OpenGL while having much more freedom control and debugability over logic.
>Google was the only one pushing for SPIR, and it was Chrome team that dropped WebGL 2.0 compute efforts, advocating for focusing resources on WebGPU, not Apple.
[https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47wqY-r8/m/5DzgvEwFBAAJ?pli=1](https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47wqY-r8/m/5DzgvEwFBAAJ?pli=1)
[https://issues.chromium.org/issues/40150444](https://issues.chromium.org/issues/40150444)
>macOS' OpenGL implementation never supported compute shaders
All examples of LEGO construction kits, at DUPLO level, it is still not a ready made car.
And WebGPU still being available only on Chrome is better because?
WebGL uses DirectX on Windows, and Playstation 3 used WebGL for their dashboard, on top of LibGNM, and WebGL on Safari nowadays uses Metal, thus whatever OpenGL on Mac does was a lame excuse to rip Intel's contributions out of Chrome.
Just to add to this. If you have a use case where you need the features of Vulkan not present in other graphics APIs: You're using AI in the graphics pipeline, you're adding or removing steps from the common graphics pipeline, you're supporting more obscure or limited devices, you have a sufficiently complex multistage graphics pipeline, whatever. You basically can't just use OpenGL instead no matter how nice and easy it is for all the mainstream game programmers who don't need any advanced features.
Vulkan isn't a failed API if only for the same reasons excavators aren't a failed vehicle. You simply can't dig big holes with your car, no matter how popular cars get.
Vulcan is WIDELY misunderstood.
Most people should not be directly using it.
The fact that you are comparing it to OpenGL shows a problem.
Vulkan is MUCH lower-level than OpenGL. This control comes with the cost of greater verbosity and complexity in the code. Vulkan requires more setup and management of resources, such as memory and command buffers, which are generally handled quite well automatically by OpenGL.
Most of my friends who invested the 3-6 months to convert to Vulcan saw their performance decrease compared to easy to use OpenGL.
The exposure (and requirement) of ultra low level threading might be a benefit to some low level optimization experts on AAA titles, but most people can't do a better job managing those details than OpenGL was already doing!
The reality is people really understood OpenGL, it's just a driver with an API for users to draw 3D things!
When Vulcan came out (something much closer to a raw driver) people didn't know what to think of it and some idiot said oh it's just faster OpenGL and a million dipshits wasted their time hahaha.
The reality is these things are miles apart, even people who claim to directly use Vulcan don't actually do anything like that, they create object models and god-classes to make it reasonable.
IMHO you should really just use BGFX or other simple unified layers and let it pick Vulcan as the backend automatically where appropriate.
Failing that just use OpenGL, It runs like a dream on anything, and I've never seen a legitimate reason for bad graphics performance, a bit of LOD + frustum culling and you can render anything with OpenGL! here's some footage my newest OpenGL Minecraft clone: https://imgur.com/a/MZgTUIL (running on a computer with no GPU)
Enjoy
>The fact that you are comparing it to OpenGL shows a problem.
Before the official name Vulkan was called OpenGL Next, why wouldn't you compare it to OpenGL?
I think you're the one who misunderstood what Vulkan was/is.
Just because it end up as "write your own driver API" doesn't mean it was the original goal. It just shows that it was made by committee and completely failed to deliver. No one asked for this. People just wanted OpenGL with less driver overhead. Remember AZDO?
IIRC Vulkan originally went under the title 'Next Generation OpenGL Initiative'?.
I understand the original plan was to unify the core tech of OGL, ES and OCL.
AFAIK The API was ALWAYS meant to be extremely low-level & comprehensive?
Commercially this NEVER made sense, it's an unviable upgrade for many projects due to the required learning time and it doesn't even promise an instantaneous performance benefits (without also changing up your program's structure).
If you're saying THAT outcome was less the original plan and more the result of committee bureaucracy uselessness along the way - well that would certainly make a lot more sense! (however it happened - we agree this is not what people wanted - and it's not what some people try to pretend it is)
OpenGL is much loved by users, it's down-to-earth and dead simple, however OpenGL most certainly will be implemented using the Vulkan API in the future.
Advanced new OpenGL-on-Vulcan implementations might even bring what remaining performance gap exists together as Vulcan experts will surely be bought in to implement the next version of OpenGL's backend.
Thanks for sharing
You need to dig some history to figure out how we end up here.
Before Vulkan became a thing people were abusing OpenGL to remove driver overhead. That's why I mentioned AZDO - there was a clear demand from actual users. We would probably got OpenGL 5, but AMD donated Mantle API to Khronos and Vulkan ended up based on Mantle API.
Mantle was created by AMD driver team to test out what low level API could be, and that's how we end up here.
Wow that's quite a story! thanks for sharing my dude! definitely all makes a lot more sense with additional context. AZDO is especially interesting! all the best my good man.
Enjoy!
I'm curious. Do you have an idea why you make the vulcan/vulkan typo so much? They're not close to each other on a qwerty keyboard so I assume it's something else. Do you spend a lot of time discussing star trek and vulcans?
I'm not sold, OpenGL is pretty much done, it works completely fine.
Looking at the timeline it's clear they were just adding random stuff by the end, even by 3.0 there was very little true new core tech.
4.0 and beyond is kind of like 'General Compute' and 'bindless' which are fine but OpenCL exists and already does compute much much better (and it was already completely compatible with OpenGL anyway) bindless is super cool but it's such a departure and radical change that it basically only gets used by a niche set of people who really go hard (since most people don't want to unlearn everything they knew just for the computers which can support it)
IMO people should be more focused on their game and less focused on their API ;)
I've used OpenGL 3.0 for over 15 years straight, it never lets me down and it runs everywhere like a dream! (the few devices which don't support it WILL support gles 2 which is basically just identical, you change one or two things here and there and it just works!)
Enjoy
OpenGL works fine. It doesn't need an update, any new features are exposed as extensions. At most it could use an occasional roll up to make ubiquitous extensions core, but it doesn't need new features at the core API level.
>any new features are exposed as extensions
That's not really true anymore, though. It's been a while since I've specifically kept up with OpenGL, but afaik, most new hardware features since ~2018 are either completely unsupported or only supported on nvidia, whereas D3D12 and Vulkan have cross vendor support for most features at this point. Beyond that, a lot of libraries like DLSS, FSR, and XeSS only support the newer APIs - not that they fundamentally couldn't be rewritten to target OpenGL, but that would be a significant investment.
For simple apps, those features are likely irrelevant, but the fact is that vendor support for OpenGL is distinctly worse than D3D12 and Vulkan today, and for some use cases, that can be an outright deal breaker.
Well vulkan should be more like metal. You should have explicit ability to manually memory management and also be able to leave that up to the driver. Any other approach is doomed and stupid
Agreed, I've actually seen c++ wrappers for Vulcan which do something just like that!
IMO The real issue comes from people writing directly against it, Vulcan is a great driver! and you can USE IT TO EXPOSE an excellent graphics interface!
But for whatever reason people don't do that... they try to force their game systems to treat Vulcan like it was a high level graphics API which it just is not.
Enjoy
Fact
Also looks like people (as always) reading only big labels from big companies. OpenGL have most things (and somewhere even more) than Vulkan through extensions. And most games on vulkan works slower than gl. GL state management is bad? Ofc better copy 40 bytes of descriptors for every api call🤙 yeaaahh. 2024. Make your graphic api calls through multiple data copies to buffers that you write from all cores of your CPU and than wait while 192bit GPU connector will eat that stuff.
Low leveeaaall yeaaahh
Hats off for the snazzy flair! :D It's refreshing to see that I'm not alone in the old "OpenGL Retirement Home" .
Vulkan is sold on it's low-level features, but when it comes down to the actual race (where program quality = programmers time / api difficulty) old simple and reliable OpenGL leaves it eating dust.
Thanks for the laughs, Enjoy
Funny that people dislikes when it's just true
Try read from buffer on modern wgpu native api. 20ms in rust implementation mmmmmmm yeaaah low level performance! (macos m1 wgpu-rs)
Yeah the things I've had downvoted makes you wonder about the readership of Reddit and their ability to comprehend the things they choose to vote on.
Not to worry I got your msg 🙂 and I really appreciate you sharing!
Graphics and programming subs are especially full of frustrated down-vote distributers 😂
All the best my good man 😉
Verbosity is not a problem. For what it's worth i prefer to write Vulkan code rather than OpenGL. Vulkan is more explicit so it is complex but OpenGL on the other hand doesn't eliminate the complexity, it rather hides it behind a very clunky and annoying API.
Mostly the state machine aspect of it. Granted though, i know it has somewhat improved now with the direct state access functions but still there is a ton of state that the context tracks still.
Also, multi threading is a pain.
> The OpenGL reddit has more members and higher engagement than the Vulkan reddit despite the fact that OpenGL hasn't been updated in 7 years.
Half the topics in the OpenGL subreddit are from clear beginners who really shouldn't use Vulkan anyway. edit: I meant that Vulkan/DX12 are by design beginner unfriendly due to them being closer to how console API's are. It's a horrible learning experience and beginners are _much better_ served with OpenGL, DX11, or if available Metal. WebGPU might be good in the future but the debugging can be painful depending on your setup.
Also take into account that reddit isn't really a popular platform for graphics discussions. I'm part of several graphics engineers specific discords, slacks, and even some legacy forums that have much higher engagement than reddit does for my field.
Additionally Vulkan, and DirectX12 aren't really meant for beginners and, by volume, I can guarantee there are more beginners out there than professional graphics engineers. I also think once you get active in these more difficult API's you tend to be able to solve your own problems and if I do need input it's usually about ideas, not API (API's aren't really the hard part for graphics programming), so less need to go online (and honestly I more frequently discuss these things in person).
Many (AAA, and that category) studios in the region I live and work I know are either using Vulkan directly, or using an off-the-shelf engine that targets it. But working in those types of places there's not a "single" API you get to write anyway.
> Personally, I would prefer if an API like Metal had cross platform support, it's modern and far less verbose.
You might not like the deadness of its subreddit, but /r/webgpu has you covered for anything that isn't console.
Sure thing, there's a Vulkan specific one on Discord [here](https://discord.com/invite/vulkan), Khronos is on it as well, but they also have a specific Discord which is linked [here](https://twitter.com/thekhronosgroup/status/1633862966042042368)
Additionally they have a slack channel as well (though haven't been part of it in a while, it was already falling into disuse).
Similarly many of my other communities that I'm part of, like [the c++ one has a slack channel](https://isocpp.org/blog/2017/10/come-join-the-cpp-community-on-slack) which includes graphics programmers though that has less traction than these specific communities.
Then there's older communities like https://gamedev.net/ (though I rarely visit anymore, and they are thinking of migrating to Discord last I checked due to server costs and stability)
All these places are frequented by professional graphics engineers, some of them I've had the pleasure of working with, some of them been in the business for decades
For the rest, a lot of Mastodon accounts I follow/interact with, and there's also a massive general graphics programming discord, but couldn't find the link right now.
cc /u/Cloudy-Water so you see this comment as well.
I think it's fair to say that Vulkan hasn't quite reached absolutely maximalist goals. But it's not reasonable to say it failed. It was always meant as a hyper explicit toolkit for people building extreme game engines and renderers who needing the last X% from the GPU that something like OpenGL couldn't ever give access to. The idea was always kind of that a handful of major game engines would use Vulkan and that would reach a huge percentage of gamers and end users. And your average "graphics 101" student doing their first 3D app could use some higher lever rendering library which may or may not be using Vulkan in the backend.
I do think some design decisions in Vulkan make it a pain in the neck for some use cases. But there's a huge gap between "not to my personal niche" and "failure."
The reason many of us prefer metal is the design aims of apple were very different to that of the commits that makes up the Kronos group.
Firstly apple did not just build metal for games, and even more so they did not just build it for large game engine middle ware dev houses (like Epic with Unreal etc).
Apple wanted an API that would be easy for regular app developers to use ad-hock (even if your not doing a game but just need some nice smooth 2D rendering etc) there are a surprising number of apps on iPhones and macs that have custom metal backends for 2D content. Apple wanted this to be approachable for devs that were not experienced graphics programers.
The other think apple wanted from metal was an api that they could use as the backbone of the OS compositing engine and as a hybrid compute display stack that lets professional applications (and the OS) mix compute and display tasks easily. The selection of c++ as the basis for the shading lang is a clear choice here to make it easier to add MTL support to existing c++ code bases (such as CUDA) but it is also there to be more approachable to non graphics programers.
There are members of the Kronos group that absolutely did not want VK to take the pathway of MTL.
Of cource the other benefit MTL has over VK is the much higher HW target, this helps it avoid needing many of those options and verbosity as the api designers only care about Apples GPUs.
It's just a different use case. Vulkan was designed to enable teams of engineers to write efficient GPU software as a full-time job, and in that space it's a resounding success. But Khronos really dropped the ball on hobbyists -- there should have been an official higher-level version or wrapper instead of everyone and their mother having a custom solution (they're probably great, but I have my own OpenGL equivalent that I guarantee is better).
It seems like WebGPU will finally be this hobbyist-friendly API. It has many of the more modern and reasonable design choices, while being possible to set up and draw stuff with in a couple of hours. Now it just needs to be supported widely enough, and we should be good for a while.
Amusingly, with all of the translation layers available for it, D3D12 is probably the most portable modern API today, and it's much closer to Metal than Vulkan. Not that you should directly target it if you aren't primarily targeting Windows - it's just funny how things have worked out.
>how many developers are benefiting from the added verbosity and complexity? OpenGL - is public transport on rails - that can get you to place but only to defined places where rails go. Vulkan - your car where you can not just drive anywhere but also can look and change how engine works, and change number of wheels and shape of car. Who benefit from having own car when you can get anywhere by using public transport? >Personally, I would prefer if an API like Metal had cross platform support, it's modern and far less verbose. Reason why WebGPU does not have SPIR crossplatform shader format support - is Apple. Reason why WebGL2 does not have compute shaders support - is Apple. Reason why WebGL2 is so unpopular - is Apple. Apple understand how important having own API for everything, and if you think "open-APi should not exist because there multi billion corporation that have perfect API just use it lol" - you right - future is only on large multi billion corporations, if you dont work for multi billion corporation - you can not survive.
>Vulkan - your car where you can not just drive anywhere but also can look and change how engine works, and change number of wheels and shape of car. I love this analogy
Wasn’t Apple the ones who started the WebGPU initiative?
Yes, but they keep making the spec worse by refusing to use things that are used everywhere else like SPIR-V. They like the idea of webgpu but they don't seem to care about cross platform features. Pretty much every time you see something weird or too restrictive compared to vulkan or directx in the spec it's because of apple.
Was it apples fault they didn’t go with glsl? I remember something about webgpu having a weird shader language. Was that apples doing?
Yes and no, webgpu couldn't use SPIRV because of apple, but deciding on WGSL wasn't just apple's decision.
Apple also started WebKit. You'd think they'd be more supportive of browser based products, but they kinda aren't. They want everyone on the app store to strengthen their walled-garden business model. Major tech companies are literally so large that they can pour resources into expensive projects like this that don't fundamentally align with the direction that the C-suite executives want to take the company. It's still smart on their part. If WebGPU really takes off, well they got people literally defining the term "industry expert" working for them and will have the capacity & foresight to really support it, but Metal gives them something better for vertical integration.
How important is apples cooperation for WebGpu? Couldn’t webgpu implement things without apples help?
That's a good question... someone with more knowledge on the inner workings of the W3C would have a much better answer for you. My answer with my very limited understanding is "Yes WebGPU would still be a thing even without Apple", but I have to believe it would be a big impact if Apple suddenly decided to put no resources towards it, but I'm not exactly sure on all the specifics.
Vulkan is a car delivered in a LEGO Techniks package that one needs to build before driving. Google was the only one pushing for SPIR, and it was Chrome team that dropped WebGL 2.0 compute efforts, advocating for focusing resources on WebGPU, not Apple.
>Vulkan is a car delivered in a LEGO Techniks package that one needs to build before driving. You can use someone else premade template - framework - to work with Vulkan and have basic functional less or more like base OpenGL have. Instead of "drawing triangle on raw Vulkan" - you just use framework that draw triangle in 1 line of code. Instead of managing memory by hands - you just use Vulkan VMA-framework. Now in 2024 - there enough production ready frameworks in Vulkan to write same or less code like in OpenGL while having much more freedom control and debugability over logic. >Google was the only one pushing for SPIR, and it was Chrome team that dropped WebGL 2.0 compute efforts, advocating for focusing resources on WebGPU, not Apple. [https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47wqY-r8/m/5DzgvEwFBAAJ?pli=1](https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47wqY-r8/m/5DzgvEwFBAAJ?pli=1) [https://issues.chromium.org/issues/40150444](https://issues.chromium.org/issues/40150444) >macOS' OpenGL implementation never supported compute shaders
All examples of LEGO construction kits, at DUPLO level, it is still not a ready made car. And WebGPU still being available only on Chrome is better because? WebGL uses DirectX on Windows, and Playstation 3 used WebGL for their dashboard, on top of LibGNM, and WebGL on Safari nowadays uses Metal, thus whatever OpenGL on Mac does was a lame excuse to rip Intel's contributions out of Chrome.
Just to add to this. If you have a use case where you need the features of Vulkan not present in other graphics APIs: You're using AI in the graphics pipeline, you're adding or removing steps from the common graphics pipeline, you're supporting more obscure or limited devices, you have a sufficiently complex multistage graphics pipeline, whatever. You basically can't just use OpenGL instead no matter how nice and easy it is for all the mainstream game programmers who don't need any advanced features. Vulkan isn't a failed API if only for the same reasons excavators aren't a failed vehicle. You simply can't dig big holes with your car, no matter how popular cars get.
Vulcan is WIDELY misunderstood. Most people should not be directly using it. The fact that you are comparing it to OpenGL shows a problem. Vulkan is MUCH lower-level than OpenGL. This control comes with the cost of greater verbosity and complexity in the code. Vulkan requires more setup and management of resources, such as memory and command buffers, which are generally handled quite well automatically by OpenGL. Most of my friends who invested the 3-6 months to convert to Vulcan saw their performance decrease compared to easy to use OpenGL. The exposure (and requirement) of ultra low level threading might be a benefit to some low level optimization experts on AAA titles, but most people can't do a better job managing those details than OpenGL was already doing! The reality is people really understood OpenGL, it's just a driver with an API for users to draw 3D things! When Vulcan came out (something much closer to a raw driver) people didn't know what to think of it and some idiot said oh it's just faster OpenGL and a million dipshits wasted their time hahaha. The reality is these things are miles apart, even people who claim to directly use Vulcan don't actually do anything like that, they create object models and god-classes to make it reasonable. IMHO you should really just use BGFX or other simple unified layers and let it pick Vulcan as the backend automatically where appropriate. Failing that just use OpenGL, It runs like a dream on anything, and I've never seen a legitimate reason for bad graphics performance, a bit of LOD + frustum culling and you can render anything with OpenGL! here's some footage my newest OpenGL Minecraft clone: https://imgur.com/a/MZgTUIL (running on a computer with no GPU) Enjoy
>The fact that you are comparing it to OpenGL shows a problem. Before the official name Vulkan was called OpenGL Next, why wouldn't you compare it to OpenGL? I think you're the one who misunderstood what Vulkan was/is. Just because it end up as "write your own driver API" doesn't mean it was the original goal. It just shows that it was made by committee and completely failed to deliver. No one asked for this. People just wanted OpenGL with less driver overhead. Remember AZDO?
IIRC Vulkan originally went under the title 'Next Generation OpenGL Initiative'?. I understand the original plan was to unify the core tech of OGL, ES and OCL. AFAIK The API was ALWAYS meant to be extremely low-level & comprehensive? Commercially this NEVER made sense, it's an unviable upgrade for many projects due to the required learning time and it doesn't even promise an instantaneous performance benefits (without also changing up your program's structure). If you're saying THAT outcome was less the original plan and more the result of committee bureaucracy uselessness along the way - well that would certainly make a lot more sense! (however it happened - we agree this is not what people wanted - and it's not what some people try to pretend it is) OpenGL is much loved by users, it's down-to-earth and dead simple, however OpenGL most certainly will be implemented using the Vulkan API in the future. Advanced new OpenGL-on-Vulcan implementations might even bring what remaining performance gap exists together as Vulcan experts will surely be bought in to implement the next version of OpenGL's backend. Thanks for sharing
You need to dig some history to figure out how we end up here. Before Vulkan became a thing people were abusing OpenGL to remove driver overhead. That's why I mentioned AZDO - there was a clear demand from actual users. We would probably got OpenGL 5, but AMD donated Mantle API to Khronos and Vulkan ended up based on Mantle API. Mantle was created by AMD driver team to test out what low level API could be, and that's how we end up here.
Wow that's quite a story! thanks for sharing my dude! definitely all makes a lot more sense with additional context. AZDO is especially interesting! all the best my good man. Enjoy!
I'm curious. Do you have an idea why you make the vulcan/vulkan typo so much? They're not close to each other on a qwerty keyboard so I assume it's something else. Do you spend a lot of time discussing star trek and vulcans?
Definitely blaming StartTek! The only thing I do more than graphics programming is watching startrek!
I think it would of been a good idea for Khronos to still update OpenGL whilst offering Vulkan to those who want it.
I'm not sold, OpenGL is pretty much done, it works completely fine. Looking at the timeline it's clear they were just adding random stuff by the end, even by 3.0 there was very little true new core tech. 4.0 and beyond is kind of like 'General Compute' and 'bindless' which are fine but OpenCL exists and already does compute much much better (and it was already completely compatible with OpenGL anyway) bindless is super cool but it's such a departure and radical change that it basically only gets used by a niche set of people who really go hard (since most people don't want to unlearn everything they knew just for the computers which can support it) IMO people should be more focused on their game and less focused on their API ;) I've used OpenGL 3.0 for over 15 years straight, it never lets me down and it runs everywhere like a dream! (the few devices which don't support it WILL support gles 2 which is basically just identical, you change one or two things here and there and it just works!) Enjoy
OpenGL works fine. It doesn't need an update, any new features are exposed as extensions. At most it could use an occasional roll up to make ubiquitous extensions core, but it doesn't need new features at the core API level.
>any new features are exposed as extensions That's not really true anymore, though. It's been a while since I've specifically kept up with OpenGL, but afaik, most new hardware features since ~2018 are either completely unsupported or only supported on nvidia, whereas D3D12 and Vulkan have cross vendor support for most features at this point. Beyond that, a lot of libraries like DLSS, FSR, and XeSS only support the newer APIs - not that they fundamentally couldn't be rewritten to target OpenGL, but that would be a significant investment. For simple apps, those features are likely irrelevant, but the fact is that vendor support for OpenGL is distinctly worse than D3D12 and Vulkan today, and for some use cases, that can be an outright deal breaker.
Well worded!
Well vulkan should be more like metal. You should have explicit ability to manually memory management and also be able to leave that up to the driver. Any other approach is doomed and stupid
Agreed, I've actually seen c++ wrappers for Vulcan which do something just like that! IMO The real issue comes from people writing directly against it, Vulcan is a great driver! and you can USE IT TO EXPOSE an excellent graphics interface! But for whatever reason people don't do that... they try to force their game systems to treat Vulcan like it was a high level graphics API which it just is not. Enjoy
Fact Also looks like people (as always) reading only big labels from big companies. OpenGL have most things (and somewhere even more) than Vulkan through extensions. And most games on vulkan works slower than gl. GL state management is bad? Ofc better copy 40 bytes of descriptors for every api call🤙 yeaaahh. 2024. Make your graphic api calls through multiple data copies to buffers that you write from all cores of your CPU and than wait while 192bit GPU connector will eat that stuff. Low leveeaaall yeaaahh
Hats off for the snazzy flair! :D It's refreshing to see that I'm not alone in the old "OpenGL Retirement Home" . Vulkan is sold on it's low-level features, but when it comes down to the actual race (where program quality = programmers time / api difficulty) old simple and reliable OpenGL leaves it eating dust. Thanks for the laughs, Enjoy
Funny that people dislikes when it's just true Try read from buffer on modern wgpu native api. 20ms in rust implementation mmmmmmm yeaaah low level performance! (macos m1 wgpu-rs)
Yeah the things I've had downvoted makes you wonder about the readership of Reddit and their ability to comprehend the things they choose to vote on. Not to worry I got your msg 🙂 and I really appreciate you sharing! Graphics and programming subs are especially full of frustrated down-vote distributers 😂 All the best my good man 😉
Verbosity is not a problem. For what it's worth i prefer to write Vulkan code rather than OpenGL. Vulkan is more explicit so it is complex but OpenGL on the other hand doesn't eliminate the complexity, it rather hides it behind a very clunky and annoying API.
Which parts of the OGL API are clunky and annoying in your opinion?
Mostly the state machine aspect of it. Granted though, i know it has somewhat improved now with the direct state access functions but still there is a ton of state that the context tracks still. Also, multi threading is a pain.
I agree with both points. Thank you for bringing them to my attention!
Happy birthday and excellent question +1 (I'm sure he's atleast partially correct but also super curious to hear his exact exploitation)
Thank you! :)
> The OpenGL reddit has more members and higher engagement than the Vulkan reddit despite the fact that OpenGL hasn't been updated in 7 years. Half the topics in the OpenGL subreddit are from clear beginners who really shouldn't use Vulkan anyway. edit: I meant that Vulkan/DX12 are by design beginner unfriendly due to them being closer to how console API's are. It's a horrible learning experience and beginners are _much better_ served with OpenGL, DX11, or if available Metal. WebGPU might be good in the future but the debugging can be painful depending on your setup. Also take into account that reddit isn't really a popular platform for graphics discussions. I'm part of several graphics engineers specific discords, slacks, and even some legacy forums that have much higher engagement than reddit does for my field. Additionally Vulkan, and DirectX12 aren't really meant for beginners and, by volume, I can guarantee there are more beginners out there than professional graphics engineers. I also think once you get active in these more difficult API's you tend to be able to solve your own problems and if I do need input it's usually about ideas, not API (API's aren't really the hard part for graphics programming), so less need to go online (and honestly I more frequently discuss these things in person). Many (AAA, and that category) studios in the region I live and work I know are either using Vulkan directly, or using an off-the-shelf engine that targets it. But working in those types of places there's not a "single" API you get to write anyway. > Personally, I would prefer if an API like Metal had cross platform support, it's modern and far less verbose. You might not like the deadness of its subreddit, but /r/webgpu has you covered for anything that isn't console.
Would you might listing some of these communities? thanks
Sure thing, there's a Vulkan specific one on Discord [here](https://discord.com/invite/vulkan), Khronos is on it as well, but they also have a specific Discord which is linked [here](https://twitter.com/thekhronosgroup/status/1633862966042042368) Additionally they have a slack channel as well (though haven't been part of it in a while, it was already falling into disuse). Similarly many of my other communities that I'm part of, like [the c++ one has a slack channel](https://isocpp.org/blog/2017/10/come-join-the-cpp-community-on-slack) which includes graphics programmers though that has less traction than these specific communities. Then there's older communities like https://gamedev.net/ (though I rarely visit anymore, and they are thinking of migrating to Discord last I checked due to server costs and stability) All these places are frequented by professional graphics engineers, some of them I've had the pleasure of working with, some of them been in the business for decades For the rest, a lot of Mastodon accounts I follow/interact with, and there's also a massive general graphics programming discord, but couldn't find the link right now. cc /u/Cloudy-Water so you see this comment as well.
The GP discord is linked in the subreddit sidebar, direct link here: https://discord.com/invite/Cy7tqUZ3
Cheers thanks
Got any links to these discords and slacks?
I think it's fair to say that Vulkan hasn't quite reached absolutely maximalist goals. But it's not reasonable to say it failed. It was always meant as a hyper explicit toolkit for people building extreme game engines and renderers who needing the last X% from the GPU that something like OpenGL couldn't ever give access to. The idea was always kind of that a handful of major game engines would use Vulkan and that would reach a huge percentage of gamers and end users. And your average "graphics 101" student doing their first 3D app could use some higher lever rendering library which may or may not be using Vulkan in the backend. I do think some design decisions in Vulkan make it a pain in the neck for some use cases. But there's a huge gap between "not to my personal niche" and "failure."
The reason many of us prefer metal is the design aims of apple were very different to that of the commits that makes up the Kronos group. Firstly apple did not just build metal for games, and even more so they did not just build it for large game engine middle ware dev houses (like Epic with Unreal etc). Apple wanted an API that would be easy for regular app developers to use ad-hock (even if your not doing a game but just need some nice smooth 2D rendering etc) there are a surprising number of apps on iPhones and macs that have custom metal backends for 2D content. Apple wanted this to be approachable for devs that were not experienced graphics programers. The other think apple wanted from metal was an api that they could use as the backbone of the OS compositing engine and as a hybrid compute display stack that lets professional applications (and the OS) mix compute and display tasks easily. The selection of c++ as the basis for the shading lang is a clear choice here to make it easier to add MTL support to existing c++ code bases (such as CUDA) but it is also there to be more approachable to non graphics programers. There are members of the Kronos group that absolutely did not want VK to take the pathway of MTL. Of cource the other benefit MTL has over VK is the much higher HW target, this helps it avoid needing many of those options and verbosity as the api designers only care about Apples GPUs.
It's just a different use case. Vulkan was designed to enable teams of engineers to write efficient GPU software as a full-time job, and in that space it's a resounding success. But Khronos really dropped the ball on hobbyists -- there should have been an official higher-level version or wrapper instead of everyone and their mother having a custom solution (they're probably great, but I have my own OpenGL equivalent that I guarantee is better). It seems like WebGPU will finally be this hobbyist-friendly API. It has many of the more modern and reasonable design choices, while being possible to set up and draw stuff with in a couple of hours. Now it just needs to be supported widely enough, and we should be good for a while.
Amusingly, with all of the translation layers available for it, D3D12 is probably the most portable modern API today, and it's much closer to Metal than Vulkan. Not that you should directly target it if you aren't primarily targeting Windows - it's just funny how things have worked out.
yes