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

Re: [Public WebGL] WebGPU



You cant map Vulkan directly to the web anyways (not in a way that still performs great), we had an in depth discussion here about that (lots of security concerns).
I expect every browser vendor to throw in its own flavor of an WebGL successor and than they will figure out how to make an api that works for everyone.

But Vulkan is the only modern API that is on most platforms, so when i doubt how to implement some feature it should tend towards performing great on an Vulkan backend, when there is no variation where all backend can perform similar great.


Am Mittwoch, 8. Februar 2017 um 00:43 schrieb Joe D Williams:


also look at this called xml3d at xml3d.org
Joe
----- 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
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.

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:



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