3 ms·

I have been wondering why WebGL isn't getting updated to ES 3.1 (and 3.2). Good to see at least 3.1 parity is coming: https://www.khronos.org/registry/webgl/spe

I have been wondering why WebGL isn't getting updated to ES 3.1 (and 3.2). Good to see at least 3.1 parity is coming: https://www.khronos.org/registry/webgl/specs/latest/2.0-compute/ https://www.khronos.org/registry/webgl/specs/latest/2.0-comp... (I didn't know it was on the horizon until I saw your link). I wonder if getting to ES 3.2 is on the horizon as well? That would bring geometry and tessellation shader support.

Jasper_ 7y ago
I refer to the Mali Performance Guide for wisdom into Geometry Shaders: https://static.docs.arm.com/100019/0100/arm_mali_application_developer_best_practices_developer_guide_100019_0100_00_en2.pdf#page=19 https://static.docs.arm.com/100019/0100/arm_mali_application... > Using geometry shading will generally lead to worse performance, high memory bandwidth, and increased system power consumption. Assert if geometry shaders are used Geometry shaders are not what you want. They should not have been included in GL ES, and I will fight their inclusion into WebGL 2.1. Tessellation shaders are better, but still kinda ultimately useless.
- planteen 7y ago
  Yes, I agree the performance is an issue in most use cases, but wouldn't you agree there is value in there being parity between WebGL and OpenGL ES? It's valuable for those of us who work with Emscripten to cross-compile apps for the web. And there are things like line drawing algorithms that have uses for geometry shaders: https://github.com/paulhoux/Cinder-Samples/tree/master/GeometryShader https://github.com/paulhoux/Cinder-Samples/tree/master/Geome... It's not like geometry shaders are specific to OpenGL ES. Desktop OpenGL has them, as does DirectX and Vulkan.