It may be time to revisit the 3D graphics and cross-computing platform, Vulkan, shows promise vs the current supported OpenCL (WebGl), DirectX, and Metal by allowing better CPU and GPU management.
This is especially important for rendering libraries which are not CPU or GPU locked and can benefit from such an approach. Vulkan also has lower memory overhead in comparison to these other libraries, allowing direct writes to the video display device, without the need for CPU intervention; better thread management and faster context switching; as well as optimal shader management via pre-compilation.
I'm very confused how this post is relevant. First, when did we previously "visit" Vulkan, but second, it's up to engines to implement ecma262 if they wish.
What changes would you expect in ecma262 for this?
1 Like
If you agree their workflow and memory management architecture would benefit us then... reach out to them and express how we've extended and expanded our specification towards an interest in a partnership- mutually beneficial to the future of both endeavours etc.
I don't understand how it would benefit the language itself at all.
1 Like
A new graphics API for web has been under development for quite some time. It's called WebGPU:
WebGPU supports different backends: Vulkan on Linux, DX12 on Windows and Metal on OSX/iOS. This API takes into account all the specifics of the architecture of new modern GPUs and differs fundamentally from WebGL.
Nightly builds of Chrome, FF and Safari already support it. See examples:
https://austin-eng.com/webgpu-samples/samples/helloTriangle
also recent article in web.dev:
2 Likes
MaxGraey absolutely right. Also Spir-V supported in Chrome (Canary) but this feature not works in other browsers. The problem that Safari refused to implement it (here you can find discussion Raw WebGPU | Hacker News) so WebGPU is some kind of trade off that guarantee easy conversion from from it. Look at WGSL goals section in spec WebGPU Shading Language