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

Re: [Public WebGL] WebVulkan



My ideal 'next-gen-web-3d-api' would essentially look like this, I
think I already wrote something similar in the past here:

- SPIR-V bytecode for shaders with an optional GLSL frontend (which
could probably be implemented in a JS module?)

- simple setup in one call similar to WebGL (but probably with more
initialization options)

- pipeline-state-objects which bundle all the render states, shader,
vertex layout; these are nearly the same across Vulkan, D3D12, Metal
and even D3D11, PSOs would be the main advantage versus WebGL IMHO
since dozen of granular render state calls would be bundled into a
single call

- D3D11/Metal-style managed resources (buffers and textures, but I
don't need to care about the complicated details that D3D12 and Vulkan
exposed, wouldn't even be possible in browsers because e.g. Chrome has
the renderer in a different process)

- ability to record shader uniform updates for an entire frame into
one big buffer buffer similar to how Metal allows it.

- Vulkan-like render pass abstraction, very useful for tiled GPUs

Most of this could even be mapped back to GLES2, and it might even be
faster then classic WebGL because the resulting rendering code would
have a lot less calls into the 3D API (just think about how much is
saved by not having granular render state and vertex attribute
updates).

For the more advanced features, like compute, tesselation, features
that are exposed to shaders I guess a common subset across 3D APIs
would have to be found.

Also slightly unrelated: lets not forget that even very expert
graphics programmers have a lot trouble beating D3D11 or a good OpenGL
driver when writing real-world Vulkan or D3D12 code (meaning: games).
And even with the perfect code it only makes sense if an application
is CPU-limited in the driver-layer, all other scenarios won't benefit
from Vulkan or D3D12.

But simplifying(!) and modernizing the API is a worthy goal IMHO.

On Fri, Aug 5, 2016 at 6:06 PM, Ashley Gullen <ashley@scirra.com> wrote:
> 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
>>> -----------------------------------------------------------
>>>
>

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