[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebVulkan



On Fri, Aug 5, 2016 at 9:36 AM Florian Bösch <pyalot@gmail.com> wrote:
Has apple committed to not implement Vulkan? It's my understanding Apple is a fully qualified member of Khronos, and if I recall, apple engineers where participating in the formulation of the standard. So the concerns of Apple as a constituent in the standards process should be appropriately addressed, and there shouldn't be any problem with them implementing it.

I'm not going to comment on Khronos politics and I have almost no insight into Apple's future roadmap, but I will say that I would find it fairly shocking if they announced support for Vulkan any time in the next several years.
 
Well, you can't have the benefits of vulkan, if you do not expose the essentials (memory model, command lists, gpu code, etc.).

The memory model Vulkan exposes is simply not something we can do in the browser. That's not a subject that's up for debate, it's a fact. Therefore we can't do a 1:1 Vulkan mapping. Period. I don't feel that the memory model is a feature with the same level of significance as some of the other core concepts of the modern APIs (Command lists, etc.), though, and the web should be able to handle the rest of it just fine.
 
It's my understanding that the Vulkan people where told to "not dumb things down" for the web (by you, or google).

Yes. I told them that.
 
So does this mean you (and the other vendors) made a premeditated decision to abandon Vulkan, before it existed, by refusing to participate in their standardization? And now the web's out of any implementable standard for its use, and no credible plan to have one either, with the only APIs still on the table getting no update henceforth. Whose idea was this?

No, as I recall the context for that statement was that the Vulkan memory model was already pretty well decided on by that point. So when they began asking about whether or not other features should be tweaked with the web in mind my response was "We already know that we can't support the memory model directly, so whatever we eventually expose to the web won't be a 1:1 mapping of the API anyway. As such, please don't dumb it down for our sakes."

I can't really get sucked into a long email thread today, so let me make my position clear and then I'm gonna have to step away for a bit:
  • Vulkan, for all it's complexities, is a great API. So are the other modern graphics APIs! I'm happy they exist.
  • I don't think we need to protect developers from complexity. That's what Three.js and friends are for.
  • I absolutely want to see modern API capabilities make it to the web in some form.
  • That form will never be a 1:1 mapping of Vulkan, even if Apple supported it, because the memory model is not compatible with the web. Full stop.
  • Apple has only committed to Metal and does not comment on future API support as a matter of policy. Since Metal represents a subset of Vulkan's features we have to plan on the web supporting that lowest common denominator of features until Apple states otherwise. This also prevents us from doing a 1:1 Vulkan mapping.
  • Outside of those restrictions, I don't have super strong opinions about the exact form a modern GPU API for the web takes. I personally think it should be modeled after Vulkan but take advantage of being web-centric where reasonable. I'd also be fine with a straight C mapping that has the incompatible bits stripped out. I'd also be fine with something completely new, though I don't think the WebGL working group has the time, energy, or manpower for it.