5 ms·

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (in

by davedx 7y ago

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (including ARM), it’s below 50% on Android, and totally absent on macOS and iOS. Vulkan Portability aims to solve it, but it’s another fairly complex layer for your application, especially considering the shader translation logic of SPIRV-Cross, and it’s still a WIP. Wow. Has Vulkan failed as a standard then? I'm interested in this area but came away from the article feeling extremely confused about what the future of portable graphics programming looks like. I know despite the hopes for WebGPU there's NWIH I will invest time learning it while everything is so up in the air. OpenGL is great despite its warts, I've had a lot of fun programming with it over all the years.

xt00 7y ago
Vulkan was not well supported in android until around android 9. In android 10 I believe it can run skia using vulkan (somehow). And broadly vulkan is still in the adoption curve — so seems too early to say vulkan is failing —it’s still quite new.
- pjmlp 7y ago
  Vulkan started as optional API on Android and its support is so bad outside Google and Samsung flagship devices, that with Android 10 Google made it a required API with respective OEM acceptance tests. Yet, the numbers are so tiny that Google has yet to bother to list them on Android Dashboard, https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards Last update was on May 1, 2020.
flohofwoe 7y ago
TBH (and IMHO of course) both OpenGL and Vulkan aren't all that great APIs to work with. OpenGL was a nice API up until early 2.x versions, after that the move away from the fixed-function-pipeline would have needed a clear cut instead of the gradual stacking of new features, and since then two or three other of such "clear cuts" would also have helped, similar to how each new D3D version was incompatible with the previous version (but still supported for a long time). Vulkan had a problem right from the start that it had to wrap an explicit low-level API over very different GPU architectures. And without the "wiggle room" of more abstract APIs this ended up in a complex API and high number of vendor-specific extensions in a very short time. As a result Vulkan was already bigger and more complex right from the start than OpenGL was after two decades.
- gnulinux 7y ago
  I'm personally pretty comfortable with OpenCL and "old" OpenGL (i.e. using immediate point API which is deprecated now, I didn't do any graphics coding for ~a decade). But I found Vulkan impenetrable. The boilerplate code was absolute insanity. I tried to find some libraries that'll implement the boilerplate for me, but couldn't find anything good enough. Maybe I didn't look hard enough, idk, but Vulkan didn't seem like something an OpenGL engineer could pick up in one afternoon.
  - jfkebwjsbx 7y ago
    To understand Vulkan, Metal or Direct3D 12, you first need to understand modern high-level APIs like OpenGL 4 or Direct3D 11. The fixed-function pipeline is nothing like the new way of doing things. Then you can move to low-level ones, if you really want to spend a few weeks on it! But if it is a hobby, I suggest you stay with a high-level one.
DagAgren 7y ago
OpenGL in 2020 is basically all warts, if you want it to actually be performant at all.
- vetinari 7y ago
  AZDO is pretty nice, if you are OK that your app won't run on some devices (which include all these running macOS).
  - DagAgren 7y ago
    That is the exact thing that is "all warts". It is bending the OpenGL API far beyond its breaking point to desperately try to get it to match what the GPU actually wants.
    - deleted 7y ago
      [deleted]
gmueckl 7y ago
Sadly, OpenGL is dead for a lot of use cases. The medium term future will certainly be competing abstraction layers over varying subsets of D3D, Metal, Vulkan, OpenGL and OpenGL ES. Libraries like bgfx and game engines lead the way. Direct programming against low level APIs is too complex for mere mortals who want to create an actual application without an army of devs just for porting their graphics rendering to different devices (e.g. Vulkan allows for tons of subtle and hard to handle variations in device behaviour and these happen in practice).
greggman3 7y ago
There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).
- kevingadd 7y ago
  While true this boils down to "Apple won't support anything it doesn't have control over", as demonstrated by them using veto power to pick WebGPU's shader language (a custom one) instead of using the shader IR literally everyone else wanted. It doesn't make a ton of sense to evaluate the success of APIs and standards this way because Apple has a long track record of refusing to implement stuff or deprecating it once they had an interest in promoting a proprietary alternative.
  - deleted 7y ago
    [deleted]
  - kvark 7y ago
    That paints Apple in a wrong light. They agreed on the WebGPU Shading Language proposed by Google (!) (previously called "Tint"). This is something Google is interested in, as well.
    - kevingadd 7y ago
      It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it. "MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that. NT: nobody is forced to come into Khronos’ IP framework." https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_253vEtKxuUkTGvxpuv8Ac/edit https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...
      - kvark 7y ago
