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

Re: [Public WebGL] WebGPU

It appears that the HN crowd is calling out apple for being the only platform that is not supporting Vulkan. And therefore this not being webVulkan.


This does not seem to be a positive reception from PR stand point.

On Tue, Feb 7, 2017 at 3:43 PM, Joe D Williams <joedwil@earthlink.net> wrote:

also look at this called xml3d at xml3d.org
----- Original Message ----- From: "Florian Bösch" <pyalot@gmail.com>
To: "Andrew" <grizzly33@gmail.com>
Cc: "public webgl" <public_webgl@khronos.org>
Sent: Tuesday, February 07, 2017 3:28 PM
Subject: Re: [Public WebGL] WebGPU

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

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

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.

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

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:


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl