4 ms·

why should it NOT be fragmented? We don't use one OS. We don't use one programming language. We don't use one assembly language. We don't have one CPU design. W

why should it NOT be fragmented? We don't use one OS. We don't use one programming language. We don't use one assembly language. We don't have one CPU design. Why would we have one GPU API?

pjc50 6y ago
We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. Fragmentation isn't stable; the largest fragment tends to expand to dominate the market.
- coldtea 6y ago
  >We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. And we get the joy of Electron...
- dindresto 6y ago
  Fortunately, WebGPU is on the horizon to fix this mess. And before someone links the relevant XKCD comic, I'll do it myself: https://xkcd.com/927/ https://xkcd.com/927/
  - pjmlp 6y ago
    Given the adoption rate of WebGL 2.0 (including the issues with blacklisting drivers), the current state of WebGL 2.0 compute, I don't have high hopes for a 3D API where the shading language is yet to be defined.
    - dindresto 6y ago
      Well, (un)fortunately WebGL 2.0 adoption is mainly blocked by Apple. And as Apple is one of the driving forces behind WebGPU, I expect it to be adopted by Safari faster.
      - flohofwoe 6y ago
        Current Safari Technology Preview on Mac actually has a working WebGL2 implementation that's pretty much complete (maybe apart from a few minor issues that need fixing before the switch can be flipped). The whole thing got rebooted quite recently (AFAIK with the help from Google developers), to integrate ANGLE into Safari instead of a 'from-scratch' implementation.
        dindresto 6y ago
        Ah that's awesome to hear!
- pjmlp 6y ago
  > huge effort is expended in polyfilling over the differences. That is the problem right there. Hence now we have ChromeOS as the Web, just give Chrome a couple more years with the current trend. And OSes adopting the Linux ABI, or even running it virtualized, instead of caring for POSIX compatibility.
  - pjc50 6y ago
    Isn't that more of a "solution" than a problem? If you want to write an app that runs across different platforms, you have to put an abstraction layer in somewhere. If it's inside your app, it's a maintenance headache. If it's outside, then that becomes the platform you're targeting. > adopting the Linux ABI, or even running it virtualized, instead of caring for POSIX compatibility. So what happens when you want to use a feature that's not in pure POSIX? I remember that quite a lot of the ugliness and insecurity of the original OpenSSL code was attributed to having #ifdefs all over the place to deal with weird and eventually dead systems.

why should it NOT be fragmented? We don't use one OS. We don't use one programming language. We don't use one assembly language. We don't have one CPU design. Why would we have one GPU API?

pjc50 6y ago

We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. Fragmentation isn't stable; the largest fragment tends to expand to dominate the market.

coldtea 6y ago
>We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. And we get the joy of Electron...
dindresto 6y ago
Fortunately, WebGPU is on the horizon to fix this mess. And before someone links the relevant XKCD comic, I'll do it myself: https://xkcd.com/927/ https://xkcd.com/927/
- pjmlp 6y ago
  Given the adoption rate of WebGL 2.0 (including the issues with blacklisting drivers), the current state of WebGL 2.0 compute, I don't have high hopes for a 3D API where the shading language is yet to be defined.
  - dindresto 6y ago
    Well, (un)fortunately WebGL 2.0 adoption is mainly blocked by Apple. And as Apple is one of the driving forces behind WebGPU, I expect it to be adopted by Safari faster.
    - flohofwoe 6y ago
      Current Safari Technology Preview on Mac actually has a working WebGL2 implementation that's pretty much complete (maybe apart from a few minor issues that need fixing before the switch can be flipped). The whole thing got rebooted quite recently (AFAIK with the help from Google developers), to integrate ANGLE into Safari instead of a 'from-scratch' implementation.
      - dindresto 6y ago
        Ah that's awesome to hear!
pjmlp 6y ago
> huge effort is expended in polyfilling over the differences. That is the problem right there. Hence now we have ChromeOS as the Web, just give Chrome a couple more years with the current trend. And OSes adopting the Linux ABI, or even running it virtualized, instead of caring for POSIX compatibility.
- pjc50 6y ago
  Isn't that more of a "solution" than a problem? If you want to write an app that runs across different platforms, you have to put an abstraction layer in somewhere. If it's inside your app, it's a maintenance headache. If it's outside, then that becomes the platform you're targeting. > adopting the Linux ABI, or even running it virtualized, instead of caring for POSIX compatibility. So what happens when you want to use a feature that's not in pure POSIX? I remember that quite a lot of the ugliness and insecurity of the original OpenSSL code was attributed to having #ifdefs all over the place to deal with weird and eventually dead systems.