pjmlp 7y ago
Game consoles also don't support Khronos standards. Switch has Vulkan, but it has its own NVN, which is what middleware engines and most Switch titles actually take advantage of. Given that Unity has shared numbers that they are responsible for 50% of the Switch titles, and there is also other middleware, there aren't many titles left.
jfkebwjsbx 7y ago
Vulkan is fine and major games are shipping with it, but you should never expect any 3D API to become standard. Hardware and software vendors will never agree on one, at least for 10 years. Vulkan is supported on macOS through MoltenVK, provided by Khronos.
- kvark 7y ago
  MoltenVK is not a Khronos product. It's a product of Brenwill Workshop that is one of the many member companies under Khronos. It moved the code under Khronos github. There is quite a few community / other companies contributions. But it's still just a library out there.
  - jfkebwjsbx 7y ago
    It is provided by Khronos in the sense that they control the repository and they provide it as a permissive, open, free license, which is the important bit for end users of Vulkan. Whoever develops it is not really important for managers deciding on technologies to use.
fulafel 7y ago
Vulkan is very successful as standards go, most never get near the coverage. But from the early days it was clear that MS and Apple will bet on their own proprietary APIs so the current situation is not news.
- pjmlp 7y ago
  Missing Sony and Nintendo (Switch main API is NVN) there.
  - fulafel 7y ago
    Kind of.. Consoles always use proprietary APIs.
kllrnohj 7y ago
> Wow. Has Vulkan failed as a standard then? I'm interested in this area but came away from the article feeling extremely confused about what the future of portable graphics programming looks like. Other than MacOS/iOS Vulkan's future looks just fine. Windows UWP has failed so incredibly hard that the Windows Store has begun allowing win32 app distribution, so what UWP supports is irrelevant. And Microsoft's game division has even given up on the Windows Store and releases their games on Steam now as well. So UWP is doubly irrelevant currently. Intel's Skylake & newer support Vulkan 1.1 (which are 4 years old now). Not supporting Haswell/Broadwell is annoying as those do support D3D12, but that's the only API gap in Intel's lineup, and that's obviously something that's on a clock to stop mattering at some point. After all, Intel's iGPU primarily matters on laptops, and laptops tend to have a shorter lifespan than desktops as things other than the CPU show their age a lot more quickly. The 50% on Android is also a thing that'll be solved with time. If Khronos doesn't do a new OpenGL ES, then eventually the driver priority on mobile will shift over to Vulkan as that's what benchmarks will begin prioritizing, and that's what sells hardware. Android's latency to supporting something new is incredibly long, but it does also keep moving forwards fairly reliably. So MacOS/iOS is currently the only real question mark on Vulkan's future. But then again, Apple seems to only want Metal on their platform, which doesn't work anywhere else, so no "standard" will matter. You'll be forced onto a compatibility layer of some kind to work on Apple - be it MoltenVK, bgfx/sokol-gfx, or WebGPU. The article dresses up WebGPU as being superior because it's backed by a standard, but that's nonsense. The quality of the implementation is the only thing that matters, and bgfx/sokol-gfx already have quite the head-start there. There's no particular reason to think a couple of people on Firefox are going to be "strictly superior" to the couple of people on bgfx/sokol-gfx. Maybe WebGPU will end up better, in which case great! But it's the same basic thing as what already exists today. It's very firmly in the "compatibility layer" camp here, despite the article trying desperately to dress it up as something else. There's no driver support for it, there's no influence on hardware road-maps, etc... So right now if you could only target a single driver API then Vulkan would cover more platforms than any other driver-native standard. Which is no small feat.
- pjmlp 7y ago
  Another one that doesn't understand UWP is also the future of Windows APIs. Also as information the WIn32 sandbox model also only allows DirectX, and Microsoft way forward is to support OpenGL on top of DirectX. https://devblogs.microsoft.com/directx/in-the-works-opencl-and-opengl-mapping-layers-to-directx/ https://devblogs.microsoft.com/directx/in-the-works-opencl-a... Expect Vulkan to get a similar treatment, the OpenGL 1.1 ICD driver model won't exist forever. Vulkan on Android is still so meaningless that the dashboard, updated this month, still doesn't show Vulkan support. https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards And then there are the game consoles.

