5 ms·

Anything that's not based on the Vulkan spec is just a land-grab by Apple to push their own technologies. As someone who spends a lot of time in that space I d

Anything that's not based on the Vulkan spec is just a land-grab by Apple to push their own technologies. As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway.

droithomme 10y ago
Yeah,what is wrong with WebGL anyway? It seems to work pretty well.
- corysama 10y ago
  WebGL is pretty great. But, like GLES, it requires a lot of API calls to get stuff done. Hopefully, with a Vulkan-like API, you should be able to move a whole lot of that work to initialization time and make the act of actually drawing stuff frame-by-frame require very little API activity. In the extreme case you get stuff like "GPU-Driven Rendering Pipelines" described in http://advances.realtimerendering.com/s2015/ http://advances.realtimerendering.com/s2015/
- sydd 10y ago
  lots of things: - Implementing OpenGL drivers is very complicated, this leads to huge drivers full of bugs and performance issues. Just look at something like this: https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/ https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and... - OpenGL's state machine logic is outdated and horrible to debug. We need something more modern. Basically its carrying cruft from the last ~20 years. - It can be very slow compared to Vulkan/Metal/DX 12. - It doesnt allow modern features like GPGPU. this would allow is to truely use the GPU for computing stuff (e.g. AI, novel shaders, new graphics pipelines etc.)
JoshTriplett 10y ago
> As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway. Not true at all; if your primary performance bottleneck is the GPU code, not CPU code, you could use a better web API modeled after Vulkan, for the same reason people switch from GL to Vulkan. In general, if there's ever something where people feel they "have to" use native instead of web, that needs fixing in the web platform.
- vvanders 10y ago
  As soon as you clear up that GPU bottleneck guess what's going to be your next one? (Here's a hint, it's the thing that's dispatching to your GPU). Another aspect that scares me about this is the security implications of exposing compute to the browser. Esp when you start talking about unified memory architectures. There's been more than a few exploits from a clever soul calling glReadPixels in the right circumstances. Increasing the surface area here doesn't seem like a great idea. Shader compilers are also great targets for instability and obscure bugs.
  - JoshTriplett 10y ago
    > As soon as you clear up that GPU bottleneck guess what's going to be your next one? Memory bandwidth for your textures, geometry, and other data, quite often. Or nothing at all, if you can successfully reach your desired target framerate. But if CPU turns out to be an issue, that's what WebAssembly is for.
    - vvanders 10y ago
      > Memory bandwidth for your textures, geometry, and other data, quite often. So in other words a GPU bottleneck?
      - JoshTriplett 10y ago
        No, a memory bottleneck. (That may be GPU memory or system memory, depending on the architecture of your graphics stack.) That's not the same as a GPU processing bottleneck. You can have a bottleneck in GPU processing, or a bottleneck in getting enough data to the GPU.
        vvanders 10y ago
        Oh I see, we're getting pedantic over semantics. If your GPU is designed with a small bus between system and GPU memory, that's still a GPU issue. You could make the same argument on the CPU side for caches and DRAM if you want to go that far. I appreciate the education lesson but I think you'll find most graphics programmers will consider it a GPU problem :). At the end of the day though here's the thing. The intersection of users that have a GPU capable of discrete pipelines, compute shaders and all the other things that make this interesting but won't go through the effort of installing a native app is relatively small. You can't polyfill(otherwise why use the GPU in the first place?) on the users don't have a cutting edge machine so you're going to have a swath of people that your WebApp won't work for. From a value proposition it just doesn't make sense.
pcwalton 10y ago
> As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway. As someone who also spends a lot of time in the GPU space, I really want something newer than WebGL. WebGL is not good enough.
- vvanders 10y ago
  There's plenty of stuff if you want to go native or are you just talking web technologies? FWIW there's tons of things build on OpenGL ES 2(all of Android for instance). If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc).
  - pcwalton 10y ago
    > If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc). You say that like it's a good thing! The point of WebGL is to put that pain on the browser vendor. OpenGL ES 2 is incredibly limited, as you know. Yeah, you can do a lot with it, but there's a ton of stuff you can't do (tessellation, compute, image load/store, heck, even unbounded loops in shaders). Why should the Web be limited to that?
    - vvanders 10y ago
      I definitely wasn't saying it was a good thing, just the reality in the graphics space. I just don't see how you push it to the web. You're forcing device capabilites onto users and the web always lags well behind what's happening in the native domain.
      - pcwalton 10y ago
        I don't understand what you're arguing. > You're forcing device capabilites onto users I guess this is an argument about portability? That's an argument against WebGL at all, not about WebGL 2. Besides, WebGL 2 is targeting an API that's 7 years old at this point. A seven-year-old API is not exactly bleeding edge. > the web always lags well behind what's happening in the native domain Again, you say that as if it were a good thing! It's not! That's what this is trying to fix!

