Live data from Hacker News

Apple proposes new web 3D graphics API

webkit.org

281–290 of 650 posts

Re: Apple proposes new web 3D graphics API

#281
post #73

Earlier quoted context omitted.

The optics are just really bad. Apple could say "In the mean time we'll support Vulkan" and bam! there is a cross platform solution. Instead you say "We will generously let everyone implement our specifications, we hate to see everyone suffering so, but if everyone else works really hard to do what we say, things will be great!"

I don't get what you are suggesting. Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal. We're expecting work on the new web API to be super collaborative, so your framing is uncharitable and incorrect.

Not trying to be uncharitable here, I'm just sharing how it looks to someone driving by.

That doc says:

"It[WebGL] was based on OpenGL ES, a cross-platform API for graphics targeted at embedded systems. This was the right starting place, because it made it possible to implement the same API in all browsers easily, especially since most browser engines were running on systems that had support for OpenGL."

And then it says later this:

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

And one imagines you could put up a big chart and have all the platforms as the columns and each technology as the row, and show all of the gaps. But the consensus is that Vulkan would show up on all the platforms except Apple's. So one might ask "well if you put Vulkan on your platforms, then you would be back to the WebGL situation where you had stuff that ran on all platforms and you could work on a Web API to that code.

So "optically" which is to say, to a casual observer, it seems like Apple is saying everyone put this new thing on your platform as this web api we're working on will talk to it.

I understand that you just want the best experience possible given the advances that have been made in GPUs over the last decade.

Re: Apple proposes new web 3D graphics API

#282

Earlier quoted context omitted.

Like?

WebM and WebP support

Not supporting WebP would be a mercy. They just let the Xvid guy working at Google release the first version of their codec as an image format, and now they can't update it.

I recommend supporting ffv1 or HEVC Still Profile (where patents don't apply).

Re: Apple proposes new web 3D graphics API

#283

Earlier quoted context omitted.

No. Provide a source that Apple actively prevents it. Developers can ask users for their admin password, sudo to root and largely do whatever they want including adding kernel extensions and drivers.

kext's must be signed now, Apple can freely revoke developer certs and block them if they so desire.

Having a technical means to make distribution of a driver awkward is quite a few steps short of forbidding it.

Re: Apple proposes new web 3D graphics API

#284
post #223

Earlier quoted context omitted.

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.

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 something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.

Re: Apple proposes new web 3D graphics API

#285
post #278
post #216

Earlier quoted context omitted.

Could someone not provide Vulkan driver support on the Mac or is it forbidden by Apple to do so?

On Windows, Vulkan support is provided by the IHV graphics drivers from Nvidia, AMD etc. On Mac, Apple themselves ship the drivers (incorporating some portions of IHV code, but ultimately all under Apple's control).

If you're using a newer Nvidia card, you can download and install much more up to date Mac drivers direct from Nvidia's site. Yes, Apple bundles their own drivers but there's nothing stopping hardware vendors from shipping their own Mac drivers.

Re: Apple proposes new web 3D graphics API

#286

Earlier quoted context omitted.

> As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway. As someone who also spends a lot of time in the GPU space, I really want something newer than WebGL. WebGL is not good enough.

There's plenty of stuff if you want to go native or are you just talking web technologies? FWIW there's tons of things build on OpenGL ES 2(all of Android for instance). If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc).

> If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc).

You say that like it's a good thing! The point of WebGL is to put that pain on the browser vendor.

OpenGL ES 2 is incredibly limited, as you know. Yeah, you can do a lot with it, but there's a ton of stuff you can't do (tessellation, compute, image load/store, heck, even unbounded loops in shaders). Why should the Web be limited to that?

Re: Apple proposes new web 3D graphics API

#287
post #278

Earlier quoted context omitted.

On Windows, Vulkan support is provided by the IHV graphics drivers from Nvidia, AMD etc. On Mac, Apple themselves ship the drivers (incorporating some portions of IHV code, but ultimately all under Apple's control).

If you're using a newer Nvidia card, you can download and install much more up to date Mac drivers direct from Nvidia's site. Yes, Apple bundles their own drivers but there's nothing stopping hardware vendors from shipping their own Mac drivers.

That still wont change the version of OpenGL supported by the driver as far as I know. If someone has OpenGL 4.5 working on OSX I would be very interested in finding out.

Re: Apple proposes new web 3D graphics API

#289

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

Why is Vulcan so magical that everyone in this thread thinks it is the only choice?

It has three things going for it:

1) It's currently the fastest (unlike DirectX)

2) It's not controlled by an OS company (unlike DirectX and Metal)

3) It reflects recent developer and hardware concerns (unlike OpenGL)

Re: Apple proposes new web 3D graphics API

#290
post #284

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…

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

Post reply on HN