6 ms·

I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done. In addition, even on p

by om2 10y ago

I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done. In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance. So either way, we need a cross-platform graphics API. Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs.

modeless 10y ago
> Lots of design work needs to be done. So support Vulkan and then let's do the design work! The choice of underlying system API has effects on the design of the upper layers. Your refusal to support Vulkan is blocking progress.
- andreyf 10y ago
  Why so combative? How is a JavaScript API standard going to benefit from Vulkan support on Apple platforms? More specifically, how will a JS API benefit from being built exclusively for Vulkan, instead of multiple "APIs that have nuanced architectural differences", to borrow Dean's phrase?
  - modeless 10y ago
    To the extent that Vulkan has capabilities or features that don't map perfectly to Metal capabilities and features, native Apple Vulkan support would increase the performance and capabilities, and reduce the complexity and bugginess, of a hypothetical WebVulkan implementation on Apple platforms. And by reducing the compromises that have to be made for platform compatibility it would benefit the API design on all platforms.
  - shmerl 10y ago
    You can simplify the design and reduce bloat if you don't need to address multiple APIs as backend.
    - corysama 10y ago
      To play devil's advocate: Isn't a big focus of web tech the goal of supporting multiple backends for everything? If a new platform wants to support WebGPU but not Vulkan (ex: XBone or PS4) it should be not just theoretically possible, but actively supported by the design of the Web spec.
      - shmerl 10y ago
        Could be, but PS and Xbox don't support Vulkan for the same bad reasons (lock-in), so messing up the spec because of that doesn't sound convincing.
      - ioquatix 10y ago
        Good point. But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. It's already been shown to be possible to do something similar, with MoltenVK. The ball would be in Microsoft's court for this one.
        corysama 10y ago
        "it should be not just theoretically possible, but actively supported by the design of the Web spec."
        douche 10y ago
        > But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. Is this not how Vulkan on Windows works? Given how many OpenGL drivers were just shims over DirectX in the past, I wouldnt be surprised if the same course was charted there.
        shmerl 10y ago
        No, it's pointless to do that. Why all the extra overhead? Vulkan talks directly to the hardware driver.
- deleted 10y ago
  [deleted]
hota_mazi 10y ago
I understand and see some merit to your angle, but at the end of the day, I don't think Apple will be taken seriously in that area until they support Vulkan. Go ahead and do that, then we can talk about going up the stack and judging the API you're proposing (and let's be honest, it's really Metal-for-Javascript). Show some good will.
- deleted 10y ago
  [deleted]
- threeseed 10y ago
  Apple will always be taken seriously since they are not just a major mobile vendor but the only vendor capable of getting any technology widely deployed. Your arguments are very reminiscent of the "Apple must adopt Flash" era. And as we've learn Apple was 100% right to dump that technology as it was simply a poor fit for mobile. I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API.
  - ioquatix 10y ago
    > I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API. And you are qualified to make this assertion because? It would make an awesome JavaScript API. It is well defined, well supported, well documented low level API for graphics. It would easily be exposed within JavaScript.
    - om2 10y ago
      Serious question, have you ever written any nontrivial code using Vulkan? Everyone I know who's ever coded using Vulkan has found it unpleasant, and even Khronos is considering a higher level API (more along the lines of Metal) because Vulkan is just too hard to use.
ioquatix 10y ago
I think what you are going to find is that there is a lot of frustration w.r.t. Apple not supporting Vulkan. One system for everything else and one system for Apple. > I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done. Nothing you assert here is invalid. But, I think you've missed the main point, which is that people don't want an entirely new API, they want the same API across all platforms. Vulkan, exposed directly in JavaScript as much as is feasible (e.g. using an automatic API generation tool) would be awesome. Simply look at how it is possible to cross-compile C/C++ to JavaScript. Now, add in support the Vulkan API. That would be incredible. > In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance. Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST available for 3D rendering on all platforms that support it, unofficial or not. > So either way, we need a cross-platform graphics API. Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs. I think you are missing the point here again. As you say, we need a cross-platform API. But, by that logic, accepting that JavaScript is just another platform, we'd like the SAME API.
- xenadu02 10y ago
  Vulkan is not suitable for exposure directly to the web. Full stop. Therefore your posts are off-topic.
  - ioquatix 10y ago
    Do you even know how Vulkan works? The driver API exposes a layered stack. It's trivial to add a validation layer between the driver and the client. It's SO much better than existing OpenGL or DirectX driver models for this one reason alone.
    - xenadu02 10y ago
      Yes, I do. I'm also slightly familiar with OpenGL and Metal. I think Metal has a better API. You are free to disagree of course.
