3 ms·

Why? It's pretty close to the Vulcan API why is Web GPU stuck in 2015 as you claim? Also Web GPU isn't just the browser didn't you read the article?

flohofwoe 3y ago
Vulkan is moving away from the extreme "everything is baked into immutable objects" philosophy of Vulkan 1.0 (see: [1], [2], [3], [4] - although these extension swing the pendulum back too much to the granular OpenGL API model, which also sucks), while WebGPU will be stuck with the "rigid model" for quite a while and even adds more rigidness (for instance baking shader resource bindings into immutable BindGroup objects). WebGPU still has a nice balance between convenience and a somewhat modern feature set, but going down to the native platform 3D APIs (Metal, D3D12 and Vulkan) will always offer a much bigger feature set and less CPU overhead (mainly because WebGPU also needs to support mobile GPUs, and some of those are indeed 10 years behind the curve). [1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [2] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state2.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [3] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state3.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [4] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_vertex_input_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man...
pjmlp 3y ago
Because 2015 hardware is the baseline for the MVP 1.0. WebGPU outside of the browser doesn't really matter, middleware engines already cover that, and with much better tooling. Besides WebGPU outside of the browser cannot deviate from the WebGPU on the browser, otherwise it is exactly the same pain as porting between OpenGL ES, OpenGL and WebGL, API that are only compatible in name.

flohofwoe 3y ago

Vulkan is moving away from the extreme "everything is baked into immutable objects" philosophy of Vulkan 1.0 (see: [1], [2], [3], [4] - although these extension swing the pendulum back too much to the granular OpenGL API model, which also sucks), while WebGPU will be stuck with the "rigid model" for quite a while and even adds more rigidness (for instance baking shader resource bindings into immutable BindGroup objects). WebGPU still has a nice balance between convenience and a somewhat modern feature set, but going down to the native platform 3D APIs (Metal, D3D12 and Vulkan) will always offer a much bigger feature set and less CPU overhead (mainly because WebGPU also needs to support mobile GPUs, and some of those are indeed 10 years behind the curve). [1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [2] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state2.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [3] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state3.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [4] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_vertex_input_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man...

pjmlp 3y ago

Because 2015 hardware is the baseline for the MVP 1.0. WebGPU outside of the browser doesn't really matter, middleware engines already cover that, and with much better tooling. Besides WebGPU outside of the browser cannot deviate from the WebGPU on the browser, otherwise it is exactly the same pain as porting between OpenGL ES, OpenGL and WebGL, API that are only compatible in name.