- From: Stephen White <steve@adam.com.au>
- Date: Thu, 6 Jul 2017 15:35:33 +0930
- To: Kenneth Russell <kbr@google.com>
- Cc: public-gpu@w3.org
On 6 Jul 2017, at 12:35 pm, Kenneth Russell <kbr@google.com> wrote: > Steve, which Github issue are you referring to? Could you please post a link? Hi Ken, It was this one... as you can see, I was raising the idea and accepted it being closed: https://github.com/gpuweb/gpuweb/issues/20 The idea was that a breaking change could come with a parse script to update old code. It could be applied at runtime to try and keep older code working, or be used to update existing code. > It's true that some of WebGL's API signatures changed early on, in incompatible ways. This was problematic because WebGL 1.0 was enabled by default in browsers under the "experimental-webgl" context type. Since then, browser implementers have chosen a better staged rollout plan for new APIs – only enabling them by default when multiple browsers are passing conformance tests. If the gpuweb implementations follow this convention, then early adopters will still be able to try things out, but the backward compatibility guarantee won't be enforced until everyone's ready to provide it. I’m thinking more about keeping as much code working as possible while getting to that first declaration of backwards compatibility. It was a bit painful in WebGL days to have a range of webpages with old code with various levels of being broken, even though it’s been very good since the declaration of the 1.0 APIs. On a different topic, from reading the minutes it appears that WebGPU is going in a significantly different direction than WebGL. Instead of defining a 1 to 1 mapping to existing OpenGL ES, the effort seems to be in creating a new universal layer to span from Metal to Direct. Yet this is what a cross platform graphics API would do. I was expecting WebGPU to be a 1 to 1 mapping to Vulkan, which is tackling the same cross-platform challenges, and any kind of retro-fitting would be the same as the auto-conversion of WebGL to DirectX (primarily because of very poor native drivers for OpenGL on Windows). Would it be best to stick to Vulkan? My primary interest is in the intersection of WebAssembler and WebGPU, as otherwise Javascript and WebGL (with WebVR) does the job for me. So I’m happy if these ideas are quickly dismissed as I don’t have the depth or insight into the problem space, unless I have accidentally highlighted an issue. Steve. -- steve@adam.com.au
Received on Thursday, 6 July 2017 06:06:10 UTC