kabes 10y ago
You wanna focus this discussion on improving the web platform? Great, start with finally shipping WebRTC.
- alwillis 10y ago
  Relax--they’re working on it: https://webkit.org/status/#specification-webrtc https://webkit.org/status/#specification-webrtc
sametmax 10y ago
The persons in favor of Vulkan in this thread don't have to prove their point, you have. Their solution works, is battle tested, is cross platform and almost an industry standard. Unless you backup the Apple proposal with serious evidences such as : - hard metrics on performance benefits, why you need them, and why you can't improve vulkan to get them; - demonstration of blatant issues with the vulkan API and very good solution you can implement and why you can't improve vulkan to get them; - strong evaluation of the benefits your solution provide given the cost it would have compared to adopting vulkan. Then you have no credibility. "Let's fix something that works" is rarely welcomed in programming. Coming from a company that is well known for disrespecting the rest of the world by creating their own island of closed standards and help noone pass the border, it's even worst. On this one, you are guilty until proven innocent, I'm sorry.
- lallysingh 10y ago
  > On this one, you are guilty until proven innocent, I'm sorry Or rather, he's got to refute the null hypothesis.
  - om2 10y ago
    In the case of web standards, the null hypothesis is "no new API" rather than "make something that works only on top of this specific native API". For the web, the latter is not even the default assumption once you've decided something needs to be added. The web is cross-platform by design.
    - mixedCase 10y ago
      >In the case of web standards, the null hypothesis is "no new API" Thanks to Apple's bone-headed decision to not support Vulkan, this is what it has come down for me when it comes to graphical APIs. For me it's either "no new graphical APIs, keep being forced to use OpenGL" or "drop macOS/iOS support".
kartan 10y ago
> I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done. Isn't that what we want? A low-level not opinionated API allows the market and the open source community to create solutions that are subject to competition. If we get an opinionated high level API then we are close to future developments by small agents. Only the big players can decide on the future of 3D graphics on browsers. Why can't Apple just develop their ideal API over Vulkan and let developer decide what to use?
- zanny 10y ago
  > Why can't Apple let developer decide what to use? Wouldn't that be just about the opposite of everything Apple has stood for the last ten years?

by om2 10y ago

modeless 10y ago

> Lots of design work needs to be done. So support Vulkan and then let's do the design work! The choice of underlying system API has effects on the design of the upper layers. Your refusal to support Vulkan is blocking progress.

andreyf 10y ago
Why so combative? How is a JavaScript API standard going to benefit from Vulkan support on Apple platforms? More specifically, how will a JS API benefit from being built exclusively for Vulkan, instead of multiple "APIs that have nuanced architectural differences", to borrow Dean's phrase?
- modeless 10y ago
  To the extent that Vulkan has capabilities or features that don't map perfectly to Metal capabilities and features, native Apple Vulkan support would increase the performance and capabilities, and reduce the complexity and bugginess, of a hypothetical WebVulkan implementation on Apple platforms. And by reducing the compromises that have to be made for platform compatibility it would benefit the API design on all platforms.
- shmerl 10y ago
  You can simplify the design and reduce bloat if you don't need to address multiple APIs as backend.
  - corysama 10y ago
    To play devil's advocate: Isn't a big focus of web tech the goal of supporting multiple backends for everything? If a new platform wants to support WebGPU but not Vulkan (ex: XBone or PS4) it should be not just theoretically possible, but actively supported by the design of the Web spec.
    - shmerl 10y ago
      Could be, but PS and Xbox don't support Vulkan for the same bad reasons (lock-in), so messing up the spec because of that doesn't sound convincing.
    - ioquatix 10y ago
      Good point. But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. It's already been shown to be possible to do something similar, with MoltenVK. The ball would be in Microsoft's court for this one.
      - corysama 10y ago
        "it should be not just theoretically possible, but actively supported by the design of the Web spec."
      - douche 10y ago
        > But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. Is this not how Vulkan on Windows works? Given how many OpenGL drivers were just shims over DirectX in the past, I wouldnt be surprised if the same course was charted there.
        shmerl 10y ago
        No, it's pointless to do that. Why all the extra overhead? Vulkan talks directly to the hardware driver.
deleted 10y ago
[deleted]

hota_mazi 10y ago

