8 ms·

Warning: this hard locked my MBP. More detail after I’m back at my machine. Edit: System details Retina Mid-2015 15" - MJLT2LL/A - MacBookPro11,5 - A1398 - 29

Warning: this hard locked my MBP. More detail after I’m back at my machine. Edit: System details Retina Mid-2015 15" - MJLT2LL/A - MacBookPro11,5 - A1398 - 2910 Firefox 65.0.1 (64-bit) The hang occurred when running the benchmark with Texture Mode enabled. The spinning gear froze after a few seconds, then the display went black and the fan was maxed. It was a pain in the ass to recover: my only option seemed to be to power down and power back up again, at which point OSX helpfully remembered the state my machine was in and dropped me back into the blacked-out display and maxed fan. Some combination of NVRAM reset, SPC reset and safe mode was required to get back in.

doctorpangloss 8y ago
As an MBP user, it's kind of funny the most dangerous thing I can do with my crazy expensive computer is use 100% of its resources in a sandbox.
- saagarjha 8y ago
  Well, you could load random kernel extensions you find on the internet…
  - WrtCdEvrydy 8y ago
    That's the spirit.
diroussel 8y ago
Worked ok on my iPhone Xs. GPU is x105 the speed of CPU according to this benchmark.
- coolspot 8y ago
  3-6 times faster on my iPhone X in the Chrome in texture mode, 1.2 times faster in default mode. 11 times faster in default mode in Safari, 5.5 times in texture mode. Results above are for battery-powered device, but repeating tests with charger plugged in didn't help to Chrome, but improved result for Safari up to 60 times. It looks like results vary significantly from time to time.
  - Wowfunhappy 8y ago
    Chrome on iOS is just a UI around Safari's rendering engine, per Apple rules. I'm going to hazard a guess you were just seeing normal variation between tests.
    - coolspot 8y ago
      I am aware of that. I suspect Safari somehow manages to consistently get more GPU priority than Safari-based Chrome. ¯\_(ツ)_/¯