by davedx 7y ago

xt00 7y ago

Vulkan was not well supported in android until around android 9. In android 10 I believe it can run skia using vulkan (somehow). And broadly vulkan is still in the adoption curve — so seems too early to say vulkan is failing —it’s still quite new.

pjmlp 7y ago
Vulkan started as optional API on Android and its support is so bad outside Google and Samsung flagship devices, that with Android 10 Google made it a required API with respective OEM acceptance tests. Yet, the numbers are so tiny that Google has yet to bother to list them on Android Dashboard, https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards Last update was on May 1, 2020.

flohofwoe 7y ago

TBH (and IMHO of course) both OpenGL and Vulkan aren't all that great APIs to work with. OpenGL was a nice API up until early 2.x versions, after that the move away from the fixed-function-pipeline would have needed a clear cut instead of the gradual stacking of new features, and since then two or three other of such "clear cuts" would also have helped, similar to how each new D3D version was incompatible with the previous version (but still supported for a long time). Vulkan had a problem right from the start that it had to wrap an explicit low-level API over very different GPU architectures. And without the "wiggle room" of more abstract APIs this ended up in a complex API and high number of vendor-specific extensions in a very short time. As a result Vulkan was already bigger and more complex right from the start than OpenGL was after two decades.

gnulinux 7y ago
I'm personally pretty comfortable with OpenCL and "old" OpenGL (i.e. using immediate point API which is deprecated now, I didn't do any graphics coding for ~a decade). But I found Vulkan impenetrable. The boilerplate code was absolute insanity. I tried to find some libraries that'll implement the boilerplate for me, but couldn't find anything good enough. Maybe I didn't look hard enough, idk, but Vulkan didn't seem like something an OpenGL engineer could pick up in one afternoon.
- jfkebwjsbx 7y ago
  To understand Vulkan, Metal or Direct3D 12, you first need to understand modern high-level APIs like OpenGL 4 or Direct3D 11. The fixed-function pipeline is nothing like the new way of doing things. Then you can move to low-level ones, if you really want to spend a few weeks on it! But if it is a hobby, I suggest you stay with a high-level one.

DagAgren 7y ago

OpenGL in 2020 is basically all warts, if you want it to actually be performant at all.

vetinari 7y ago
AZDO is pretty nice, if you are OK that your app won't run on some devices (which include all these running macOS).
- DagAgren 7y ago
  That is the exact thing that is "all warts". It is bending the OpenGL API far beyond its breaking point to desperately try to get it to match what the GPU actually wants.
  - deleted 7y ago
    [deleted]

gmueckl 7y ago

Sadly, OpenGL is dead for a lot of use cases. The medium term future will certainly be competing abstraction layers over varying subsets of D3D, Metal, Vulkan, OpenGL and OpenGL ES. Libraries like bgfx and game engines lead the way. Direct programming against low level APIs is too complex for mere mortals who want to create an actual application without an army of devs just for porting their graphics rendering to different devices (e.g. Vulkan allows for tons of subtle and hard to handle variations in device behaviour and these happen in practice).

greggman3 7y ago

There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).

kevingadd 7y ago
While true this boils down to "Apple won't support anything it doesn't have control over", as demonstrated by them using veto power to pick WebGPU's shader language (a custom one) instead of using the shader IR literally everyone else wanted. It doesn't make a ton of sense to evaluate the success of APIs and standards this way because Apple has a long track record of refusing to implement stuff or deprecating it once they had an interest in promoting a proprietary alternative.
- deleted 7y ago
  [deleted]
- kvark 7y ago
  That paints Apple in a wrong light. They agreed on the WebGPU Shading Language proposed by Google (!) (previously called "Tint"). This is something Google is interested in, as well.
  - kevingadd 7y ago
    It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it. "MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that. NT: nobody is forced to come into Khronos’ IP framework." https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_253vEtKxuUkTGvxpuv8Ac/edit https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...
    - kvark 7y ago

