18 ms·

We're not complaining, we're explaining the lay of the land. Working on top of all three of these APIs is totally doable and will result in a better API for the

• Nullabillity 10y ago
  > We're not complaining, we're explaining the lay of the land. No, you're stating your own company's ambition.
• kristofferR 10y ago
  Why is DirectX support needed? Isn't Vulkan supported on the same platforms as DirectX anyway?
  • om2 10y ago
    We expect DirectX 12 drivers to be more complete, more performant, and more likely to be available out of the box without a separate install. We expect Windows browsers will want to build on top of DirectX, not Vulkan.
    • ioquatix 10y ago
      Care to back up those assertions with real world evidence?
      • spatulon 10y ago
        Chrome and Firefox felt there were sufficient problems with OpenGL driver availabity that they implemented WebGL using DirectX (via the ANGLE project), despite the more obvious mapping to OpenGL. Is there any reason to believe that, unlike OpenGL, Vulkan drivers will be sufficiently widespread for browser vendors to use it on Windows?
        • ioquatix 10y ago
          That's really fascinating and I didn't know that.
      • mrpippy 10y ago
        Intel has no stated intention of releasing production-quality Vulkan drivers for Windows. Forum statement from August: The current Plan Of Record is that Intel® is not supporting Vulkan on Windows drivers. The drivers that were made available on Developer.com are intended for Vulkan developers. So, it is expected that some Vulkan drivers may not work for end users.
        • ioquatix 10y ago
          A quick google finds an Intel representative providing clarification: https://software.intel.com/en-us/forums/developing-games-and-graphics-on-intel/topic/696380 https://software.intel.com/en-us/forums/developing-games-and... So, they ARE planning full Vulkan support on Intel iGPUs.
          • mrpippy 10y ago
            Good find, it's a shame that the only info is buried in forums and there's no timeline or official statements.
    • cmiles74 10y ago
      I don't see why this would be the case. The vendors (i.e. NVidia) are providing the drivers, I see no reason why they would porposely cripple them.
      • Rusky 10y ago
        Because they have been doing so with OpenGL (an identical situation) for years. Besides, "purposefully cripple" is inaccurate. They just put more effort into Direct3D because there's no reason to support OpenGL as fully.
        • pjmlp 10y ago
          Including the SDKs, AMD and NVidia SDKs for a long time used to have better DirectX tooling than OpenGL.
      • TazeTSchnitzel 10y ago
        It's the current reality with OpenGL on Windows, which is why Windows browsers do not implement WebGL with OpenGL, but rather by translating to Direct3D. Maybe it'll be different for Vulkan, but that would be a surprise.
    • om2 10y ago
      https://www.lunarg.com/faqs/microsoft-support-vulkan/ https://www.lunarg.com/faqs/microsoft-support-vulkan/ Microsoft won't support Vulkan officially, and apps would have to install their own Vulkan drivers.
      • Kubuxu 10y ago
        Not true, Vulcan drivers are included in drivers of the GPU manufacturer.
        • MBCook 10y ago
          No, Nvidia and AMD including Vulcan drivers. Intel isn't and said they don't plan to. Intel has a HUGE market share thanks to integrated graphics. There are other companies too.
          • deleted 10y ago
            [deleted]
          • ioquatix 10y ago
            According to https://software.intel.com/en-us/forums/developing-games-and-graphics-on-intel/topic/696380 https://software.intel.com/en-us/forums/developing-games-and... Intel DOES plan on releasing official production quality drivers at some point.
            • pjmlp 10y ago
              Planning and actually releasing is not the same thing.
              • ioquatix 10y ago
                They HAVE released drivers, I've used them on both Windows and Linux.
                • 10y ago
  • obl 10y ago
    xbox
    • corysama 10y ago
      Concrete example: The PS4 dashboard is actually WebGL via Chromium (https://www.youtube.com/watch?v=sIhtcUvi0BQ&t=55m25s https://www.youtube.com/watch?v=sIhtcUvi0BQ&t=55m25s) I don't think PS4 supports OpenGL, DX or Vulkan. Sony has their own API.
      • snuxoll 10y ago
        Sony has historically supported a variant of OpenGL on the PS3 (in addition to their low level API) - I would be surprised if they don't have one for the PS4.
        • corysama 10y ago
          I worked on PS3. PSGL is the half-truth rumor that refuses to die. It was an experimental GLES1.0 with Nvidia's Cg shaders as an extension. I don't think any games actually used it. https://en.m.wikipedia.org/wiki/PSGL https://en.m.wikipedia.org/wiki/PSGL
        • pjmlp 10y ago
          Besides what corysama replied, there are a few game blogs that described how bad it was, but I cannot link to them as I am behind a proxy currently.
• ChuckMcM 10y ago
  The optics are just really bad. Apple could say "In the mean time we'll support Vulkan" and bam! there is a cross platform solution. Instead you say "We will generously let everyone implement our specifications, we hate to see everyone suffering so, but if everyone else works really hard to do what we say, things will be great!"
  • om2 10y ago
    I don't get what you are suggesting. Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal. We're expecting work on the new web API to be super collaborative, so your framing is uncharitable and incorrect.
    • surrealize 10y ago
      > Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal. The web GPU API and the lower-level API aren't "totally orthogonal" if you're using the Metal shader language in your web GPU API! You're trying get web authors to use (a part of) Metal! It's totally not orthogonal.
      • om2 10y ago
        The Metal Shader Language use in our prototype is totally a placeholder, and the post says so. We expect the standards process to define new source and binary representations, possibly based on Khronos's SPIR-V. The shader language is partly independent of the API though, and we though the API was the interesting thing to prototype, more so than shaders.
        • shmerl 10y ago
          That's already something. But you shouldn't have started with a bad placeholder, waiting for others to criticize and propose replacing it. Start with open languages and technologies right away.
• hota_mazi 10y ago
  > I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU. No, it's not a separate issue. If Apple supported Vulcan, the simple act of proposing this new API as a standard would be laughed out of the room. We can only speculate why Apple won't support Vulcan but I'm going to go with "Prefer a solution they designed themselves over one designed by other parties". Just support Vulkan and let's abandon this silliness, shall we?
  • 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.
• yellowapple 10y ago
  "We're not complaining, we're explaining the lay of the land." The "lay of the land" is that the rest of the world is adopting Vulkan, and therefore the right target for WebGPU is very obviously Vulkan. Even macOS and iOS can (theoretically) support it thanks to MoltenVK [0], and Vulkan is already available on Windows. Trying to wrap all three "major" native APIs is pointless when there's already one that works everywhere and does so reasonably well. [0]: https://moltengl.com/moltenvk/ https://moltengl.com/moltenvk/
  • om2 10y ago
    Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS. We don't think it's right to depend on this even if it's theoretically possible. Likewise for unofficial macOS/iOS drivers.
    • modeless 10y ago
      > Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS. This is not materially different than the situation with OpenGL, and yet I hope you'll agree that basing WebGL on OpenGL was the right decision, rather than inventing a new API based largely on a lower level API proprietary to a single company's platforms.
      • om2 10y ago
        As it happens, OpenGL was so high level that supporting it on top of DirectX was feasible. A number of Windows browsers use the DirectX back end to ANGLE, so users don't have to download OpenGL drives. Unfortunately, that doesn't work as well for Vulkan. Vulkan is the lowest-level of the three APIs, so it's hard to support on top of Metal or DirectX 12.
        • modeless 10y ago
          Since WebGL was released, Microsoft has demonstrated a new willingness to support Web graphics. They joined Khronos, and now ship a WebGL implementation of their own with Windows. I have confidence that if the industry moved toward a WebVulkan standard that this new Microsoft would make platform changes to better support it. Unfortunately I have no such confidence about Apple.
• dman 10y ago
  While I have your attention - what can be done to improve the state of Vulkan and OpenGL on the mac - its the single biggest reason for me to ragequit the OSX platform every time I try to give it a shot.
  • om2 10y ago
    I think you'll want to talk to Apple Developer Relations and see if they can put you in touch with the teams responsible for the GPU-level stuff. We as the browser team can't do much with this feedback.
    • dman 10y ago
      I will try do do this, though I remain sceptical that this will lead to anything. Not supporting external graphics APIs and Apple effectively controlling the drivers seems to be more of a business decision to me than a decision from a tech / dev relations team. Unless someone high up at Apple takes a call that supporting something like Vulkan / OpenGL is the path forward I doubt that this can be solved in a bottom up manner.
    • sipos 10y ago
      It is a serious problem for the future of Apple that they have almost completely lost the support of software developers. It used to be that most software developers had MacBook Pros and, the ones that didn't wished they did. Now software developers are generally buying non-Apple machines and running Linux or Windows. In the short term, this is only a tiny market so the loss of sales is irrelevant but, these people are people that other people look to when they are deciding what to buy and, they are people that develop software that other people use. If there is no decent software for Mac OS because none of the developers who would otherwise write it and release it use it anymore, it will make it much harder for other people to use. Both of these are long term effects and, it is too soon to show their effect on sales but, they are important. Since the release of Mac OS X, it has been an attractive platform for developers but, this has completely changed in the last couple of years and, the only reason to use it now is for iOS development IMHO. Windows has done an awful lot to make itself more attractive to developers recently because they get that it is vital for their future. I hate Windows but, even I have to admit, it has got way way better. Apple's decision to stop producing things like AirPort Extreme or monitors is a stupid decision in the long run too. Even if these don't make any money on their own, part of what makes Apple an attractive platform to people is that they can buy everything from Apple and it work together so, even if these lose a bit of money, they make sense to do. There are an awful lot of reasons to not use Mac OS so, it has to get the reasons to use it right and, it is quickly losing them. Fair enough, most of their money comes from selling iPhones but, sales of these will be seriously harmed in the long run if Apple can't sell other systems that integrate well with them. For example, Microsoft would not have to port or update Office on iOS if there wasn't the possibility that it could weaken their hold on the market if there was a Mac and iOS Office alternative. As it is, they would be insane not to support it on iOS but, without Mac OS and Macs, not doing so would be an option and, it would be a serious selling point for Windows phones. Apple's strategy is seriously broken and, it is going to be a serious problem for the company in the long term if it doesn't fix it soon, if it isn't already too late.
• pharrington 10y ago
  You say Vulkan drivers will, for the forseeable future, be of lower quality than D3D12 drivers and lack official support. Lets assume I blindly accept this faith-based argument. WebGPU than, must be implemented on top of D3D12 and Metal, two already very different APIs. What, than, makes a hypothetical WebVulkan unfeasible in contrast to WebGPU?
  • Rusky 10y ago
    A hypothetical WebVulkan is tied to an API that it is guaranteed to have to translate from. A hypothetical WebGPU could simply be tweaked to better support its multiple target APIs.
    • pharrington 10y ago
      The straightforward translation and predictability of a hypothetical WebVulkan is a strong point in its favor. WebGPU's JavaScript interface can be changed arbitrarily, yes; there is nothing simple about that process.
      • Rusky 10y ago
        Vulkan (and similar APIs) are straightforward as translation targets, not so much as sources.
  • ioquatix 10y ago
    Keep in mind that DX12 doesn't support Windows 7 or 8, so that cuts out a significant portion of the existing market.
    • pjmlp 10y ago
      Still higher than GNU/Linux will ever be.
      • algo_cheese 10y ago
        Not if you take Android into account.
• AsyncAwait 10y ago
  Are you familiar with https://xkcd.com/927 https://xkcd.com/927 ?
• microcolonel 10y ago
  While Microsoft hasn't committed to supporting Vulkan first-party, every major Windows(and macOS) graphics vendor has a compliant Windows Vulkan driver which performs well, most vendors have two or three independent implementations. There are real applications being built today under the assumption that these drivers will continue to work. Also, given that Windows versions other than ten still make up more than half of the PC market, Direct3D 12 is not even an option for most PCs, but Vulkan is. So if we're being honest, it's not really "all three", but Apple vs. literally every other platform. Obviously web applications can't simply be trusted not to crash an exposed driver, but "will result in a better API for the web." is exactly the opposite of what you would expect, given the history of high-level graphics APIs. Any layer of abstraction or heuristic other than those required for security reasons, will ultimately increase the number of implementation inconsistencies, that would be objectively worse. Then consider just the shader language. It would be considerably easier and less error-prone to just support SPIR-V shader programs; but with this there will have to be even more levels of translation, even more places for things to go wrong, and a need to make completely new tooling to generate shader binaries. Furthermore, driver bugs are a given, but Vulkan makes the skills to debug and report driver bugs portable across vendors and operating systems. If I'm an ISV and users are experiencing issues on Metal on OS X on an AMD card, I don't have layers, I largely don't know where to shim the library, and even if I could figure that out, why should I have to figure it out for every system?
  • pjmlp 10y ago
    Sony and Nintendo don't support it as well. Sony doesn't has official plans to ever doing it, as the PS4 APIs are better anyway. Nintendo is only supporting Vulkan for easing bringing in titles to the Switch, because they actually have a better API called NVN that exposes all the graphics hardware features.
  • MrScruff 10y ago
    Intel doesn't have a production quality Vulcan driver as of now. Considering that browsers implemented WebGL on top of DirectX, why would it be any different for a proposed new API? In which case it's reasonable to at least have a discussion about what this new API might look like.
• snarfy 10y ago
  If Vulkan doesn't have enough security features to support the web, you'd think Apple would work with Khronos to get them implemented, instead of rolling their own API. It's yet more 'not invented here syndrome' from Apple.