I understand and see some merit to your angle, but at the end of the day, I don't think Apple will be taken seriously in that area until they support Vulkan. Go ahead and do that, then we can talk about going up the stack and judging the API you're proposing (and let's be honest, it's really Metal-for-Javascript). Show some good will.

deleted 10y ago
[deleted]
threeseed 10y ago
Apple will always be taken seriously since they are not just a major mobile vendor but the only vendor capable of getting any technology widely deployed. Your arguments are very reminiscent of the "Apple must adopt Flash" era. And as we've learn Apple was 100% right to dump that technology as it was simply a poor fit for mobile. I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API.
- ioquatix 10y ago
  > I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API. And you are qualified to make this assertion because? It would make an awesome JavaScript API. It is well defined, well supported, well documented low level API for graphics. It would easily be exposed within JavaScript.
  - om2 10y ago
    Serious question, have you ever written any nontrivial code using Vulkan? Everyone I know who's ever coded using Vulkan has found it unpleasant, and even Khronos is considering a higher level API (more along the lines of Metal) because Vulkan is just too hard to use.

ioquatix 10y ago

I think what you are going to find is that there is a lot of frustration w.r.t. Apple not supporting Vulkan. One system for everything else and one system for Apple. > I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done. Nothing you assert here is invalid. But, I think you've missed the main point, which is that people don't want an entirely new API, they want the same API across all platforms. Vulkan, exposed directly in JavaScript as much as is feasible (e.g. using an automatic API generation tool) would be awesome. Simply look at how it is possible to cross-compile C/C++ to JavaScript. Now, add in support the Vulkan API. That would be incredible. > In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance. Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST available for 3D rendering on all platforms that support it, unofficial or not. > So either way, we need a cross-platform graphics API. Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs. I think you are missing the point here again. As you say, we need a cross-platform API. But, by that logic, accepting that JavaScript is just another platform, we'd like the SAME API.

xenadu02 10y ago
Vulkan is not suitable for exposure directly to the web. Full stop. Therefore your posts are off-topic.
- ioquatix 10y ago
  Do you even know how Vulkan works? The driver API exposes a layered stack. It's trivial to add a validation layer between the driver and the client. It's SO much better than existing OpenGL or DirectX driver models for this one reason alone.
  - xenadu02 10y ago
    Yes, I do. I'm also slightly familiar with OpenGL and Metal. I think Metal has a better API. You are free to disagree of course.

kabes 10y ago

You wanna focus this discussion on improving the web platform? Great, start with finally shipping WebRTC.

alwillis 10y ago
Relax--they’re working on it: https://webkit.org/status/#specification-webrtc https://webkit.org/status/#specification-webrtc

sametmax 10y ago

The persons in favor of Vulkan in this thread don't have to prove their point, you have. Their solution works, is battle tested, is cross platform and almost an industry standard. Unless you backup the Apple proposal with serious evidences such as : - hard metrics on performance benefits, why you need them, and why you can't improve vulkan to get them; - demonstration of blatant issues with the vulkan API and very good solution you can implement and why you can't improve vulkan to get them; - strong evaluation of the benefits your solution provide given the cost it would have compared to adopting vulkan. Then you have no credibility. "Let's fix something that works" is rarely welcomed in programming. Coming from a company that is well known for disrespecting the rest of the world by creating their own island of closed standards and help noone pass the border, it's even worst. On this one, you are guilty until proven innocent, I'm sorry.

lallysingh 10y ago
> On this one, you are guilty until proven innocent, I'm sorry Or rather, he's got to refute the null hypothesis.
- om2 10y ago
  In the case of web standards, the null hypothesis is "no new API" rather than "make something that works only on top of this specific native API". For the web, the latter is not even the default assumption once you've decided something needs to be added. The web is cross-platform by design.
  - mixedCase 10y ago
    >In the case of web standards, the null hypothesis is "no new API" Thanks to Apple's bone-headed decision to not support Vulkan, this is what it has come down for me when it comes to graphical APIs. For me it's either "no new graphical APIs, keep being forced to use OpenGL" or "drop macOS/iOS support".

kartan 10y ago

> I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done. Isn't that what we want? A low-level not opinionated API allows the market and the open source community to create solutions that are subject to competition. If we get an opinionated high level API then we are close to future developments by small agents. Only the big players can decide on the future of 3D graphics on browsers. Why can't Apple just develop their ideal API over Vulkan and let developer decide what to use?

zanny 10y ago
> Why can't Apple let developer decide what to use? Wouldn't that be just about the opposite of everything Apple has stood for the last ten years?