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

[Public WebGL] WebGL/WebGPU Considerations



All,

I've been following the WebGPU proposals and commentary closely
(particularly https://github.com/gpuweb/gpuweb/issues/2 and
https://github.com/gpuweb/admin/issues/1), and it seems WebGPU aims to
target several concerns which are primarily performance-based:
1. Low level access to the GPU
2. Functionality that doesn't currently exist in WebGL 2, possibly
including command queues, SPIR-V support, multi-threading by sharing
contexts across web workers, improved async support, etc.
3. More object-oriented API or builder-like functionality to improve
efficiency in some way (i.e. decrease precondition checks)

Numerous security concerns have been raised about point 1 in
considerations whether to map an API such as Vulkan directly (i.e.
similar to the mapBuffer[Range] security issue with WebGL). If the API
cannot be that low level, it would likely operate at a level closer to
the existing WebGL API.

Based on the above, I have been wondering about the future plans for
WebGL. Instead of creating a new API for WebGPU, is it feasible to
incorporate some of the proposed WebGPU concepts into WebGL to improve
performance? A complete list of proposed WebGPU functionality has not
been defined yet, but I expect this to be decided soon after a number
of WebGPU proposals have been submitted.

For example, where feasible, it may be useful to incorporate AZDO
ideas from OpenGL into WebGL through extensions. As well, SPIR-V
support has been mentioned on this mailing list before and could be a
useful addition. It looks as though async support is starting to be
added through extensions (i.e. WEBGL_get_buffer_sub_data_async). Each
of these concepts could contribute to WebGL performance improvements,
however the extent of these improvements is unclear (i.e. relative to
a new API).

I am interested in the community's thoughts on this approach and
viewpoints on the future of WebGL in general (especially with respect
to the proposed WebGPU). I have also been wondering whether
OpenGL/OpenGL ES have considered future changes in this direction. If
anyone has any insight into this, it may be useful to consider.

Josh

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