3 ms·

Sounds like you're focused on what is best for Vulkan, not what is best for the web.

by om2 10y ago

int_19h 10y ago
So far as I can see, the argument he's making is that there's already an actively emerging standard for a 3D API outside of the web, so it would make sense if the web also jumped on the same bandwagon, and we could have a single API everywhere. That makes sense to me. What is special about the web that should exclude it from the single API narrative?
- acqq 10y ago
  The standard in question is still "one of the standards" (and a "me too" one, "the one to end all the previous standards" (1) as far as I see it) not the standard. Remember claims of Flash being the necessary thing on the mobile web, and efficient too? It turned out it was never true. Note there's still no web version of "pure" Vulkan. If it gets to be modified to be less "ridiculously low level" in its web variant, it is anyway going to come closer to the goal Apple proposes for the web. Again, to quote from the Apples proposal: "We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code. Other browser engines have made their own similar prototypes. It will be exciting to collaborate with the community and come up with a great new technology for graphics." --------------- 1) https://xkcd.com/927/ https://xkcd.com/927/
  - int_19h 10y ago
    I don't think the XKCD reference is appropriate. Vulkan is trying to standardize low-level graphics API, which is a niche in which other existing contenders (notably, D3D 12 and Metal) are explicitly platform-specific, and don't even try to be standards outside of their ecosystem. Thus, it fills a useful niche. Yes, it doesn't have a web API. That's because there's no existing web API for low-level graphics of this nature. The question is, what this API should look like. It seems natural to answer this question with, "whatever is the standard outside of the web". Now, there isn't one - but Vulkan is the closest that we have. So, from an engineering perspective, if Apple does want standardization in this area, it would make sense to standardize on Vulkan for both web and non-web applications. Or if they want something else, like e.g. Metal, because Vulkan is somehow inadequate, then they should also submit Metal as a cross-platform standard API outside of the web. Basically, this is trying to solve the standardization problem at a higher level in the stack, while ignoring the same exact problem one layer lower - despite the fact that there's a similar effort ongoing on that layer. Good design would dictate solving it at the lower level first, then building on that for the higher level.
    - MBCook 10y ago
      > Good design would dictate solving it at the lower level first, then building on that for the higher level. I'm guessing the changes that may occur in the lower level aren't big enough to affect the upper level. A lot of people in this discussion seem to just be operating under the assumption that the web API SHOULD be the same as the native API. But if you want a layer of indirection there for any reason (optimization, security, future proofing, whatever) then trying to be a one to one match to a lower level API may not be a good design decision. There are one or two comments by the Apple people here on this point but not many from others: let's just assume the Vulcan is everywhere... would it still makes sense to use that (directly) as a web API? I'm not convinced it would.
      - int_19h 10y ago
        It's not that it should be the same exactly. But I don't see any advantages in it being drastically different. It can be higher-level if needed, but if it's similar both conceptually and in things like semantics and even naming, it's just fewer concepts to hold in your head, and therefore easier to learn. That, to me, is an advantage. Why make stacks more complicated than they need to be?
        K0SM0S 10y ago
        That's pretty much the reason why Google went with Java as the first-class language for Android dev back then: being late to market they wanted the biggest programmer skill subset available, and that was (perhaps still is?) Java. Neverming the fact that it implied running a VM on a phone, tie themselves to Oracle in undesirable (read: licensing) ways, or that it was not the best technical choice: market forces (including dev skillsets in production, down to mass customer adoption) determine the winning strategies in tech. It's all about money, and waiting for hundreds of thousands of devs worldwide to train on a new tech isn't cheap nor easy nor fast. So that's a good real-world example of a successful strategy that didn't make much sense from an engineering standpoint (surprising move by Google of all big tech, given their deep engineering DNA/culture). However it's been stated time and again that most people Apple talked to regarding WebGPU are in agreement that this high-level web API should be able to target pretty much any and all low-level graphics API (DX12, Vulkan, Metal and perhaps others eventually, like NVN or other custom implementations on consoles etc.) So there's that. The reasons are probably as much political as they are technical (nobody probably wants to drop their own horse). It might require more work, and produce lesser results (in terms of performance) but ultimately that may be the way to make WebGPU succeed, regardless of who's proposing it. If we look at the JS situation generally (ref: "what it's like using JS in 2016"), the same could be argued that standards are very much not the norm beyond W3C specs (because TypeScript this, framework that, Babel this, npm that, etc.) Is that a good thing? Some say yes. Is that a bad thing? Some say yes. If we end up having several disparate implementations of WebGPU we know it'll be the same: you have one problem to solve and a solution space that's 10x redundant -but what little idiosyncrasy you find in all this mess is also the reason why everyone and their mother can use JS (different problems meet a bunch of various solutions), it's also probably why the field is so dynamic. The matter of the fact, imho, is that thinking of 3D on the web in 2017 without considering AR/VR from the get go is just a loss of time, and that implies catering to mobile (because the economic revolution of that will be shaped as portable glasses or lenses, not 60-pounds workstation). It's highly likely that these devices will rely on custom/new OS more of an IoT flavor, and in making these the classic vendors (MS, Google) can add whatever drivers WebGPU requires by then. In the meantime, it may be a reason not to lock anyone into any particular low-level API, including OSS Vulkan, simply because we don't know yet what the actual reqs/specs of the next wave of devices will be. Designing WebGPU to be low level API-agnostic is probably safer in this transitional environment. Not advocating anything here, just thinking out loud.
