[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGPU



On Tue, Feb 7, 2017 at 3:28 PM, Florian Bösch <pyalot@gmail.com> wrote:
Basically it's WebMetal. While I find the API at a glance reasonable enough, I find myself disagreeing with some things.

 With a broader landscape of graphics technologies, following one specific API like OpenGL is no longer possible.

This assessment by the blog post includes GL, ES and Vulkan as "not possible to follow". It's my understanding that Vulkan was supposed to be the new cross platform API allowing exposure of nuanced differences in hardware and obtain the benefits of less overhead and talking to the hardware more directly. Apparently Apple doesn't think so. I can't blame them on that count, Vulkan is a very unwieldy API, and Metal isn't, but still...

The W3C provides the Community Group platform for exactly this situation. The “GPU for the Web” Community Group is now open for membership.

Also instead of creating a Khronos group/standard, Apple has decided to create a W3C group for this purpose. I'm noticing a theme here, and the theme seems to be that Apple doesn't want anything todo with what Khronos does.

I find this troubling. Now there seems to be a proliferation of multiple competing standards for the future of how to talk to GPUs (and on the Web), and one of them just so happens to be custom tailored exactly to what hardware Apple produces. What a coincidence.

I can't comment on the choice of venue. Khronos has been a supportive home for the WebGL API for many years, and I'm grateful to the organization and all of its members. I hope, and am optimistic, that it will be possible to make good progress on this necessary step -- abstracting over the lower-level, pre-validated and more explicit graphics APIs -- at the W3C.

A couple of key sentences from Apple's blog post:

"We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code. Other browser engines have made their own similar prototypes."

It's in all browsers' best interests to produce one standard API that works well on all platforms. In coming weeks we'll see more analyses of the low-level APIs and how to abstract well over them.

Developing a solid standard around these low-level APIs will take time. So, everyone, please take advantage of this time to upgrade your code to use the new features in WebGL 2.0. :)

-Ken



We anticipated the situation of next-generation graphics APIs a few years ago and started prototyping in WebKit, to validate that we could expose a very low-level GPU API to the Web, and still get worthwhile performance improvements.

Yes I'm sure the performance results where promising for the API that you designed for your hardware and implemented natively by your OS/drivers. But where they promising when that API gets transpiled/translated to a different backend like Direct3D or Vulkan? Or does it just happen to perform not so great in those kinds of situations, where anybody who doesn't natively implement Metal is at a disadvantage?

 On the whole I'm not thoroughly confused. I'd appreciate other vendors chipping in if they don't see things as gloomy as I do. I'd very much could use some assuaging right about now that we won't be re-starting the 3D API wars all over again for the Web.

On Tue, Feb 7, 2017 at 11:32 PM, Andrew <grizzly33@gmail.com> wrote:
Just found this, and since there seems to be no thread about it yet, I wonder what everyone here thinks about it:

https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/