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

[om2]

Making a new standard is inevitable. That's not really a choice.

Even if the web platform directly replicated one of the existing APIs, you still have to explain how it binds to JavaScript, as well as memory and GPU resource management details. So bringing a modern graphics API to the web will inevitably create a new standard.

The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.

[shmerl]

> The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.

Besides this approach being supportive of lock-in (of underlying closed APIs like Metal and DX), which is more than questionable, more importantly, what shading language should this Web API use for example?

[bobajeff]

This brings another question. Would it be better given the likely use cases for WebGPU to be designed as a WebAssembly only API?

[staticautomatic]

Why is making a new standard inevitable?

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

[MrScruff]

It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. The discussion is not about what platform will run VR the best.

In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.

[ioquatix]

> It makes no sense to judge the quality of an API by the power of the available hardware it might be running on.

I didn't make any such judgement or even mention VR a single time!

But, looking at the points you've raised, I can say with confidence that Vulkan has been designed, taking into considering these issues.

Vulkan has been carefully engineered from the ground up not to alienate tile-based renderer hardware. So, it's just as suitable for mobile GPUs as desktop GPUs. https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-ma...

As such, it's already supported by many mobile GPU hardware vendors.

> In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.

The GPU in the iPhone 7 uses a custom version of the PowerVR GT7600 GPU. While this is purely speculation, PowerVR does support Vulkan in their other offerings, so it's not that much of a stretch to assume that the hardware is at least capable of it.

NVidia, AMD and Intel power all of Apple's desktop graphics, in addition, they collectively power almost all of Windows and Linux setups too (excepting other mobile and SFF computers)

[foobiekr]

It does, though.

Many times bottlenecks and missteps are not really visible until you can see how your decisions and assumptions encounter reality especially when every other chokepoiht has been removed.

Unless they did their development on Windows or on hardware that has never shipped, Apple isn't really in the position to have evaluated how well Metal works in reality.

I would add that the awkwardness of some "good" API designs is often not revealed until much later (and this is doubly true in the graphics space where there is ample evidence of API choices revealing themselves to be stuck with what turned out to be bad choices some times later).

[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 :)

[hifigi]

I make no argument against what you've said except you used Valve as an "appeal to authority", when they have a vested interest in promoting Vulkan (since SteamOS is based on Linux). So of course they will be persuading developers to use Vulkan over DX12, because it broadens the domain of users who can buy an individual title on Steam.

[ioquatix]

If you look up the endorsement by Valve, it's not just a straight up "Use Vulkan" but a well reasoned set of arguments and case studies by people with a lot of experience. So, this is not an "appeal to authority", but a reference to an existing body of research which supports my assertions.

[Rusky]

By "platform support," I was not referring to the number of platforms supported by the API, but the quality of support for the API provided by the platform(s). Vulkan objectively loses to D3D and Metal here.

We absolutely know the implementation quality of D3D- you don't have to see the source to see its performance, its stability, or its adherence to the spec. On the whole, it's far more consistent and stable than OpenGL and there is no reason to believe Vulkan will change any of that as it uses the same process for specification, development, and deployment.

[ioquatix]

The Vulkan development process is very different from OpenGL. It's a significant improvement so it's not fair to make this judgement. There is significant evidence: The quality of the API, the number of platforms supported within the first 12 months of publication, the availability of source code and documentation on GitHub (including allowing contributions). These are all things which are far better than the equivalent DX model, and also, in comparison, OpenGL.

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

[Rusky]

It's not NP (whatever that means) if you're allowed to change the API instead of just inserting checks at each call.

Besides, Javascript doesn't really need driver support to intercept function calls...

[ioquatix]

NP means non-determinstically polynomial. Validating a GPU shader is undecidable if it include flow control. This is a problem for security.

> if you're allowed to change the API instead of just inserting checks at each call.

The only case is where you simply make the API so limited that it becomes decidable, e.g. remove all backwards flow control and recursion.

> Besides, Javascript doesn't really need driver support to intercept function calls...

Nope, it doesn't, but it makes for a more flexible approach when there is an existing model and implementation (validation layer) which supports this approach.

Improving the quality of the validation layer means that everyone benefits. It's also a massive job and thus, that something already exists, and is standardised, is a good approach.

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

[jaegerpicker]

And the vast majority of webapps are shitty UI/UX from a consumer perspective. Doing just fine with shitty UI/EX, because the platform is crippled does not equal the best solution for the user.

[dkersten]

I completely agree!

Web is convenient in the sense that its easy to get access to a lot of applications and you don't have to install them etc, but the UX often leaves a lot to be desired...

[AlphaSite]

Web apps just have lower standards.

[ioquatix]

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

[yoz-y]

As a developer I see this as a "damned if you do, damned if you don't" issue. Professionally I develop an application with Linux and Windows support, it is a pain and requires a great investment in time. Of course one could use a web technology such as Electron but then you get insulted because of memory hogging, non optimization and disrespect for UX. Developing an iOS and Android application the right way practically takes twice as much time.

As I value user experience and performance above all, for personal projects I prefer to focus on a single platform. And so far, I was also always more happy when using applications from developers that do the same.

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

[criddell]

I don't like it, but I think consumers are pretty accepting of platform exclusives.

[shmerl]

Not really. Gamers don't like exclusives, when they are excluded especially. Why would they like to be excluded?

[MBCook]

If you're a gamer, then you're quite used to this going back all the way to the old Sega vs Nintendo days. It may be annoying but it's something we by and large accept.

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

[MBCook]

There are definitely consumers who care. There are a lot of them here on hacker news.

But that number doesn't seem to be high enough to cause serious sales dips on iOS devices.

I'm not saying the number is 100% of consumers don't care. But it's also pretty clear it's not 70% who do care.

[ioquatix]

So, if you know that, don't say "Consumers don't appear to be bothered by any of those missing freedoms."

Say something like "Apple is still successful despite the lack of freedom" :)

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

[jolux]

That was an interesting non sequitur...

[saurik]

It is not a non sequitur: it is the same argument applied to another situation where people fall into the same trap of lack of knowledge leading to a lack of understanding of their own plight (we might even call it a "blissful ignorance"). The other person who responded to the same parent comment saying "it's hard to be consciously bothered by the lack of something that you've never experienced?" could have been leaving that exact same comment with respect to having an intact foreskin in response to someone claiming the point about circumcision.

Do you really not see the parallels? It seemed like a really great way to point out the fallacy here and demonstrate that "just because people aren't complaining, and even if when asked they are adamant they don't have a problem (an even stronger position than simply that they aren't going out of their way to complain), it clearly doesn't imply they don't have a problem if they haven't been given the necessary knowledge to understand or appreciate the problem" without having to directly engage with the broken logic (which is, of course, impossible).

[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