ricardobeat 10y ago
Care to explain? Why is Vulkan not good for the web?
- kshmir 10y ago
  With that logic, we should only have blink, or webkit or gecko, just one engine
  - boardwaalk 10y ago
    You're conflating implementations with APIs. If we had a theoretical "WebVulkan" standard, we'd have implementations in each browsers and along with display drivers underneath.
  - MBCook 10y ago
    But we do have more less one standard: HTML & JS. Blink, WebKit, gecko, etc are implementations that support that standard.
- om2 10y ago
  The best 3D standard for the web is one that can be delivered cross-platform with high performance, high quality, and no need for end-user driver installs. And that can be made safe and secure without losing too much performance. In exploring the issue, we concluded that basing it 100% on Vulkan wasn't the best way to achieve these goals. The response wasn't about how Vulkan was good for the web, but rather about how a different route might help the Vulkan ecosystem. That may or may not be good, but it has nothing to do with what's good for the web.
  - ricardobeat 10y ago
    Don't you agree that the main reason Vulkan is not the best way to achieve those goals is because Microsoft and Apple are refusing to support it? This is circular reasoning.
    - aseipp 10y ago

Sounds like you're focused on what is best for Vulkan, not what is best for the web.

by om2 10y ago

Sounds like you're focused on what is best for Vulkan, not what is best for the web.

So far as I can see, the argument he's making is that there's already an actively emerging standard for a 3D API outside of the web, so it would make sense if the web also jumped on the same bandwagon, and we could have a single API everywhere. That makes sense to me. What is special about the web that should exclude it from the single API narrative?

