[hota_mazi]

> 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]

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.

[ioquatix]

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.

[Rusky]

> 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.

Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. Direct3D 12 is at the same level as Vulkan, and I see no reason for the trend of D3D being higher quality than GL to end with Vulkan.

[ioquatix]

Those are pretty subjective assertions. Do you have any evidence to back that up?

[om2]

Do you have any evidence for your claim that Vulkan is best? Metal and D3D 12 are also low-level APIs designed for performance. I've seen no evidence that Vulkan is better on platforms where there are drivers for two different APIs.

[Zandikar]

I think we've all gone a bit off the rails here.

Although you and those you've been discussing this with can't agree on which API is better, there's plenty of evidence that Vulcan, Metal and Dx are all quite good. Why then would we introduce yet another "standard" from scratch, as opposed to working to implement one of the existing ones better across platforms (if the desire is truly to build a universal gfx api)?

[ioquatix]

Well, I guess you know all this but you've asked me to elaborate. So, in terms of compatibility you have:

DX12: Windows only. Metal: macOS/iOS only. Vulkan: cross-platform and cross-vendor. Windows 7/8/10, Android, Linux, MoltenVK supports iOS/macOS with a wrapper. That's a big win for Vulkan IMHO. Valve also agrees with this assertion.

In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel. w.r.t. Vulkan vs DX, from what I've seen it's pretty close, with Vulkan usually coming out ahead by a few performance points but of course it depends a lot on the implementation when it's at that level. Vulkan has been shown to be systematically better than OpenGL.

[Rusky]

There's nothing subjective about it. Take a look at the APIs, they operate at the same level and are designed around the same principles.

As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.

[ioquatix]

> Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality.

I never asserted that. I didn't even qualify what I meant by "BEST". But, let's evaluate the qualities you mention:

> platform support

Vulkan objectively wins here, supporting Windows 7/8/10, Linux, macOS/iOS with a wrapper, Android, etc. Intel has unofficial drivers for their x86 iGPU. Qualcomm recently announced hardware support, along with ARM.

> implementation quality

Vulkan is developed as an open specification, and has a full conformance test for implementations (https://www.khronos.org/vulkan/adopters/). Many aspects of Vulkan are available on GitHub and you can submit PRs. In my experience, drivers on Linux are very good and there are frequent updates. We currently deploy Vulkan at scale in production and haven't had a single issue with reliability.

In addition, the Vulkan validation layers assist with development because they check almost all API invariants and log incorrect usage. This helps to develop programs that work correctly according to the specs.

So, from the driver stack to the client software, Vulkan, IMHO, has a quality and well thought out implementation.

In comparison to DX12, which is developed behind closed doors, we don't know the implementation quality.

I personally haven't heard about any major bugs in Vulkan drivers, but I have seen quite few DX12 demos plagued by bugs. That's my subjective opinion though.

> Direct3D 12 is at the same level as Vulkan

Vulkan is better than DX12 in terms of openness, conformance testing, development tools, platform support, etc. Performance is about the same.

Even Valve agrees: http://www.kitguru.net/components/graphic-cards/anton-shilov...

> OpenGL drivers are inconsistent and buggy.

Agreed :)

[brians]

Vulkan isn't designed for adversarial input. The web language has to be. That alone is likely to require a ground-up redesign.

[boardwaalk]

But OpenGL wasn't either. I'd like to hear concrete examples of how it couldn't be made workable. There are already validation layers that do a pretty good job of checking for bad usage.

Especially since things like NaCl exist(ed) which are inarguably lower level and still safe.

I think it's folly to create a whole new API before evaluating the option of using Vulkan.

[om2]

We did evaluate the option of using Vulkan. So have others. It's not even necessarily off the table, we just don't think it is the best design approach.

If you are very interested in the details of API design choices, then I'd suggest joining the Community Group. Anyone can join!

[pjmlp]

Which is a good example why I don't have any issues with native code on OpenGL ES 3.x mobiles, while Chrome with WebGL is just choppy and dropping frames left and right.

[ThisIs_MyName]

Naw, that's happening because you have a JS thread doing everything. Native code on OpenGL ES is structured very differently.

[ioquatix]

I'd argue that Vulkan IS designed for adversarial input. It deliberately provides a layer mechanism within the driver for validation of function calls. It's trivial to create your own layers and they can be used to validate EVERY entry point into the Vulkan driver.

[Rusky]

Validation layers were created so drivers could remove checks to improve performance. And regardless, properly handling adversarial input is much more involved than just a validation layer.

