4 ms·

According to webglstats.com WebGL is supported on 96% of browsers/devices. I wonder what is a maximum possible coverage to be achieved by WebGL2 with current ha

According to webglstats.com WebGL is supported on 96% of browsers/devices. I wonder what is a maximum possible coverage to be achieved by WebGL2 with current hardware (If I understand correctly some WebGL capable devices will never be able to support WebGL2 due to hardware limitations).

pjmlp 10y ago
WebGL 2.0 requires OpenGL ES 3.0 capable hardware, plus that browser vendors don't black list drivers/GPUs. I have a few OpenGL ES 3.x devices that Chrome doesn't like, but native games don't have any problem taking full advantage of the GPU. EDIT: forgot the version
aedron 10y ago
I would love to start using it, but most WebGL content I try to view fails (some error message that it is not supported). This is true on the last three (different) computers I have used (all some recent Windows/Chrome combination). Sometimes it can be enabled via some flag, but that is useless for real world solutions.
overgard 10y ago
On PC it's probably no difference. WebGL 1 is a really low baseline -- its based on an ES spec from 2007. ES3/webGL2 isn't super cutting edge. In terms of mobile I dont think webgl is that useful anyway (too much overhead), but pretty much every high end device newer than 2013 should support it.
- iainmerrick 10y ago
  Too much overhead? Can you go into more detail? Part of the point of OpenGL is to offload as much computation as possible to the GPU. There's a lot of very cool stuff you can do with barely any CPU usage at all, so even if you're using JavaScript it shouldn't make much difference. (High-end games still need a lot of CPU power too, of course)
  - overgard 10y ago
    Well, two things. First off, because it has to be safe in the browser, there's no direct memory access. Which means if you need to dynamically write CPU data to buffers WebGL is going to add a lot of overhead. The trend with newer APIs (DX12/Metal/Vulcan) the last few years has been direct access to avoid API overhead, and it's unlikely the browser+javascript will allow for that kind of memory usage (since it's unsafe). So that's one limitation that's unlikely to be addressed. There are other limitations, like for example, Windows has no native OpenGL ES support, and so all your API calls get translated to DirectX9 (via ANGLE in chrome and firefox), so now you're actually going through two APIs. Another consideration is that, excluding pure viewers, you're likely to be doing a lot of other expensive calculations in a 3d scene and javascript is poorly suited to that kind of work.
    - iainmerrick 10y ago
      The trend with newer APIs (DX12/Metal/Vulcan) the last few years has been direct access to avoid API overhead Hmm, is that really true? I haven't used those latest APIs yet! I thought good practice was still to keep the data on the GPU as much as possible, and avoid fine-grained sharing with the CPU. There's plenty you can do with static data. I agree that JS/WebGL is not quite there yet for big-name games, but it's surely pretty close. And asm.js and eventually WebAssembly can help claw back CPU performance. Rather than technical concerns, as a game developer I'm more concerned by the fact that nobody is willing to pay for anything on the web. If and when WebGL goes mainstream for games, it'll be even more of an ad-encrusted "freemium" race to the bottom than the various mobile app stores already are.
      - pjmlp 10y ago
        Yes, modern cards are migrating to a model where CPU and GPU have have direct access to the same memory region with zero copy. Of course you need to synchronize access.
        iainmerrick 10y ago
        I guess that's something WebAssembly could in principle handle efficiently, but not for a while.
iainmerrick 10y ago
On Android, around 60% of devices support OpenGL ES 3.0 (https://developer.android.com/about/dashboards/index.html#OpenGL https://developer.android.com/about/dashboards/index.html#Op...). I assume they will all support WebGL 2 too.
- pjmlp 10y ago
  It depends on Google. They tend to black list GPUs due to graphic issues and we all know how often those drivers get updated. With native code you get to work around driver bugs. With WebGL you need to guide your users how to manually white list the GPU and still don't have control all it is given to the driver, meaning it can still fail.

pjmlp 10y ago

WebGL 2.0 requires OpenGL ES 3.0 capable hardware, plus that browser vendors don't black list drivers/GPUs. I have a few OpenGL ES 3.x devices that Chrome doesn't like, but native games don't have any problem taking full advantage of the GPU. EDIT: forgot the version

aedron 10y ago

I would love to start using it, but most WebGL content I try to view fails (some error message that it is not supported). This is true on the last three (different) computers I have used (all some recent Windows/Chrome combination). Sometimes it can be enabled via some flag, but that is useless for real world solutions.

overgard 10y ago

On PC it's probably no difference. WebGL 1 is a really low baseline -- its based on an ES spec from 2007. ES3/webGL2 isn't super cutting edge. In terms of mobile I dont think webgl is that useful anyway (too much overhead), but pretty much every high end device newer than 2013 should support it.

iainmerrick 10y ago
Too much overhead? Can you go into more detail? Part of the point of OpenGL is to offload as much computation as possible to the GPU. There's a lot of very cool stuff you can do with barely any CPU usage at all, so even if you're using JavaScript it shouldn't make much difference. (High-end games still need a lot of CPU power too, of course)
- overgard 10y ago
  Well, two things. First off, because it has to be safe in the browser, there's no direct memory access. Which means if you need to dynamically write CPU data to buffers WebGL is going to add a lot of overhead. The trend with newer APIs (DX12/Metal/Vulcan) the last few years has been direct access to avoid API overhead, and it's unlikely the browser+javascript will allow for that kind of memory usage (since it's unsafe). So that's one limitation that's unlikely to be addressed. There are other limitations, like for example, Windows has no native OpenGL ES support, and so all your API calls get translated to DirectX9 (via ANGLE in chrome and firefox), so now you're actually going through two APIs. Another consideration is that, excluding pure viewers, you're likely to be doing a lot of other expensive calculations in a 3d scene and javascript is poorly suited to that kind of work.
  - iainmerrick 10y ago
    The trend with newer APIs (DX12/Metal/Vulcan) the last few years has been direct access to avoid API overhead Hmm, is that really true? I haven't used those latest APIs yet! I thought good practice was still to keep the data on the GPU as much as possible, and avoid fine-grained sharing with the CPU. There's plenty you can do with static data. I agree that JS/WebGL is not quite there yet for big-name games, but it's surely pretty close. And asm.js and eventually WebAssembly can help claw back CPU performance. Rather than technical concerns, as a game developer I'm more concerned by the fact that nobody is willing to pay for anything on the web. If and when WebGL goes mainstream for games, it'll be even more of an ad-encrusted "freemium" race to the bottom than the various mobile app stores already are.
    - pjmlp 10y ago
      Yes, modern cards are migrating to a model where CPU and GPU have have direct access to the same memory region with zero copy. Of course you need to synchronize access.
      - iainmerrick 10y ago
        I guess that's something WebAssembly could in principle handle efficiently, but not for a while.

iainmerrick 10y ago

On Android, around 60% of devices support OpenGL ES 3.0 (https://developer.android.com/about/dashboards/index.html#OpenGL https://developer.android.com/about/dashboards/index.html#Op...). I assume they will all support WebGL 2 too.

pjmlp 10y ago
It depends on Google. They tend to black list GPUs due to graphic issues and we all know how often those drivers get updated. With native code you get to work around driver bugs. With WebGL you need to guide your users how to manually white list the GPU and still don't have control all it is given to the driver, meaning it can still fail.