acqq 10y ago
The standard in question is still "one of the standards" (and a "me too" one, "the one to end all the previous standards" (1) as far as I see it) not the standard. Remember claims of Flash being the necessary thing on the mobile web, and efficient too? It turned out it was never true. Note there's still no web version of "pure" Vulkan. If it gets to be modified to be less "ridiculously low level" in its web variant, it is anyway going to come closer to the goal Apple proposes for the web. Again, to quote from the Apples proposal: "We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code. Other browser engines have made their own similar prototypes. It will be exciting to collaborate with the community and come up with a great new technology for graphics." --------------- 1) https://xkcd.com/927/ https://xkcd.com/927/
- int_19h 10y ago
  I don't think the XKCD reference is appropriate. Vulkan is trying to standardize low-level graphics API, which is a niche in which other existing contenders (notably, D3D 12 and Metal) are explicitly platform-specific, and don't even try to be standards outside of their ecosystem. Thus, it fills a useful niche. Yes, it doesn't have a web API. That's because there's no existing web API for low-level graphics of this nature. The question is, what this API should look like. It seems natural to answer this question with, "whatever is the standard outside of the web". Now, there isn't one - but Vulkan is the closest that we have. So, from an engineering perspective, if Apple does want standardization in this area, it would make sense to standardize on Vulkan for both web and non-web applications. Or if they want something else, like e.g. Metal, because Vulkan is somehow inadequate, then they should also submit Metal as a cross-platform standard API outside of the web. Basically, this is trying to solve the standardization problem at a higher level in the stack, while ignoring the same exact problem one layer lower - despite the fact that there's a similar effort ongoing on that layer. Good design would dictate solving it at the lower level first, then building on that for the higher level.
  - MBCook 10y ago
    > Good design would dictate solving it at the lower level first, then building on that for the higher level. I'm guessing the changes that may occur in the lower level aren't big enough to affect the upper level. A lot of people in this discussion seem to just be operating under the assumption that the web API SHOULD be the same as the native API. But if you want a layer of indirection there for any reason (optimization, security, future proofing, whatever) then trying to be a one to one match to a lower level API may not be a good design decision. There are one or two comments by the Apple people here on this point but not many from others: let's just assume the Vulcan is everywhere... would it still makes sense to use that (directly) as a web API? I'm not convinced it would.
    - int_19h 10y ago
      It's not that it should be the same exactly. But I don't see any advantages in it being drastically different. It can be higher-level if needed, but if it's similar both conceptually and in things like semantics and even naming, it's just fewer concepts to hold in your head, and therefore easier to learn. That, to me, is an advantage. Why make stacks more complicated than they need to be?
      - K0SM0S 10y ago
        That's pretty much the reason why Google went with Java as the first-class language for Android dev back then: being late to market they wanted the biggest programmer skill subset available, and that was (perhaps still is?) Java. Neverming the fact that it implied running a VM on a phone, tie themselves to Oracle in undesirable (read: licensing) ways, or that it was not the best technical choice: market forces (including dev skillsets in production, down to mass customer adoption) determine the winning strategies in tech. It's all about money, and waiting for hundreds of thousands of devs worldwide to train on a new tech isn't cheap nor easy nor fast. So that's a good real-world example of a successful strategy that didn't make much sense from an engineering standpoint (surprising move by Google of all big tech, given their deep engineering DNA/culture). However it's been stated time and again that most people Apple talked to regarding WebGPU are in agreement that this high-level web API should be able to target pretty much any and all low-level graphics API (DX12, Vulkan, Metal and perhaps others eventually, like NVN or other custom implementations on consoles etc.) So there's that. The reasons are probably as much political as they are technical (nobody probably wants to drop their own horse). It might require more work, and produce lesser results (in terms of performance) but ultimately that may be the way to make WebGPU succeed, regardless of who's proposing it. If we look at the JS situation generally (ref: "what it's like using JS in 2016"), the same could be argued that standards are very much not the norm beyond W3C specs (because TypeScript this, framework that, Babel this, npm that, etc.) Is that a good thing? Some say yes. Is that a bad thing? Some say yes. If we end up having several disparate implementations of WebGPU we know it'll be the same: you have one problem to solve and a solution space that's 10x redundant -but what little idiosyncrasy you find in all this mess is also the reason why everyone and their mother can use JS (different problems meet a bunch of various solutions), it's also probably why the field is so dynamic. The matter of the fact, imho, is that thinking of 3D on the web in 2017 without considering AR/VR from the get go is just a loss of time, and that implies catering to mobile (because the economic revolution of that will be shaped as portable glasses or lenses, not 60-pounds workstation). It's highly likely that these devices will rely on custom/new OS more of an IoT flavor, and in making these the classic vendors (MS, Google) can add whatever drivers WebGPU requires by then. In the meantime, it may be a reason not to lock anyone into any particular low-level API, including OSS Vulkan, simply because we don't know yet what the actual reqs/specs of the next wave of devices will be. Designing WebGPU to be low level API-agnostic is probably safer in this transitional environment. Not advocating anything here, just thinking out loud.

ricardobeat 10y ago

Care to explain? Why is Vulkan not good for the web?

kshmir 10y ago
With that logic, we should only have blink, or webkit or gecko, just one engine
- boardwaalk 10y ago
  You're conflating implementations with APIs. If we had a theoretical "WebVulkan" standard, we'd have implementations in each browsers and along with display drivers underneath.
- MBCook 10y ago
  But we do have more less one standard: HTML & JS. Blink, WebKit, gecko, etc are implementations that support that standard.
om2 10y ago
The best 3D standard for the web is one that can be delivered cross-platform with high performance, high quality, and no need for end-user driver installs. And that can be made safe and secure without losing too much performance. In exploring the issue, we concluded that basing it 100% on Vulkan wasn't the best way to achieve these goals. The response wasn't about how Vulkan was good for the web, but rather about how a different route might help the Vulkan ecosystem. That may or may not be good, but it has nothing to do with what's good for the web.
- ricardobeat 10y ago
  Don't you agree that the main reason Vulkan is not the best way to achieve those goals is because Microsoft and Apple are refusing to support it? This is circular reasoning.
  - aseipp 10y ago