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

Re: [Public WebGL] WebVulkan

I think it's unreasonable to say:

   "Vulkan is hard - so it's not for the web"

There are perfectly capable graphics programmers working on complex
web-based applications who would greatly benefit from having it (I'm one
of them!).

We need game engines like Unity3D to more completely embrace the web - and
as those things transition to using Vulkan under the hood - we'll want
them to generate WebVulkan when you set the target to "Web".

For those who aren't so hard-core, people will make wrappers and
frameworks that are easier.  Also, WebGL isn't likely to "go away" anytime
soon...so that's always that option for those who prefer a gentler
learning curve.  WebGL hasn't obsoleted the canvas API despite a heavy
overlap in capabilities - and I don't think WebVulkan would obsolete WebGL

  -- Steve

Florian Bösch wrote:
> It has been a year since WebVulkan was last discussed on this mailing
> list,
> and I think, now that a specification of Vulkan is out, it's time to
> revisit this.
> *The end of OpenGL/ES*
> Vulkan is the successor to OpenGL and ES. There isn't going to be an
> OpenGL
> 5, and an ES 4 seems doubtful.
> *Vulkan, formerly named the "Next Generation OpenGL Initiative"
>> (glNext),[38][39] is a grounds-up redesign effort to unify OpenGL and
>> OpenGL ES into one common API that will not be backwards compatible with
>> existing OpenGL versions.[40][41][42] The initial version of the API was
>> released on 16 February 2016.*
> Wikipedia <https://en.wikipedia.org/wiki/OpenGL#Vulkan>
> It'll be a while before this becomes a persistent pain for web developers,
> but as the years pass (as they're wont to do), this is going to become a
> bigger burden.
> *The difficulty of Vulkan*
> Vulkan is a very complex API, and it is also largely discoverable and
> extensible. It exposes a wide variety of machine parameters and
> capabilities, and fully expects every developer to intricately be aware of
> those and use them to the best advantage.
> That is to say, it's not a beginners API. Even Khronos advises beginners
> to
> learn OpenGL of some or other variety first, before attempting Vulkan.
> *Many want WebVulkan*
> There does exist a growing clientele for this kind of API (the difficult
> kind) on the web, which is the variety of companies and developers that
> have coalesced around WebGL and are ready to jump into new waters. We're
> all eagerly waiting for WebGL2 (limited as it may be), and we can't wait
> for WebGL the ES 3.1 version, mainly because of compute capabilities.
> *Vulkan or irrelevance*
> Right now the API gap to vulkan from the Web is so large, it might not
> seem
> to matter much to think about it. But if the hardware accelerated web
> intends to stay relevant, Vulkan can't be ignored. It's there, it's
> increasingly going to be what people expect to be able to do, and as the
> Vulkan ecosystem matures, the web will be left behind, again.
> We can't afford to ignore Vulkan. For the hardware accelerated, web, it's
> Vulkan or nothing.
> *Resistance is futile*
> Vulkan isn't just a graphics API. It's an API to build an ecosystem on.
> There is already a wide variety of tools designed to tie into that
> ecosystem (from SPIR-V compilers to abstraction frameworks, debuggers,
> etc.).
> It would be an immense disservice to the Web if we tried to be
> different...
> because reasons. We'd be excluding ourselves from all the efforts that tie
> in with the Vulkan ecosystem.
> It's also extremely doubtful that a Web-only hardware accelerated solution
> could ever gain multi vector traction, as any such effort has persistently
> failed in the past.

 -- Steve

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