[ioquatix]

Yes, you are right, but solving the problem of adversarial input is probably NP. A validation layer can intercept every API call and validate it. It's probably the best you can do. The nice thing about it, is that you could actually use it in many different contexts, since, you know, Vulkan makes it a standard feature of the driver.

[ioquatix]

> remove checks to improve performance

In addition to my other points, the Vulkan validation layers are objectively (and IMHO significantly) better for debugging than OpenGL ever was. It's not just to improve performance. The debugging and development experience is significantly improved.

[andreyf]

> One system for everything else and one system for Apple.

This seems to have worked out pretty well for innovation in the mobile OS market, no?

[ioquatix]

Yes, for Apple... For the consumer? I don't think so.

As a consumer, the mobile device market is a walled garden. Are apps compatible between platforms? Do you have control over your hardware? Can you choose what software you run on your own device?

[lapfelix]

> Are apps compatible between platforms

That would be an awful experience for the consumers, UI/UX-wise.

[dkersten]

And yet somehow web apps, each with their very own shirty UI and UX, that looks and works completely different than the platform you use them from, are doing just fine.

[ioquatix]

It wouldn't need to be. The application could have different UI/UX models based on the expectations of the user.

[MBCook]

Consumers don't appear to be bothered by any of those missing freedoms.

[tornadoboy55]

Consumers are bothered by games that get released much later (or not at all) on iOS instead of Android, or the other way around. They're not directly bothered by the cause, but they sure as hell hate the symptoms.

[Teever]

it's hard to be consciously bothered by the lack of something that you've never experienced?

[ioquatix]

That's a faulty generalisation. I am a "consumer" and I'm bothered by it.

[saurik]

Men in America also don't appear to be bothered by having been circumcised, but that is only due to their lack of knowledge and should not be used as evidence that "routine infant circumcision has worked out pretty well for health outcomes in America".

[xenadu02]

Vulkan is not suitable for exposure directly to the web. Full stop.

Therefore your posts are off-topic.

[ioquatix]

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]

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.

[vetinari]

Metal has nice API only if you are using [ObjectiveC|Swift]. The moment you step outside (Rust, Python, ...), you have additional jumps to make.

[toxican]

No, I don't like your opinion, therefore you're off topic and should leave the dicussion.

/s

[sametmax]

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]

> On this one, you are guilty until proven innocent, I'm sorry

Or rather, he's got to refute the null hypothesis.

[om2]

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]

>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".

[hota_mazi]

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.

[threeseed]

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]

> 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]

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.

[modeless]

> 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]

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]

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]

You can simplify the design and reduce bloat if you don't need to address multiple APIs as backend.

[corysama]

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.

[ioquatix]

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.

[shmerl]

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.

[kartan]

> 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]

> 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?

[kabes]

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

[alwillis]

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

[zbuttram]

What people seem to be missing here is that based on available info it seems Microsoft isn't officially supporting Vulkan either. Sure Nvidia and AMD have released drivers for Windows that have Vulkan support, but we're talking about a web standard that would need to be implemented by browser makers and if Microsoft isn't going to use Vulkan, then what do they implement as the backing for this new standard in Edge? Probably DirectX. I think the idea is to sort out an API that would be compatible between all three due to Microsoft and Apple _both_ not wanting to officially support Vulkan over their own platforms in their browsers, regardless of the support at the OS level.

[modeless]

There is a difference between "not officially supporting" Vulkan and completely preventing anyone from providing a Vulkan implementation for your platform. Microsoft allows competing APIs to be integrated into their platform at the driver level. Apple does not.

[cma]

FWIW, Microsoft doesn't allow that on ARM. Only where they have previous antitrust decisions holding them back (x86).

[mrec]

It used to be the case that 3D APIs other than Direct3D couldn't be used from whatever Metro^H Windows Store apps are called this week. Which kind of blocks it at a platform-within-a-platform level.

That may have changed, I dunno.

[vondur]

Could someone not provide Vulkan driver support on the Mac or is it forbidden by Apple to do so?

[mrec]

