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

Re: [Public WebGL] WebVulkan



We develop a popular 2D HTML5 game engine that currently renders with WebGL, and by the time we get WebGL 2, I feel like for our purposes that will basically be sufficient. Obviously there are other developers out there who need it more, but I am not convinced there's a lot for us to get out of it, which makes me think WebVulkan has a possibly significantly smaller target audience than WebGL, which may be quite a problem considering the enormous amount of work a WebVulkan project represents.

What we would want from WebVulkan is:
- improved performance due to reduced driver overhead
- improved stability due to simpler drivers which are more reliable (less blacklisting/glitches/crashes)
- new features like the ability to use multiple GPUs (either selecting which GPU to avoid crappy laptop integrated GPUs, or using both at once)

I think it is entirely possible to get all these benefits in WebGL if browser makers implement WebGL with a Vulkan backend. There appears to be at least some interest in this in ANGLE: https://bugs.chromium.org/p/angleproject/issues/detail?id=1319

So if browsers implement WebGL with ANGLE, you get some of the benefits, and they can seamlessly fall back to OpenGL/DirectX like they do now if a system doesn't have or support Vulkan. There's no need for any new APIs that way, except perhaps there could be a few new WebGL extensions to expose interesting features.

Regardless of what happens with WebVulkan, I feel like that's an interesting middleground or intermediate step worth thinking about.







On 5 August 2016 at 16:45, Brandon Jones <bajones@google.com> wrote:

I think I share Floh's general thinking on the subject: Anything exposed to the web has to be feasible to implement on all the major platforms (even if they don't pursue it right away.) Vulkan as-is can't work on Apple's platforms because Metal is a more limited API. (Mostly in how it deals with memory allocation, but it also lacks things like tesselation last I looked.) So really we'd want to find an API that represented the common ground between Vulkan and Metal (and D3D12, but that's not far off from Vulkan.)

Metal being the lowest common denominator it would actually not be terrible to do a WebMetal that worked on all the platforms, but that's unlikely to happen politically and the web stakeholders/Khronos aren't likely to be happy modeling after an API that's controlled by a single platform owner.

As such it starts to feel like a new API designed specifically for the web with the purpose of wrapping the modern APIs is the only logical conclusion. You'd lose some of the convenience we've had with WebGL where a lot of existing OpenGL/ES resources were usable with minor tweaks, but at least it would allow the web as a platform to keep pace without sitting around waiting for a "winner" to emerge.


On Fri, Aug 5, 2016, 8:30 AM Floh <floooh@gmail.com> wrote:

Just IMHO: the main problem with Vulkan is not that it's 'hard', but
that it is so verbose (D3D12 has the same problem but is not quite as
bad, Metal is the big exception). It takes 2.5k lines of C code just
to get a triangle on screen in Vulkan :/ The good parts are IMHO:

- SPIR-V
- render passes
- pipeline state objects

Everything that has to do with initialisation and resources (buffers
and textures) is not so good.

There are no modern 'standard' 3D APIs anymore. On Windows, game
development will stay on D3D11 or move to D3D12, on OSX or iOS, Vulkan
is not available, and everybody will be moving to Metal or stay on GL,
game consoles have their own 3D APIs which look radically, or just
slightly different. That leaves Vulkan for Linux and Android.
Personally I don't see such a big problem in introducing a modern Web
3D-API that borrows ideas from Metal, D3D12 and Vulkan, but is not
'compatible' with any of those. I think we are now back at a state
where there is no dominating standard 3D API, the wheel of
reincarnation has turned again and we're in the same state as around
1998. It's a bit of a shame, but that's progress ;)

On Fri, Aug 5, 2016 at 4:22 PM, Steve Baker <steve@sjbaker.org> wrote:
>
> 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
> either.
>
>   -- 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
> -----------------------------------------------------------
>

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