4 ms·

GPU drivers are insane complicated beasts. While doing my advanced graphics, OpenGL with my nvidia card has locked my machine many times. WebGL propagates that

by nojvek 8y ago

GPU drivers are insane complicated beasts. While doing my advanced graphics, OpenGL with my nvidia card has locked my machine many times. WebGL propagates that. There’s nothing chrome can do, since those webgl calls are essentially proxies to the GPU which is also used to display the rest of OS Most GPUs don’t have a strong sandbox, and things blow up.

tambourine_man 8y ago
Sure, but I mean, exposing almost raw GPU calls to the open web is… nuts. There must be a less powerful, safer subset.
- seanmcdirmid 8y ago
  Pixel and vertex and other shaders that run on the GPU are....mostly benign. They can’t be used to take down a computer unless there is a bug in the hardware or graphics card driver, the latter being very common unfortunately. Shader language is pretty simple, there is no way to really subset it. The only safe alternative is not executing user provided shader code on the GPU, but that just means making it completely unavailable.
- kevingadd 8y ago
  Earlier versions of WebGL were less powerful, but that made it hard to do anything useful with them. So now, we have this. Vendors are busy adding a Vulkan-style web API now so we'll have even more fun
- chrismorgan 8y ago
  Browsers do a lot of blacklisting of drivers with known problems. Things are slowly improving, especially as browsers themselves, especially Firefox, steadily do more GPU stuff (putting pressure on the driver makers to fix things), but there’s a reason why it’s been very rare for non-game UIs to target GPUs for rendering: GPU drivers are atrocious. Even if they don’t crash, the number of absolutely fundamental and critical bugs that they have is very impressive. As an example of a fundamental thing being broken, try https://github.com/tomaka/winit/pull/332#issuecomment-341383016 https://github.com/tomaka/winit/pull/332#issuecomment-341383... and later on down in the thread where a driver update fixed it.
  - chrismorgan 8y ago
    (Actually, I misrecalled the cited example: the driver update fixed that bug, but introduced another far worse one.)
  - 43920 8y ago
    The list of driver issues that Mozilla has run into while developing webrender is also impressively long: https://github.com/servo/webrender/wiki/Driver-issues https://github.com/servo/webrender/wiki/Driver-issues
  - frankchn 8y ago
    As another example, here is the long list of blacklisted drivers and cards in Chrome: https://cs.chromium.org/chromium/src/gpu/config/software_rendering_list.json https://cs.chromium.org/chromium/src/gpu/config/software_ren...
- tokyodude 8y ago
  There is no useful subset that doesn't have the same problem (see my longer response). We did an investigation back when making O3D (before WebGL) if there was a smaller subset that was both performant and didn't have the issue. The answer was no. It does not require shaders to trigger the GPU issue mentioned in my other comment and there's no performant way to check if geometry submitted to some fixed pipeline is going to trigger the "too long" issue or not.

by nojvek 8y ago

tambourine_man 8y ago

Sure, but I mean, exposing almost raw GPU calls to the open web is… nuts. There must be a less powerful, safer subset.

seanmcdirmid 8y ago
Pixel and vertex and other shaders that run on the GPU are....mostly benign. They can’t be used to take down a computer unless there is a bug in the hardware or graphics card driver, the latter being very common unfortunately. Shader language is pretty simple, there is no way to really subset it. The only safe alternative is not executing user provided shader code on the GPU, but that just means making it completely unavailable.
kevingadd 8y ago
Earlier versions of WebGL were less powerful, but that made it hard to do anything useful with them. So now, we have this. Vendors are busy adding a Vulkan-style web API now so we'll have even more fun
chrismorgan 8y ago
Browsers do a lot of blacklisting of drivers with known problems. Things are slowly improving, especially as browsers themselves, especially Firefox, steadily do more GPU stuff (putting pressure on the driver makers to fix things), but there’s a reason why it’s been very rare for non-game UIs to target GPUs for rendering: GPU drivers are atrocious. Even if they don’t crash, the number of absolutely fundamental and critical bugs that they have is very impressive. As an example of a fundamental thing being broken, try https://github.com/tomaka/winit/pull/332#issuecomment-341383016 https://github.com/tomaka/winit/pull/332#issuecomment-341383... and later on down in the thread where a driver update fixed it.
- chrismorgan 8y ago
  (Actually, I misrecalled the cited example: the driver update fixed that bug, but introduced another far worse one.)
- 43920 8y ago
  The list of driver issues that Mozilla has run into while developing webrender is also impressively long: https://github.com/servo/webrender/wiki/Driver-issues https://github.com/servo/webrender/wiki/Driver-issues
- frankchn 8y ago
  As another example, here is the long list of blacklisted drivers and cards in Chrome: https://cs.chromium.org/chromium/src/gpu/config/software_rendering_list.json https://cs.chromium.org/chromium/src/gpu/config/software_ren...
tokyodude 8y ago
There is no useful subset that doesn't have the same problem (see my longer response). We did an investigation back when making O3D (before WebGL) if there was a smaller subset that was both performant and didn't have the issue. The answer was no. It does not require shaders to trigger the GPU issue mentioned in my other comment and there's no performant way to check if geometry submitted to some fixed pipeline is going to trigger the "too long" issue or not.