On Windows, Vulkan support is provided by the IHV graphics drivers from Nvidia, AMD etc. On Mac, Apple themselves ship the drivers (incorporating some portions of IHV code, but ultimately all under Apple's control).

[kitsunesoba]

If you're using a newer Nvidia card, you can download and install much more up to date Mac drivers direct from Nvidia's site. Yes, Apple bundles their own drivers but there's nothing stopping hardware vendors from shipping their own Mac drivers.

[dman]

That still wont change the version of OpenGL supported by the driver as far as I know. If someone has OpenGL 4.5 working on OSX I would be very interested in finding out.

[threeseed]

Apple allows you to provide an alternative API on OSX but not on iOS.

Microsoft is exactly the same. They do not support custom APIs on Windows Mobile AFAIK.

[modeless]

> Apple allows you to provide an alternative API on OSX

I'll need a source for this claim considering that no driver-level Vulkan implementations are available on macOS.

[jolux]

macOS is not popular among gamers? I don't understand what the problem is.

[threeseed]

No. Provide a source that Apple actively prevents it.

Developers can ask users for their admin password, sudo to root and largely do whatever they want including adding kernel extensions and drivers.

[snuxoll]

kext's must be signed now, Apple can freely revoke developer certs and block them if they so desire.

[stymaar]

> sudo to root and largely do whatever they want

Not anymore, even being root doesn't give you total control now[1], and custom kernel extensions are among the things that are prohibited.

This «feature» bas been introduced in El Capitan for «security reason».

[1] System Integrity Protection : System Integrity Protection

[MikusR]

It's a dead platform with no market-share.

[alwillis]

Latest results of the so-called dead platform--"iPhone, Services, Mac and Apple Watch Set All-Time Records"

http://www.apple.com/newsroom/2017/01/apple-reports-record-f...

[douche]

I think the parent claim is that Windows Mobile is a dead plarform, which, it pretty much is, after the nokia fiasco.

[AsyncAwait]

Why are they so hostile to Vulkan and what problems does Vulkan, which is vendor independent and open, have that adding a new API to support to the pile would not?

[shmerl]

No good reason whatsoever.

[MBCook]

Do you have a source for your claim?

[shmerl]

Lack of known good reasons, and their major infamy in perpetuating lock-in in general. They have only themselves to blame for being seen in negative light in this topic by default.

[agmcleod]

That doesn't mean their isn't good reason. I guess they believe they can build a better product by having control over the graphics pipeline. Obviously I cannot say for sure what they think in that regard, but neither can you.

[hota_mazi]

NIAA.

Not Invented At Apple.

[slavik81]

It's not even that. They seem to have abandoned OpenCL as well, and that was invented at Apple.

[shmerl]

It's more like "let's mess everyone else, because we can".

[TazeTSchnitzel]

> Microsoft isn't officially supporting Vulkan either

It's Microsoft's lack of official support for OpenGL on Windows that leads to WebGL implementations using of ANGLE translation to Direct3D, rather than direct OpenGL, right? So I assume we'd have the same situation for a hypothetical WebVulkan. Yes, Vulkan would be available on Windows with the right drivers, but the browsers wouldn't want to use it.

[ioquatix]

I was under the impression that DX wasn't available out of the box either? That you'd need to install suitable drivers and a suitable runtime?

[pjmlp]

Starting with Windows 7, DX became a platform component.

[ioquatix]

Every time I install a game from Steam, it almost always re-installs the DX runtime for that specific game. Is there a reason for that?

[pjmlp]

Also HN seems to forget consoles a lot, which don't support OpenGL (PS3 GL was never used in production), even Nintendo with Switch actually does have another API besides Vulkan(NVN), which devs are more keen in using as it allows even more fine grained control.

[seanmcdirmid]

I'm sure Microsoft has an interest in a 3D web API working on top of D3D, even if NVIDIA and AMDS are putting out Vulkan drivers for the platform (Microsoft is not supporting Vulkan themselves as far as I can tell).

[philippeback]

Anyway, WebVR support is shaky on most browsers, except Firefox / Nightly where it works properly. Get that working before WebGL 2 or whatever. And throw in some support for external GPUs. Moved away from Apple and got myself an Intel NUC i7 w/ Thunderbolt. Better everything in there. Can use external GPUs of all kinds for easy testing. Apple may have had its best quarter ever but is not sexy to me anymore.

Yeah, support Vulkan.

[rehemiau]

> I understand your desire to have Vulkan on Apple platforms, but

There are no 'but's. Just support it and we can have simpler APIs on top of it.

[ionwake]

I agree

[angry-hacker]

While I agree with you, I doubt some random webkit engineer has any power saying what to support.

Apple never listens to anyone, probably some higher exec wants better lock in and that they design the standards. Everyone else keep their mouths shut.

[shmerl]

Then why should W3C accept the views of that higher execs as something useful for the Web? Let them remain Apple only.