Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple proposes new web 3D graphics API

webkit.org

Post reply on HN
Print view View original

291–300 of 650 posts

Re: Apple proposes new web 3D graphics API

#291

Post by om2 »

comex wrote: post #213
om2 wrote: post #127

Earlier quoted context omitted.

I don't think browsers will choose to pipe this through Vulkan drivers on Windows (since they are all unofficial and in general don't have as complete coverage) and I don't think they'd choose to use unofficial Vulkan drivers for Apple platforms either, even if they existed. Also, if you compare the sample code in the post with a sample of Vulkan code, I think it will be clear that a literal "WebVulkan" is a road bes…

> Also, if you compare the sample code in the post with a sample of Vulkan code, I think it will be clear that a literal "WebVulkan" is a road best not traveled. Are you sure? Don't forget about WebAssembly… Just as Emscripten currently exposes the original OpenGL ES API as a wrapper for WebGL, for the sake of porting existing C/C++ code that uses it, in the future there will be a desire to port Vulkan renderers to t…

It's likely there will be a need for a C++-level meta-API that can work on top of Vulkan, D3D and Metal. There's already been discussion of making such a thing. It would be nice if that could be exposed to WebAssembly via Emscripten.

Re: Apple proposes new web 3D graphics API

#292

Post by shmerl »

om2 wrote: post #264
surrealize wrote: post #256

Earlier quoted context omitted.

> Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal. The web GPU API and the lower-level API aren't "totally orthogonal" if you're using the Metal shader language in your web GPU API! You're trying get web authors to use (a part of) Metal! It's totally not orthogonal.

The Metal Shader Language use in our prototype is totally a placeholder, and the post says so. We expect the standards process to define new source and binary representations, possibly based on Khronos's SPIR-V. The shader language is partly independent of the API though, and we though the API was the interesting thing to prototype, more so than shaders.

That's already something. But you shouldn't have started with a bad placeholder, waiting for others to criticize and propose replacing it. Start with open languages and technologies right away.

Re: Apple proposes new web 3D graphics API

#293

Post by MBCook »

shmerl wrote: post #187
AsyncAwait wrote: post #175

Earlier quoted context omitted.

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?

No good reason whatsoever.

Do you have a source for your claim?

Re: Apple proposes new web 3D graphics API

#294

Post by shmerl »

MBCook wrote: post #293
shmerl wrote: post #187

Earlier quoted context omitted.

No good reason whatsoever.

Do you have a source for your claim?

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.

Re: Apple proposes new web 3D graphics API

#295

Post by vvanders »

JoshTriplett wrote: post #261
vvanders wrote: post #47

Earlier quoted context omitted.

> Memory bandwidth for your textures, geometry, and other data, quite often. So in other words a GPU bottleneck?

No, a memory bottleneck. (That may be GPU memory or system memory, depending on the architecture of your graphics stack.) That's not the same as a GPU processing bottleneck. You can have a bottleneck in GPU processing, or a bottleneck in getting enough data to the GPU.

Oh I see, we're getting pedantic over semantics.

If your GPU is designed with a small bus between system and GPU memory, that's still a GPU issue. You could make the same argument on the CPU side for caches and DRAM if you want to go that far. I appreciate the education lesson but I think you'll find most graphics programmers will consider it a GPU problem :).

At the end of the day though here's the thing. The intersection of users that have a GPU capable of discrete pipelines, compute shaders and all the other things that make this interesting but won't go through the effort of installing a native app is relatively small. You can't polyfill(otherwise why use the GPU in the first place?) on the users don't have a cutting edge machine so you're going to have a swath of people that your WebApp won't work for. From a value proposition it just doesn't make sense.

Re: Apple proposes new web 3D graphics API

#296

Post by MBCook »

ioquatix wrote: post #208
andreyf wrote: post #152

Earlier quoted context omitted.

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

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?

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

Re: Apple proposes new web 3D graphics API

#297

Post by shmerl »

om2 wrote: post #269
shmerl wrote: post #184

Earlier quoted context omitted.

That's a positive thing, but the whole effort looks like an indirect attempt to push Metal, without making it open itself. What about shader tools and etc.? Are there any open ones for Metal? IMHO if anything like that should be created, it should be based on open APIs.

We think the eventual shader language will not be based on MSL. We need both source and binary formats, and MSL doesn't even have a public binary format at this time. However, if we do end up with something MSL-inspired, the same commitment to follow the Patent Policy would apply.

I think it's a sane expectation to use something that is both open and already available. GLSL, SPIR-V and etc. Using something like MSL won't go anywhere, if there won't be comparable, open and freely available implementation already.

You should take that idea seriously, if you want to view it as a truly collaborative project that invites everybody's participation. I.e using MSL from the start was a major mistake.

Re: Apple proposes new web 3D graphics API

#298

Post by ioquatix »

om2 wrote: post #223
ioquatix wrote: post #204

Earlier quoted context omitted.

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

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.

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.

Re: Apple proposes new web 3D graphics API

#299

Post by om2 »

yazaddaruvala wrote: post #271
om2 wrote: post #102

Earlier quoted context omitted.

If you draw a 2-dimensional chart of low-levelness vs performance, Vulkan, DirectX12 and Metal are all higher performance and lower-level than OpenGL. Metal is a bit higher level than the others and Vulkan is probably the lowest level, but they are about the same performance. WebGPU is a bit closer to the Metal level than the Vulkan level, but it's still lower-level and higher-performance.

Why not write a blog post, comparing a hypothetical: WebMetal vs WebVulkan? Clearly there is a lot of misunderstanding, or at the least passion in regards to Vulkan and Metal. Rather than disregard it as "yeah, we thought about it.. but no". Why not actually help educate us? > "Metal is a bit higher level than the others and Vulkan is probably the lowest level, but they are about the same performance" The above is wh…

I think rough consensus and running code will end up more convincing than the things you suggest. So that's what we're working towards.

Re: Apple proposes new web 3D graphics API

#300

Post by ioquatix »

shmerl wrote: post #290
om2 wrote: post #284

Earlier quoted context omitted.

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 somethin…

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

When you look at the amount of effort that's gone into SPIR-V you'll only have one conclusion to this question.
Post reply on HN