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.

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!

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.

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

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.

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.

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.

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

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.

I know what NP means, my parenthetical implied that you used it in a way that made no sense.

Undecidable control flow does not inherently make validation undecidable, or NP, or anything else really. The key (like with any sort of type system) is that it's okay to reject some subset of valid programs in exchange for easy enforcement of the invariants you need.

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