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

Re: [Public WebGL] WebVulkan

I am actually wondering what the WebGL community think about SPIR-V ever for current WebGL. There are still improvements required in SPIR-V (fine grain capabilities) but we should expect that SPIR-V modules should be a lot easier to validate than GLSL source.

I think it's too early for WebVulkan. First the ecosystem needs to develop itself (spec, drivers, validation tools) and then before WebVulkan I think web browsers developers should consider Vulkan back-ends for WebGL implementations.


On Sun, Aug 30, 2015 at 10:51 AM, Florian Bösch <pyalot@gmail.com> wrote:
There is still no specification on Vulkan (other than SPIRV). However a few details seem to emerge so I'll briefly guesstimate at how it'll look:
  • multi threaded and multi processed operation
  • low level bytecode to pass to the Vulkan driver to compile to GPU native code (SPIRV)
  • command queue assembly for anything that's not SPIRV
  • low driver overhead (less validation, error checking, state management etc.)

Vulkans utility

I believe there will be substantial challenges to program in Vulkan (and not atop some library and engine). Challenges such as: targeting each specific GPU and its registers, caches (tiers/sizes), execution groups, memory lanes, capabilities/specific instructions, etc. That is to say, it'll be really difficult. I also believe that you will not see any tangible benefit from using Vulkan unless you make good use of the capabilities of each GPU. I don't think that targeting a common subset of functionality common across all GPUs that run Vulkan will be any faster than OpenGL or Direct3D drivers.

With that being said, I also think that Vulkan may deliver astounding performance advantages in specific cases on specific hardware. Because it would allow to squeeze every last bit of performance out of a given GPU.

WebVulkan Critisisim

In various discussions, tweets etc. a few main points of criticism of the idea ov WebVulkan have emerged. I'll briefly summary those positions:
  • You cannot expose Vulkan to the web because it would be unsafe.
  • WebVulkan would deliver no performance advantage because browser/DOM/JS.
  • Vulkan would be far too difficult for people to use on the Web.
I don't agree with any of those statements, but I believe they should be discussed at an appropriate time (when Vulkan is less vapoware and more released specification).

Don't drop the ball on Vulkan

Regardless of difficulties and challenges that go with something like Vulkan and WebVulkan, it is quite clear that Vulkan is meant to run on a wide installation base. And therefore it challenges several other technologies for primacy, namely:
  • OpenCL kernels can be compiled to Vulkan, unlike OpenCL, Vulkan (should) run everywhere easily.
  • A lot of what Cuda does will probably be able to run on Vulkan, and because Vulkan is (in principle) cross platform, should offer a lot more attractive target to program against.
  • Compute Shaders are rather directly in competition with Vulkan
  • OpenGL and Direct3D: Be it either trough direct use, library or engine, both of these "legacy" APIs would be threatened by Vulkan
  • Metal (being iOS only) would have a hard position against something that runs on Android and most other platforms.
Hardware accelerated rendering (and general purpose programming) on the Web is still at a nascent stage. WebGL already has to fend of the (justified) perception of being clunky to work with because it is based on ES 2.0. WebGL 2 will help somewhat, but only somewhat, because the gap to DX12 and OpenGL 4.5 (or even ES 3.1) is still stupendous.

The Web cannot afford to drop the ball on technology that will make DX12/GL4.5/ES3.1 look old and clunky. It will hurt WebGL immesurably if there is no alternative if/once that happens.