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

[Public WebGL] WebVulkan

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:

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