8 ms·
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 A
by ioquatix 10y ago
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.
- xenadu02 10y agoVulkan is not suitable for exposure directly to the web. Full stop. Therefore your posts are off-topic.
- ioquatix 10y agoDo 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 10y agoYes, 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.
- andreyf 10y ago> 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 10y agoYes, 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?
- y_u_no_rust 10y agoYeah more then I could 14 years ago
- MBCook 10y agoConsumers don't appear to be bothered by any of those missing freedoms.
- ioquatix 10y agoThat's a faulty generalisation. I am a "consumer" and I'm bothered by it.
- MBCook 10y agoThere 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 10y agoSo, 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" :)
- brians 10y agoVulkan isn't designed for adversarial input. The web language has to be. That alone is likely to require a ground-up redesign.
- boardwaalk 10y agoBut 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 10y agoWe 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 10y agoWhich 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 10y agoNaw, that's happening because you have a JS thread doing everything. Native code on OpenGL ES is structured very differently.
- ioquatix 10y agoI'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 10y ago> 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 10y agoThose are pretty subjective assertions. Do you have any evidence to back that up?
- om2 10y agoDo 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 10y agoI 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 10y agoMaking 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.