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

41–50 of 650 posts

Re: Apple proposes new web 3D graphics API

#41

Post by om2 »

NickGerleman wrote: post #9

"The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms." So Apple, the only company not supporting Vulkan on their platforms, is complaining that there isn't a cross-platform solution?

We're not complaining, we're explaining the lay of the land. Working on top of all three of these APIs is totally doable and will result in a better API for the web.

Things worth noting: - We believe other browser vendors agree with us that the web API should work on all three of the major native APIs. - The web has security requirements which force us to go a bit higher-level than Vulkan anyway.

I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU.

Re: Apple proposes new web 3D graphics API

#42

Post by sova »

Go for it! I would love to see more focus on browser-based what-the-future-of-code-may-look-like. That said, I don't think that 3D interfaces are the only kinds that need good language / representation. Not that the rules should be really rigid, but I think that if we pursue the notion of reversely symmetric UI-languages we can make a lot of progress. Imagine that you have a 3D scene, what is the minimal language you need to describe it? How can we make it so that language/code is not only minimised but extensible? We must strike a balance.

I would like to have such simplicity in a potential language that when I see a scene in my minds' eye, it's really easy to transfer to the digital realm. I think the simplicity of representation is key.

Being a web dev on my own hours for the past several years now has given me a pretty solid grip of all the needs of an interactive application, and I can say that there has to be some way for users to easily interact and offer all the possible inlets for the information. Starting a 3D-internet movement might require rethinking the inputs. Won't we just use holo-wands to navigate vast swathes of data rapidly? Run through this field of data sheets...

So yeah, rethinking the medium will naturally come up as a question in conversations around this, and I think that it's simply a matter of keeping "user input" as straightforward and easy as possible, in the local _and_ distributed sense. With that as a foundational block, the rest of the 3D scene can start to make sense.

Re: Apple proposes new web 3D graphics API

#45

Post by eridius »

AndrewKemendo wrote: post #17

Biggest questions I have are: 1. What is the (proposed) backward compatibility across devices? 2.Given that it is structured for Metal shaders, what are the plans for other, non-apple devices? I see the hat tip to D3D and Vulkan, but I assume they need to get on board first - any early takers? After all common standard means cross-platform hardware support, something Apple has never really embraced.

The blog post explicitly says that they think that discussion around the shading language to be "one of the most fun parts of the standardization process" (i.e. most contentious), and they explicitly said they're deferring the issue of shading language and just accepting an existing language "for now", and that they picked the Metal Shading Language because the authors of the proposal here are using Apple platforms. I think the implication is clear that they don't expect the Metal Shading Language to actually be the final shading language after the proposal has gone through the standardization process.

Re: Apple proposes new web 3D graphics API

#46

Post by revelation »

Benjamin_Dobell wrote: post #8

I feel like Apple are just trying to get in early with a proposal so they don't get forced into supporting Vulkan (and wasting all that effort on Metal). Mind you, it does at least look like they're trying not to be jerks about it (even if the motivation is somewhat selfish). They specifically mention the competition to Metal and how "webgpu" is ideally an abstraction that'll sit on-top of Vulkan, Metal and Direct3D…

It is not "seen as non-ideal", it was the very point of existence for all of those standards. Graphic apis had become a leaking abstraction of non-standardized driver behavior with single-digit FPS lurking around every non-popular feature corner.

It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks.

Re: Apple proposes new web 3D graphics API

#47

Post by vvanders »

JoshTriplett wrote: post #38
vvanders wrote: post #32

Earlier quoted context omitted.

As soon as you clear up that GPU bottleneck guess what's going to be your next one? (Here's a hint, it's the thing that's dispatching to your GPU). Another aspect that scares me about this is the security implications of exposing compute to the browser. Esp when you start talking about unified memory architectures. There's been more than a few exploits from a clever soul calling glReadPixels in the right circumstance…

> As soon as you clear up that GPU bottleneck guess what's going to be your next one? Memory bandwidth for your textures, geometry, and other data, quite often. Or nothing at all, if you can successfully reach your desired target framerate. But if CPU turns out to be an issue, that's what WebAssembly is for.

> Memory bandwidth for your textures, geometry, and other data, quite often.

So in other words a GPU bottleneck?

Re: Apple proposes new web 3D graphics API

#48

Post by eridius »

DigitalSea wrote: post #29

Another anti-competitive initiative disguised as "Apple-led innovation" - maybe Apple should get on board with Vulkan, everyone else has, instead of complaining about there being no cross-platform solutions.

How is this anti-competitive? They're explicitly trying to create a cross-platform JavaScript API for graphics, one that can be built on top of whatever platform-specific low-level APIs that exist. This seems to be the exact opposite of anti-competitive.

Re: Apple proposes new web 3D graphics API

#49

Post by Nullabillity »

om2 wrote: post #41
NickGerleman wrote: post #9

"The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms." So Apple, the only company not supporting Vulkan on their platforms, is complaining that there isn't a cross-platform solution?

We're not complaining, we're explaining the lay of the land. Working on top of all three of these APIs is totally doable and will result in a better API for the web. Things worth noting: - We believe other browser vendors agree with us that the web API should work on all three of the major native APIs. - The web has security requirements which force us to go a bit higher-level than Vulkan anyway. I understand your de…

> We're not complaining, we're explaining the lay of the land.

No, you're stating your own company's ambition.

Re: Apple proposes new web 3D graphics API

#50

Post by om2 »

Benjamin_Dobell wrote: post #8

I feel like Apple are just trying to get in early with a proposal so they don't get forced into supporting Vulkan (and wasting all that effort on Metal). Mind you, it does at least look like they're trying not to be jerks about it (even if the motivation is somewhat selfish). They specifically mention the competition to Metal and how "webgpu" is ideally an abstraction that'll sit on-top of Vulkan, Metal and Direct3D…

Is that really a "just" or is it the right thing to do? Working on top of all the major APIs is the right thing for the web.

We've discussed our proposal a lot with key players in this space (including other browsers, GPU vendors, relevant ISVs) and we're pretty sure a cross-API abstraction is the way to go.

Some even want to build a form of cross-API abstraction at the native C/C++ level.

Post reply on HN