droithomme 10y ago

Yeah,what is wrong with WebGL anyway? It seems to work pretty well.

corysama 10y ago
WebGL is pretty great. But, like GLES, it requires a lot of API calls to get stuff done. Hopefully, with a Vulkan-like API, you should be able to move a whole lot of that work to initialization time and make the act of actually drawing stuff frame-by-frame require very little API activity. In the extreme case you get stuff like "GPU-Driven Rendering Pipelines" described in http://advances.realtimerendering.com/s2015/ http://advances.realtimerendering.com/s2015/
sydd 10y ago
lots of things: - Implementing OpenGL drivers is very complicated, this leads to huge drivers full of bugs and performance issues. Just look at something like this: https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/ https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and... - OpenGL's state machine logic is outdated and horrible to debug. We need something more modern. Basically its carrying cruft from the last ~20 years. - It can be very slow compared to Vulkan/Metal/DX 12. - It doesnt allow modern features like GPGPU. this would allow is to truely use the GPU for computing stuff (e.g. AI, novel shaders, new graphics pipelines etc.)

JoshTriplett 10y ago

> As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway. Not true at all; if your primary performance bottleneck is the GPU code, not CPU code, you could use a better web API modeled after Vulkan, for the same reason people switch from GL to Vulkan. In general, if there's ever something where people feel they "have to" use native instead of web, that needs fixing in the web platform.

vvanders 10y ago
As soon as you clear up that GPU bottleneck guess what's going to be your next one? (Here's a hint, it's the thing that's dispatching to your GPU). Another aspect that scares me about this is the security implications of exposing compute to the browser. Esp when you start talking about unified memory architectures. There's been more than a few exploits from a clever soul calling glReadPixels in the right circumstances. Increasing the surface area here doesn't seem like a great idea. Shader compilers are also great targets for instability and obscure bugs.
- JoshTriplett 10y ago
  > As soon as you clear up that GPU bottleneck guess what's going to be your next one? Memory bandwidth for your textures, geometry, and other data, quite often. Or nothing at all, if you can successfully reach your desired target framerate. But if CPU turns out to be an issue, that's what WebAssembly is for.
  - vvanders 10y ago
    > Memory bandwidth for your textures, geometry, and other data, quite often. So in other words a GPU bottleneck?
    - JoshTriplett 10y ago
      No, a memory bottleneck. (That may be GPU memory or system memory, depending on the architecture of your graphics stack.) That's not the same as a GPU processing bottleneck. You can have a bottleneck in GPU processing, or a bottleneck in getting enough data to the GPU.
      - vvanders 10y ago
        Oh I see, we're getting pedantic over semantics. If your GPU is designed with a small bus between system and GPU memory, that's still a GPU issue. You could make the same argument on the CPU side for caches and DRAM if you want to go that far. I appreciate the education lesson but I think you'll find most graphics programmers will consider it a GPU problem :). At the end of the day though here's the thing. The intersection of users that have a GPU capable of discrete pipelines, compute shaders and all the other things that make this interesting but won't go through the effort of installing a native app is relatively small. You can't polyfill(otherwise why use the GPU in the first place?) on the users don't have a cutting edge machine so you're going to have a swath of people that your WebApp won't work for. From a value proposition it just doesn't make sense.

pcwalton 10y ago

vvanders 10y ago
There's plenty of stuff if you want to go native or are you just talking web technologies? FWIW there's tons of things build on OpenGL ES 2(all of Android for instance). If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc).
- pcwalton 10y ago
  > If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc). You say that like it's a good thing! The point of WebGL is to put that pain on the browser vendor. OpenGL ES 2 is incredibly limited, as you know. Yeah, you can do a lot with it, but there's a ton of stuff you can't do (tessellation, compute, image load/store, heck, even unbounded loops in shaders). Why should the Web be limited to that?
  - vvanders 10y ago
    I definitely wasn't saying it was a good thing, just the reality in the graphics space. I just don't see how you push it to the web. You're forcing device capabilites onto users and the web always lags well behind what's happening in the native domain.
    - pcwalton 10y ago
      I don't understand what you're arguing. > You're forcing device capabilites onto users I guess this is an argument about portability? That's an argument against WebGL at all, not about WebGL 2. Besides, WebGL 2 is targeting an API that's 7 years old at this point. A seven-year-old API is not exactly bleeding edge. > the web always lags well behind what's happening in the native domain Again, you say that as if it were a good thing! It's not! That's what this is trying to fix!