pjmlp 7y ago

Game consoles also don't support Khronos standards. Switch has Vulkan, but it has its own NVN, which is what middleware engines and most Switch titles actually take advantage of. Given that Unity has shared numbers that they are responsible for 50% of the Switch titles, and there is also other middleware, there aren't many titles left.

jfkebwjsbx 7y ago

Vulkan is fine and major games are shipping with it, but you should never expect any 3D API to become standard. Hardware and software vendors will never agree on one, at least for 10 years. Vulkan is supported on macOS through MoltenVK, provided by Khronos.

kvark 7y ago
MoltenVK is not a Khronos product. It's a product of Brenwill Workshop that is one of the many member companies under Khronos. It moved the code under Khronos github. There is quite a few community / other companies contributions. But it's still just a library out there.
- jfkebwjsbx 7y ago
  It is provided by Khronos in the sense that they control the repository and they provide it as a permissive, open, free license, which is the important bit for end users of Vulkan. Whoever develops it is not really important for managers deciding on technologies to use.

fulafel 7y ago

Vulkan is very successful as standards go, most never get near the coverage. But from the early days it was clear that MS and Apple will bet on their own proprietary APIs so the current situation is not news.

pjmlp 7y ago
Missing Sony and Nintendo (Switch main API is NVN) there.
- fulafel 7y ago
  Kind of.. Consoles always use proprietary APIs.

kllrnohj 7y ago

> Wow. Has Vulkan failed as a standard then? I'm interested in this area but came away from the article feeling extremely confused about what the future of portable graphics programming looks like. Other than MacOS/iOS Vulkan's future looks just fine. Windows UWP has failed so incredibly hard that the Windows Store has begun allowing win32 app distribution, so what UWP supports is irrelevant. And Microsoft's game division has even given up on the Windows Store and releases their games on Steam now as well. So UWP is doubly irrelevant currently. Intel's Skylake & newer support Vulkan 1.1 (which are 4 years old now). Not supporting Haswell/Broadwell is annoying as those do support D3D12, but that's the only API gap in Intel's lineup, and that's obviously something that's on a clock to stop mattering at some point. After all, Intel's iGPU primarily matters on laptops, and laptops tend to have a shorter lifespan than desktops as things other than the CPU show their age a lot more quickly. The 50% on Android is also a thing that'll be solved with time. If Khronos doesn't do a new OpenGL ES, then eventually the driver priority on mobile will shift over to Vulkan as that's what benchmarks will begin prioritizing, and that's what sells hardware. Android's latency to supporting something new is incredibly long, but it does also keep moving forwards fairly reliably. So MacOS/iOS is currently the only real question mark on Vulkan's future. But then again, Apple seems to only want Metal on their platform, which doesn't work anywhere else, so no "standard" will matter. You'll be forced onto a compatibility layer of some kind to work on Apple - be it MoltenVK, bgfx/sokol-gfx, or WebGPU. The article dresses up WebGPU as being superior because it's backed by a standard, but that's nonsense. The quality of the implementation is the only thing that matters, and bgfx/sokol-gfx already have quite the head-start there. There's no particular reason to think a couple of people on Firefox are going to be "strictly superior" to the couple of people on bgfx/sokol-gfx. Maybe WebGPU will end up better, in which case great! But it's the same basic thing as what already exists today. It's very firmly in the "compatibility layer" camp here, despite the article trying desperately to dress it up as something else. There's no driver support for it, there's no influence on hardware road-maps, etc... So right now if you could only target a single driver API then Vulkan would cover more platforms than any other driver-native standard. Which is no small feat.

pjmlp 7y ago
Another one that doesn't understand UWP is also the future of Windows APIs. Also as information the WIn32 sandbox model also only allows DirectX, and Microsoft way forward is to support OpenGL on top of DirectX. https://devblogs.microsoft.com/directx/in-the-works-opencl-and-opengl-mapping-layers-to-directx/ https://devblogs.microsoft.com/directx/in-the-works-opencl-a... Expect Vulkan to get a similar treatment, the OpenGL 1.1 ICD driver model won't exist forever. Vulkan on Android is still so meaningless that the dashboard, updated this month, still doesn't show Vulkan support. https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards And then there are the game consoles.