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

351–360 of 650 posts

Re: Apple proposes new web 3D graphics API

#351

Post by panic »

vilya wrote: post #244

All of you complaining about this proposal not being based on Vulkan seem to be overlooking the fact that Vulkan is actually quite cumbersome to use. Metal, on the other hand, is a really well designed API and in my opinion strikes just the right balance between performance and usability. If it was available for non-Mac platforms too, it would be my first choice of graphics API every time. So for me, a cross platform…

Yeah, have the people arguing for Vulkan on the web actually experienced what it's like to use Vulkan? Here's a small taste: https://renderdoc.org/vulkan-in-30-minutes.html

Re: Apple proposes new web 3D graphics API

#352

Post by saurik »

MBCook wrote: post #306
Kubuxu wrote: post #167

Earlier quoted context omitted.

Not true, Vulcan drivers are included in drivers of the GPU manufacturer.

No, Nvidia and AMD including Vulcan drivers. Intel isn't and said they don't plan to. Intel has a HUGE market share thanks to integrated graphics. There are other companies too.

> https://software.intel.com/en-us/blogs/2016/03/14/new-intel-...

"DATE: March 11, 2016" "-NEW- Intel® Vulkan BETA 15.40.20.4404 Graphics Driver for Windows® 7/8.1/10 [15.40]"

> https://software.intel.com/en-us/blogs/2016/06/29/new-intel-...

"DATE: June 24 2016" "-NEW- Intel® Graphics Test Driver for Windows® 10 and Windows 7/8.1 [15.40.4473]"

https://software.intel.com/en-us/blogs/2016/06/23/intel-open...

"In his blog published on February 16, 2016, Imad Sousou shared that Intel was selected as one of the leading graphics platform suppliers with Vulkan* 1.0 drivers certified by the Khronos Group Consortium."

https://www.youtube.com/watch?v=bsOTVpepS44

"We are demoing Intel’s implementation of the API available on the latest hardware from Intel on 3 major operating systems: Windows, Linux and Android." Intel Engineer: "This really shows the industry is moving towards Vulkan."

https://www.khronos.org/conformance/adopters/conformant-prod...

Intel sure seems to have been making sure all of their chips are now Vulkan capable. All I can find for "they don't plan to" are what seems like rumors on one forum that are spawned by the current drivers being "unsupported" (but given that they are in beta, that makes sense to me: the storyline here is that they were provided for Vulkan developers to start testing their products and likely testing this driver). It really seems like Intel is at worst being "a little slow" to push Vulkan, but they are definitely not unsupportive.

Re: Apple proposes new web 3D graphics API

#353

Post by DLudwig »

om2 wrote: post #291
comex wrote: post #213

Earlier quoted context omitted.

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

But to what degree might this 'meta-API' be different than WebGPU/JS? Might this effort effectively end up creating two, new APIs, each with different vocabularies (one for JS, another for C or C++)?

Re: Apple proposes new web 3D graphics API

#354

Post by JoshTriplett »

vvanders wrote: post #295
JoshTriplett wrote: post #261

Earlier quoted context omitted.

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

The reason for the distinction is that that's one of the specific things Vulkan helps with: keeping the GPU well-fed with work to do. (Also, keep in mind the architectural differences between integrated graphics and discrete graphics.)

You potentially can polyfill, if you have a graphics engine with a higher-performance Vulkan/WebVulkan backend and a lower-performance GL/GLES/WebGL backend. The Vulkan version will make better use of resources and allow you to turn up the quality higher while still hitting the all-important framerate targets.

All the same problems apply just as much if you go native as if you go web. You either have to work with older APIs (often via an engine), or write off older GPUs and some subset of users. Whether you can do that depends on what you're doing.

Re: Apple proposes new web 3D graphics API

#355

Post by ioquatix »

MBCook wrote: post #345
ioquatix wrote: post #323

Earlier quoted context omitted.

That's a faulty generalisation. I am a "consumer" and I'm bothered by it.

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

So, 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" :)

Re: Apple proposes new web 3D graphics API

#356

Post by bobajeff »

om2 wrote: post #284
Zandikar wrote: post #274

Earlier quoted context omitted.

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

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…

This brings another question. Would it be better given the likely use cases for WebGPU to be designed as a WebAssembly only API?

Re: Apple proposes new web 3D graphics API

#357

Post by stephenr »

shmerl wrote: post #35
stupidcar wrote: post #30

Earlier quoted context omitted.

The group's draft charter[1] proposes that contributing organisations would be required to agree to the W3C Community Contributor License Agreement[2], which includes a patent licensing commitment for all essential claims. So, if a specification came out of this, then it would not be patent encumbered; at least not by any patents held by Apple. I'm willing to give Apple the benefit of the doubt on this. Like any big…

> So, if a specification came out of this, then it would not be patent encumbered; at least not by any patents held by Apple. So how come they didn't manage to have the same idea for touch events? > Everyone supporting Vulcan would be nice, but a standardised, patent-free, cross-platform, web-enabled, low-level GPU API would still be a major step forward. I'd say design and its roots matter. If they base it off Metal…

> If Apple want to help, let them base WebGPU on Vulcan.

Literally the whole point of the WG is to design a low level GPU api specifically for the web with security etc in mind (i.e. not just "give javascript direct access to the GPU" like Google's WebUSB and WebBluetooth proposals) that can be backed by whatever GPU library is on the platform: for Window's that's DirectX (do you really want a web app to tell you that you need to update your GPU drivers to get support for Vulkan?), on (mac|tv|i|watchOS) that's Metal, on Linux its.. um.. Vulkan I guess or perhaps OpenGL or who knows what else people decide to install?

Re: Apple proposes new web 3D graphics API

#358

Post by paulddraper »

saurik wrote: post #327
paulddraper wrote: post #231

Earlier quoted context omitted.

Firefox was just the opposite on Indexed DB/WebSQL. History written by the victors.

WebSQL was never going to be picked up by Microsoft either: it was a WebKit-only concept that was doomed from the start.

Opera might disagree.

Re: Apple proposes new web 3D graphics API

#359

Post by normalperson123 »

what a coincidence. just the other day i kind of stumbled across the situation with apple and vulkan and was totally mystified. why would apple, who was a supporter of vulkan, not implement drivers for it, and in effect block the possibility for a universal webvulkan standard and all the glorious benefits of it? lo there was a reason! i have to say that i think apple is being a complete dunce. so they refuse to implement vulkan drivers, or even modern gl drivers, and now their next move is to create yet another graphics api? the success of which would depend on everyone else supporting it when apple wouldnt support stuff? apple has enough money (tax dodgers) to support other standards. they should probably do that and do it well before telling everyone else what to do. /rant

Re: Apple proposes new web 3D graphics API

#360

Post by sowbug »

I find Apple Inc. as annoying as the next geek does, but I agree with them here. It's rarely -- possibly never -- a good idea to tie a web API design to a desktop API (see, e.g., WebSQL). The web platform is too different from desktop platforms for any nontrivial functionality to port slavishly to it.

Moreover, web standards last much longer than typical desktop APIs. Do we really want to take a snapshot of Vulkan's API today and live with it on the web for the next couple decades, as desktop Vulkan continues to evolve?

It's better to build a web API that is fluent for its target platform, taking care that it's possible to implement it performantly on foreseeable host platforms.

Let Apple lock themselves in if they want. Don't lock the web into Vulkan.

Post reply on HN