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

Re: [Public WebGL] WebVulkan



Given the importance of the web - I'd really hope that the needs for
WebVulkan would be high on the list of priorities for the main Vulkan
group.

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!

  -- Steve


Christophe Riccio wrote:
> 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.
>
> Thanks,
> Christophe
>
> 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.*
>>
>


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