6 ms·
The only downside I see to this is that the Vulkan space for AMD will leave OpenGL development in the dust. The OpenGL drivers for AMD cards have been sub par o
by Honeybunch 9y ago
The only downside I see to this is that the Vulkan space for AMD will leave OpenGL development in the dust. The OpenGL drivers for AMD cards have been sub par on Windows and Linux for a long time. This doesn't matter much for AAA games but smaller games and most non-game applications don't need and shouldn't want to use Vulkan.
That said as someone who does a bunch of Vulkan development on AMD platforms on Linux I'm really excited. There's nothing bad with some healthy competition.
- ktta 9y agoIs that such a bad thing? Any game dev that's not going to use Vulkan will use a game engine, which will pretty much handle vulkan for them. I'm excited because Vulkan support will mean better GPU compute support across platforms.
- Honeybunch 9y agoNot necessarily. I see a few small games that roll their own OpenGL/DX11 engines due to unique requirements that game engines can't easily accommodate. I don't have any good examples off the top of my head but it's not uncommon to see indie game blog posts talking about why they're not using Unity/Unreal
- outworlder 9y agoMinecraft would be one. Bigger games, Elite Dangerous rolled its own, which is able to use both OpenGL and DX (even though the OpenGL support is no longer useful). Most indie games do not roll their own, however.
- outworlder 9y agoBy platforms, I assume you mean Windows and Linux.
- ktta 9y agoYes, and android too. And depending on MoltenVK's success, maybe Apple devices.
- masklinn 9y agoCouldn't you use Mesa or its ilk to provide OpenGL on top of Vulkan?
- dognotdog 9y agoI cannot think of a single use case from the top of my head where I wouldn't prefer Vulkan over modern OpenGL. In my experience it isn't actually harder to use, even though it's technically "lower level". However, I see the next useful level up from Vulkan not in OpenGL, but an actual 3D engine like Unity, which manages state more usefully from the application's POV than OpenGL.
- Honeybunch 9y agoVulkan takes time to bootstrap. Even if I have a Vulkan bootstrap that works well for one project it may be unusable for another. If I have infinite time I'll use Vulkan but for a lot of people OpenGL is just going to be faster to iterate on. Sometimes this development speed is important while at the same time using an engine like Unity or Unreal isn't going to provide the desired look and or feel. It's a rare intersection but it does exist.
- gpm 9y agoHow long until there are libraries that wrap vulkan well enough that you don't have the bootstrap time though (apart from initial learning time of a new api, that will affect current devs once and future devs never)? I believe gfx-rs is one such effort in rust, as an example.
- exDM69 9y ago> This doesn't matter much for AAA games but smaller games and most non-game applications don't need and shouldn't want to use Vulkan. Most apps don't want to directly use OpenGL either. It's a terrible API that's not much simpler than Vulkan for the programmer (Vulkan is low level and verbose, OpenGL has 25 years of legacy baggage you need to be aware of). OpenGL also has a history of really buggy implementations out there, especially in mobile space. Doing anything with GL requires mountains of QA work on different HW/OS/driver combinations. Ideally there would be some kind of middleware/engine/framework that takes out the tedium of doing graphics with the GPU. But no open source project has really found adoption on this front, it's Unity or UE, both proprietary. One reason for this is that OpenGL is so badly designed with its stateful API that any kind of middleware short of a full game engine is very difficult to get right. Vulkan should be the choice for all green field development right now. OpenGL will stay to support the legacy stuff, but there are no compelling arguments to use it where Vulkan is supported.