4 ms·

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 mobil

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
        modern cards are migrating to a model where CPU and GPU have have direct access to the same memory region with zero copy Hmm, looking at the Metal docs, that's not quite how I read it! Here's Apple's "best practices" doc (https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/MTLBestPracticesGuide/TripleBuffering.html#//apple_ref/doc/uid/TP40016642-CH5-SW1 https://developer.apple.com/library/content/documentation/3D...): "Dynamic buffer data is typically written by the CPU and read by the GPU. An access conflict occurs if these operations happen at the same time; [...] For the processors to work in parallel, the CPU should be working at least one frame ahead of the GPU. This solution requires multiple instances of dynamic buffer data" It's still zero copy, but they're not literally peeking and poking the same buffer at the same time. So WebGL "just" needs to offer zero-copy access to buffers from JavaScript. That seems at least possible...? TypedArray would be the key component, and that already exists. Whether all those pieces have been put together in the right order yet, I dunno. Anyway, low-overhead access to the GPU from JavaScript seems possible in principle.
        pjmlp 10y ago
        Well, modern graphic cards and Apple devices don't go hand in hand on the same sentence. https://developer.amd.com/wordpress/media/2013/06/1004_final.pdf https://developer.amd.com/wordpress/media/2013/06/1004_final... > It's still zero copy, but they're not literally peeking and poking the same buffer at the same time. Hence why I mentioned some synchronization is needed.
      - 10y ago

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
      modern cards are migrating to a model where CPU and GPU have have direct access to the same memory region with zero copy Hmm, looking at the Metal docs, that's not quite how I read it! Here's Apple's "best practices" doc (https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/MTLBestPracticesGuide/TripleBuffering.html#//apple_ref/doc/uid/TP40016642-CH5-SW1 https://developer.apple.com/library/content/documentation/3D...): "Dynamic buffer data is typically written by the CPU and read by the GPU. An access conflict occurs if these operations happen at the same time; [...] For the processors to work in parallel, the CPU should be working at least one frame ahead of the GPU. This solution requires multiple instances of dynamic buffer data" It's still zero copy, but they're not literally peeking and poking the same buffer at the same time. So WebGL "just" needs to offer zero-copy access to buffers from JavaScript. That seems at least possible...? TypedArray would be the key component, and that already exists. Whether all those pieces have been put together in the right order yet, I dunno. Anyway, low-overhead access to the GPU from JavaScript seems possible in principle.
      - pjmlp 10y ago
        Well, modern graphic cards and Apple devices don't go hand in hand on the same sentence. https://developer.amd.com/wordpress/media/2013/06/1004_final.pdf https://developer.amd.com/wordpress/media/2013/06/1004_final... > It's still zero copy, but they're not literally peeking and poking the same buffer at the same time. Hence why I mentioned some synchronization is needed.
    - 10y ago