Live data from Hacker News

Apple proposes new web 3D graphics API

webkit.org

511–520 of 650 posts

Re: Apple proposes new web 3D graphics API

#511

Earlier quoted context omitted.

> sudo to root and largely do whatever they want Not anymore, even being root doesn't give you total control now[1], and custom kernel extensions are among the things that are prohibited. This «feature» bas been introduced in El Capitan for «security reason». [1] System Integrity Protection : System Integrity Protection

It's easy to disable System Integrity Protection: https://developer.apple.com/library/content/documentation/Se...

Let's not forget the post I was replying to :

> Developers can ask users […]

Have you ever seen anybody shipping software asking their user to do stuff like this to get their software working ?

> Boot to Recovery OS by restarting your machine and holding down the Command and R keys at startup.

Re: Apple proposes new web 3D graphics API

#512

Earlier quoted context omitted.

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

Signing was designed for security purposes which is the only reason where certificate revocation has been used to date. There seems to be a lot of FUD here but without any actual hard examples.

But it prevents doing what you just said above :

> Developers can ask users for their admin password, sudo to root and largely do whatever they want including adding kernel extensions and drivers.

Re: Apple proposes new web 3D graphics API

#513
post #182

Related reading re. Vulkan "What a WebGL2 successor could look like and why it can’t be WebVulkan" - https://floooh.github.io/2016/08/13/webgl-next.html See also the the author's sketch of a next-gen web graphics API on top of WebGL ( https://floooh.github.io/2016/10/24/altai.html ) which is (perhaps unsurprisingl) broadly similar to the sketch given the article (minus command queues, shader libraries, ...).

Everyone here (including me) is upset that Apple are refusing to support Vulkan (or even improve their existing OpenGL support). They haven't even made a public statement. And now we get the news that they are working on another API. It doesn't really matter that the new API is targeting a completely different market to Vulkan. It doesn't really matter that a WebVulkan can't really exist in the first place. It doesn'…

> It doesn't matter if this is probally the correct starting point for a NextGen web graphics API.

Scads of this thread are giving me that signal loud and clear. Not HN at it's best.

Re: Apple proposes new web 3D graphics API

#514

The discussion about Apple not supporting Vulkan is irrelevant because the point of this Webkit proposal is replacing WebGL 2 for web applications, not replacing the sadly fragmented "real" GPU APIs for native applications. As a WebGL replacement and as a 3D API in general, many details of the proposal are strange. >Since we were building on Apple platforms we picked the Metal Shading Language. Mature and portable te…

It's really hard to make the example complex enough for experts without completely losing most people. This is deliberately a simple example.

The string thing is the way enums tend to be done in modern JS APIs. It's not really a bottleneck but if it turned out to be, we'd go a different way.

Re: Apple proposes new web 3D graphics API

#515
I'm not quite sure what Apple were expecting, when they have shown a clear contempt for OpenGL by leaving it at version 4.1 (while everyone else is up to 4.5, even Mesa).

But to the people saying use Vulkan for the web API, that wouldn't be a good idea. Vulkan is a very verbose low level API.

Here[1] is a sample for the most basic of renderers (renders a single triangle). That's 1,000 lines of (commented) code. It's not a good fit for web development. A far better solution would be to evolve the current WebGL API, than shoehorn Vulkan into somewhere it was never meant to be.

[1] https://github.com/SaschaWillems/Vulkan/blob/master/triangle...

Re: Apple proposes new web 3D graphics API

#516

Earlier quoted context omitted.

> sudo to root and largely do whatever they want Not anymore, even being root doesn't give you total control now[1], and custom kernel extensions are among the things that are prohibited. This «feature» bas been introduced in El Capitan for «security reason». [1] System Integrity Protection : System Integrity Protection

It's easy to disable System Integrity Protection: https://developer.apple.com/library/content/documentation/Se...

Sure, and your grandma (=proxy for mainstream user) is surely going to do that.

It's simply a no-go for the mainstream market that expects things to just work.

Re: Apple proposes new web 3D graphics API

#517
post #404
post #365

Earlier quoted context omitted.

Thoroughly solving the security problems will require more eyes on it than just ours. Which is why we're proposing a starting point for a standard, and a process to work on it, not an endpoint.

Thoroughly solving security problems would of course take time. But the parent comment asked a very high level question: How does the security of this new proposal compare to a client-server model such as that of OpenGL? One can simulate one model over another, but in that case, performance can suffer due to overheads. This sort of thing needs to be addressed at the outset, because graphics needs performance and the…

I don't think passing command buffers or structures in memory will be an obstacle to security.

The main security issues will likely be: * Avoiding out of bounds memory reads * Avoiding threadsafety issues * Figuring out lifetime for everything to avoid enabling out of bounds memory reads * Coming up with a safe and validatable shader format (probably a binary one, which makes validation harder) * Checking correctness of things enough to avoid making drivers completely choke

We haven't figured out a lot of these deeper issues. We don't believe the basic model is intrinsically harder to secure than OpenGL though. In fact, OpenGL's complex drivers make security harder, because exploiting the driver means a kernel exploit, so you have to be super paranoid about what you pass to the OpenGL API. Modern graphics APIs have thinner drivers so there's less risk.

Re: Apple proposes new web 3D graphics API

#518
post #62

Earlier quoted context omitted.

That's one of the benefits of designing an API for the web from the get-go, instead of just literally copying an API that's meant to be used from C. It makes for a cleaner and nicer API, even though some lower-level details are exposed.

It's basically a webified Metal API, similar to how WebGL is a webified OpenGL, so I wouldn't say it was designed from the get-go for the web. And as far as I can see from the proposal, WebGPU will still be well usable from C (this is important for talking to it from asm.js / WebAssembly)

It's Metal-inspired, but we tried to use JS API design idioms where possible. It does help that Metal is already an object-oriented design instead of bare functions passing around primitive values and structs.

Re: Apple proposes new web 3D graphics API

#519
post #518

Earlier quoted context omitted.

It's basically a webified Metal API, similar to how WebGL is a webified OpenGL, so I wouldn't say it was designed from the get-go for the web. And as far as I can see from the proposal, WebGPU will still be well usable from C (this is important for talking to it from asm.js / WebAssembly)

It's Metal-inspired, but we tried to use JS API design idioms where possible. It does help that Metal is already an object-oriented design instead of bare functions passing around primitive values and structs.

Ha, sorry I wasn't aware that you're on the WebGPU team when I replied. Please don't forget about us emscripten users, I'd love to give WebGPU a whirl with my C++ mini-3D-framework (http://www.github.com/floooh/oryol), would be interesting how the C/C++ code would differ from the Metal rendering backend, and how performance compares to WebGL on one hand, and Metal / GL on the other.

Re: Apple proposes new web 3D graphics API

#520
post #429

Earlier quoted context omitted.

Windows 8 and older power more than half of Windows PCs, so Direct3D 12 is no more widely deployed than Vulkan.

It is, given that Vulkan only has quality drivers on Android 7, currently 0.7%, and GNU/Linux, currently 2% of the desktop market, as per Steam dashboard. Windows 10 is at around 25% currently.

However, those Windows 7 and 8 machines with AMD and Nvidia GPUs do support Vulkan.
Post reply on HN