yread 8y ago
I've recently hard blocked my windows machine by trying to be smart with a filters on a complex svg. Can happen
saagarjha 8y ago
Worked fine on my MacBook Pro (Retina, 13-inch, Early 2015)–apparently the GPU was 367.95x faster. Might be something with your discrete graphics card, or your use of Firefox? Edit: works fine for me in Firefox Nightly.
onion2k 8y ago
It locked up a tab on my unbelievably-low-spec Acer Chromebook 11, but eventually came back to life to tell me it's 5.53 times faster than the CPU.
parhamn 8y ago
Same. MBP2018/FF65. Hard reboot needed to get back up. Interestingly when it soft-crashed FF had a dangling process which wouldn't let it me open the app again (~"Only one FF can be running"). Guess I was well overdue for a reboot anyway...
ontologiae 8y ago
Same. MPB 2012/FF65 Not the first time I notice that macOS has a lot of troubles with big IOs (disk, network, and now GPU)
milancurcic 8y ago
Same on Ubuntu 18.10, Firefox 65.0.1 (64-bit) on NVIDIA Quadro P400.
aylmao 8y ago
Worked fine for me. - macOS 10.14.3 (18D109) - MacBook Pro 15-inch 2017 (Intel HD Graphics 630 1536 MB + Radeon Pro 555 2048 MB) - Chrome 72.0.3626.96 (Official Build) (64-bit) The page definitely got more choppy with Texture Mode enabled (guessing the perf delta is higher, so they run a more intensive test to get significant results. I'd test on Firefox, but currently at work, so I don't want to risk it haha. FireFox 65 seems to be the common denominator I see for these crashes.
masswerk 8y ago
The benchmark in "Texture Mode" just shot my system as well. (Older MacPro, Firefox 65.0.1) No visual response anymore / hard system reset required. This is why computing on the GPU with code loaded by a web page isn't a good idea.
- EForEndeavour 8y ago
  It's amazing how quickly my attitude toward the idea of GPU-accelerated JavaScript flipped from "awesome idea, let's check out the comments!" to "how about no."
  - AstralStorm 8y ago
    Idea is great, GPU OSes (called firmware to disguise complexity) are about as good as Windows 95 but much more complex. No virtualization yet, very little memory safety, expected use case is single big task.
microcolonel 8y ago
> my MBP In my experience, Apple's OpenGL drivers are incredibly unstable. On Windows I'll often see incorrect results, but generally the drivers have not crashed for normal inputs. When I've run my (admittedly kinda avant-garde) shaders on iOS and OSX devices, there's a good chance that the whole system will halt at some point. I honestly don't know how they have problems like this.
- davedx 8y ago
  Mine too. My Macbook Pro has a discrete GPU but using it for gaming results in all kinds of weird behaviour
tambourine_man 8y ago
This is nuts. There’s no way a webpage (or app for that matter) should be able to crash an entire OS. Something's gone very wrong with ours software.
- 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.
rolleiflex 8y ago
I ran this test on an iPhone 7 with a battery health at 99%. It made the battery drop 3% in about 30 seconds. I don’t know what else it is, but it is a great DDoS tool for batteries.
- Tade0 8y ago
  *iPhones They seem to have the highest computing power to battery size ratio among mobile devices in general. One one hand it's great because they're powerful, on the other this here happens. Around Christmas there was this sand game which was really neat, but sucked my SO's battery dry in moments going a stable 40fps. My Galaxy S8 ran it slower and choppier, but considerably longer.
globuous 8y ago
same on my gentoo with FF and nvidia proprietary drivers. A simple reboot was enough though

doctorpangloss 8y ago

As an MBP user, it's kind of funny the most dangerous thing I can do with my crazy expensive computer is use 100% of its resources in a sandbox.

saagarjha 8y ago
Well, you could load random kernel extensions you find on the internet…
- WrtCdEvrydy 8y ago
  That's the spirit.

diroussel 8y ago

Worked ok on my iPhone Xs. GPU is x105 the speed of CPU according to this benchmark.

coolspot 8y ago
3-6 times faster on my iPhone X in the Chrome in texture mode, 1.2 times faster in default mode. 11 times faster in default mode in Safari, 5.5 times in texture mode. Results above are for battery-powered device, but repeating tests with charger plugged in didn't help to Chrome, but improved result for Safari up to 60 times. It looks like results vary significantly from time to time.
- Wowfunhappy 8y ago
  Chrome on iOS is just a UI around Safari's rendering engine, per Apple rules. I'm going to hazard a guess you were just seeing normal variation between tests.
  - coolspot 8y ago
    I am aware of that. I suspect Safari somehow manages to consistently get more GPU priority than Safari-based Chrome. ¯\_(ツ)_/¯

yread 8y ago

I've recently hard blocked my windows machine by trying to be smart with a filters on a complex svg. Can happen

saagarjha 8y ago

Worked fine on my MacBook Pro (Retina, 13-inch, Early 2015)–apparently the GPU was 367.95x faster. Might be something with your discrete graphics card, or your use of Firefox? Edit: works fine for me in Firefox Nightly.

onion2k 8y ago

It locked up a tab on my unbelievably-low-spec Acer Chromebook 11, but eventually came back to life to tell me it's 5.53 times faster than the CPU.

parhamn 8y ago

Same. MBP2018/FF65. Hard reboot needed to get back up. Interestingly when it soft-crashed FF had a dangling process which wouldn't let it me open the app again (~"Only one FF can be running"). Guess I was well overdue for a reboot anyway...

ontologiae 8y ago

Same. MPB 2012/FF65 Not the first time I notice that macOS has a lot of troubles with big IOs (disk, network, and now GPU)

milancurcic 8y ago

Same on Ubuntu 18.10, Firefox 65.0.1 (64-bit) on NVIDIA Quadro P400.

aylmao 8y ago

Worked fine for me. - macOS 10.14.3 (18D109) - MacBook Pro 15-inch 2017 (Intel HD Graphics 630 1536 MB + Radeon Pro 555 2048 MB) - Chrome 72.0.3626.96 (Official Build) (64-bit) The page definitely got more choppy with Texture Mode enabled (guessing the perf delta is higher, so they run a more intensive test to get significant results. I'd test on Firefox, but currently at work, so I don't want to risk it haha. FireFox 65 seems to be the common denominator I see for these crashes.

masswerk 8y ago

The benchmark in "Texture Mode" just shot my system as well. (Older MacPro, Firefox 65.0.1) No visual response anymore / hard system reset required. This is why computing on the GPU with code loaded by a web page isn't a good idea.

EForEndeavour 8y ago
It's amazing how quickly my attitude toward the idea of GPU-accelerated JavaScript flipped from "awesome idea, let's check out the comments!" to "how about no."
- AstralStorm 8y ago
  Idea is great, GPU OSes (called firmware to disguise complexity) are about as good as Windows 95 but much more complex. No virtualization yet, very little memory safety, expected use case is single big task.

microcolonel 8y ago

> my MBP In my experience, Apple's OpenGL drivers are incredibly unstable. On Windows I'll often see incorrect results, but generally the drivers have not crashed for normal inputs. When I've run my (admittedly kinda avant-garde) shaders on iOS and OSX devices, there's a good chance that the whole system will halt at some point. I honestly don't know how they have problems like this.

davedx 8y ago
Mine too. My Macbook Pro has a discrete GPU but using it for gaming results in all kinds of weird behaviour

tambourine_man 8y ago

This is nuts. There’s no way a webpage (or app for that matter) should be able to crash an entire OS. Something's gone very wrong with ours software.

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.

rolleiflex 8y ago

I ran this test on an iPhone 7 with a battery health at 99%. It made the battery drop 3% in about 30 seconds. I don’t know what else it is, but it is a great DDoS tool for batteries.

Tade0 8y ago
*iPhones They seem to have the highest computing power to battery size ratio among mobile devices in general. One one hand it's great because they're powerful, on the other this here happens. Around Christmas there was this sand game which was really neat, but sucked my SO's battery dry in moments going a stable 40fps. My Galaxy S8 ran it slower and choppier, but considerably longer.

globuous 8y ago

same on my gentoo with FF and nvidia proprietary drivers. A simple reboot was enough though