[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebVulkan
You should definitely have at look at Metal for inspiration what
modern Web 3D API could look like. In my opinion the new resource
management (or rather lack of) in Vulkan and D3D12 is way to
complicated and low level for a web API and (IMHO) won't bring any
benefits in a safe browser environment. Metal on the other hand can
absolutely be used without an engine-layer.
Metal has simple D3D11-style resource binding (you only need to make
sure to not overwrite data that's not currently in use), combined with
modern concepts like pre-compiled pipeline-state-objects and
free-threaded command lists.
In my opinion, the 'perfect' modern Web 3D API would look like this:
- coarse, pre-compiled state (e.g. pipeline-state-objects)
- command lists which can also be built on WebWorker threads
- SPIR-V shader byte code
- more or less traditional resource management, D3D11 style
(MAP_DISCARD buffer renaming under the hood, resources remain live as
long as used by the GPU).
Trying to create a direct copy of Vulkan or D3D12 on the Web doesn't
make much sense IMHO, I'd rather see a cleaned up WebGL3/OpenGLES4
with pipeline-state-objects and SPIR-V shaders.
On Mon, Aug 31, 2015 at 2:44 AM, Brandon Jones <email@example.com> wrote:
> The WebGL working group has given input to Vulkan pretty early on in the
> process, but aside from a couple of broad requests the general message was
> "Don't dumb anything down on our account."
> We're too deep into WebGL 2 to be distracted much with what WebGL Next looks
> like, but certainly the idea of basing it on next gen APIs has been
> discussed. Here's the thing: it will probably be impractical to try and
> expose a ~1:1 mapping for Vulkan and friends on the web like we did with
> WebGL and GLES2/3. I'm expecting that anything we do build will require some
> pretty heavy shimming if you wanted to do WebAssembly builds targeting it
> with Vulkan/DX12 C++ code.
> As such my gut feeling is that instead of trying to mimic any particular
> next gen API on the web we should probably build something that feels
> web-native (Vulkan definitely does not!) while still retaining the best
> ideas from the current crop of APIs. Of course that puts a tremendous amount
> of spec effort on the WebGL working group, and I'm not sure we're currently
> equipped to handle that.
> But as I said, the current focus is WebGL 2. It's a near-term, very
> realistic goal that will open up significant new GPU capabilities for
> developers. Avoiding that work in favor of focusing on a next gen API would
> be doing the WebGL community a huge disservice.
> On Sun, Aug 30, 2015, 11:51 AM Florian Bösch <firstname.lastname@example.org> wrote:
>> On Sun, Aug 30, 2015 at 8:44 PM, Steve Baker <email@example.com> wrote:
>>> We've felt the pain of trying to bolt a proper security structure on top
>>> of a pre-existing OpenGL API...let's not make that mistake again!
>>> Waiting until the Vulkan spec is cast in concrete before we start to
>>> consider the web implications would be to repeat history here!
>> That's quite a good point. Even though WebVulkan may be far in the future,
>> it'd be helpful if the Vulkan WG took input on security from the WebGL WG so
>> that an eventual integration with the web does not become a massive pain in
>> the posterior. Actually, given the rather dismal state of security of native
>> apps on desktops overall, considering security implications of Vulkan
>> doesn't just benefit the Web...
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: