Hacker News new | past | comments | ask | show | jobs | submit login

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.

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.

You’re right, but it’s not by design, it’s just a little buggy and a lot complicated. There are still easy ways to lock a browser up with CPU code too. It’s harder to crash the OS, but it does happen.

There also shouldn’t be ways to crash the internet or a large scale redundant network service like the ones Google & Amazon have set up with a single microservice or database corruption or flaky cache or router, yet cascading failures are happening all the time and getting long post analysis write-ups featured on HN, even.

The main thing that’s “wrong” is complexity, but it’s also here to stay, there’s no going back, there’s just tightening up the sandboxes and hardening the APIs. GPU resource management is still a bit more raw than what the OS & CPU have, but it’s steadily improving every year. And aside from crashing sometimes, browsers have become very careful about GPU sandboxing for privacy.

In short, it has only gotten better over time, it won’t be long before a webpage really can’t crash the OS just by using the GPU.

If you need the GPU within the browser, then the user should be asking why?

Why should they should provide such expensive resources to any third party?

If you're doing any kind of graphics work, the GPU is actually the less "expensive resource" as it will do it faster and more efficiently.

Any kind of <canvas> work, graphs/charts, browser games, animations, and video all will perform better with some GPU assistance. The alternative is run everything on a CPU and get a more limited experience and have your CPU maxed out to 100% a lot more.

That’s a strange framing, I’m not sure I understand what you mean. The reason for WebGL is much faster graphics for me, I don’t ask why because I want GPU in the browser. Which third party are you talking about? What does the expense of a component have to do with anything? If you’re assuming a malicious GPU computation done without the user’s intent, maybe state that assumption, but that’s not what the parent thread was talking about. I’m certain that if GPU abuse were to become a thing, the browsers will immediately deny default access and request user permission, just like with audio. In the mean time, you can currently turn off GPU access in your browser settings if you’re afraid of something.

The context here is the GPU js library, which is a general purpose computing using the GPU.

Does this actually build on top of WebGL?

Yes, GPU.js is built on top of WebGL. So this exposes no new functionality, only new convenience. And yes, the context is GPU.js, general purpose compute for the GPU. That doesn't mean you're "providing" resources to any third party, right? The primary reason to want general purpose GPU compute in the browser are the same as the reasons to want GPU graphics - to make my own experience faster.

Thanks for clarifying.

The security risks of WebGL has been discussed for years, so as concerning as it is that's not what I'm interested in.

If you as the developer of a web application need the power of a GPU, then aside from graphics my question is why?

The power draw of GPUs isn't trivial and the vast majority of browsers are hand-held devices.

Aside from minimalist sites like hacker news, websites already drain my phone's battery very quickly.

If it's meant for desktops, then to what end?

I guess there's two different topics in there.

First, I agree completely that the web has insane amounts of bloat relative to the size of the content you request. Most people here would agree; frameworks and ads and analytics are crazy. This is true, but irrelevant to GPU.js.

Second, GPGPU applications numerous. There are several listed here in the comments and on the GPU.js site, e.g., ray tracing, matrix multiplication. A really obvious one for HN would be neural network traing and/or inference, or any other optimization technique. It's useful for physics sims, video editing, and image processing. Here's a longer list: https://en.wikipedia.org/wiki/General-purpose_computing_on_g...

That's not to mention that it's just fun in the spirit of hacking to figure out how to use your systems in weird ways. The cool part about GPU.js is the GPU access with transparent CPU fallback - you get to write GPU-CPU agnostic code in javascript. It's neat that they implemented in javascript a way to cross compile javascript to a shader.

You're right that the power draw of a GPU isn't trivial, but the watts per megaflop is lower than CPU, for well-crafted highly parallel compute applications, even on mobile devices. I don't imagine using GPU.js on a phone, my personal assumption is that GPU.js is mostly meant for developers playing around on desktops right now. The benchmark specs on the GPU.js page describe a desktop system.

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.

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

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-341383... and later on down in the thread where a driver update fixed it.

As another example, here is the long list of blacklisted drivers and cards in Chrome: https://cs.chromium.org/chromium/src/gpu/config/software_ren...

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

(Actually, I misrecalled the cited example: the driver update fixed that bug, but introduced another far worse one.)

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.

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.

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

Blame Apple. They have the worst graphics stack when it comes to stuff like this.

Most GPUs are not pre-emptable (maybe that's changing?). Because they are not pre-emptable if you give them something to do they will do it until finished. There is no interrupting them, saving state, switching to something else like with a CPU.

Microsoft realized this and so Microsoft built into the OS a timeout. If the GPU is given something to do and doesn't come back in a few seconds then they reset the GPU (like shut the power off and turn it back on, or rather send a PCI reset). You need to be aware of this in Windows programming if you have data you need on the GPU. Most games don't and can just re-upload their data if told their data was ejected but some GPGPU calculation will at least get told "sorry, GPU reset, start over"

Apple didn't implement anything like that in OSX (now MacOS) for the longest time. The entire OS is built around the idea that all apps are well behaved (LOL). If a single app gives the GPU 30minutes of work to then the GPU is going to do 30 minutes of work and your option was only hold the power button.

They tried retrofitting in a timeout but AFAICT there's just too many parts of the OS that expect no one will ever hog the GPU and it filters back to CPU land when the CPU tries to do something (queue drawing some windows) and the GPU doesn't respond for .5 a second, 1 second, 20 seconds, etc and stuff piles up etc...

Linux had (has?) exactly the same problem. I don't know how much progress has been made on either MacOS nor Linux to deal with this.

Now comes WebGL which you guys won't like but basically any page can give your GPU something that takes a few minutes to run and your machine (if it's not Windows) may crash. The mitigating factor is it doesn't help the bad guys. It's not like they can steal your info. The most they can do is convince you never to visit their site again so it's a mostly self correcting problem. The hard spots are if the person making the site was targeting a top end GPU and you visit with a low-end GPU.

There are really only 2 real solutions. The OSes need to handle the fact that GPUs are non-preemptable or we need preemptable GPUs.

Some will argue get rid of WebGL. I'd argue the issue is mostly self correcting and that Google Maps is pretty awesome and it gets that awesomeness from being able to render with the GPU. There's plenty of other 2D and 3D visualizations WebGL enables. So I'm happy to live with the self correcting problem for the benefits while I wait for pre-emptable GPUs for the real fix.

This is actually one place where I'm surprised there are cloud GPUs since they'd have the same issue. I've never used one but they must have some way of being reset. They must also not be shared? Or you just have to accept that some other process on the machine can completely hog the machine.

>Linux had (has?) exactly the same problem. I don't know how much progress has been made on either MacOS nor Linux to deal with this.

All my AMD GPUs have been issued GPU resets for years. I know that in 2013 my Radeon 5870 (the card I had at the time) was issued soft resets, which was logged in dmesg as a success. The problem with that is that whatever program caused the GPU lockup would continue to run (unless it crashes, which is frequently the case) until the kernel had reset the GPU so many times, the only option left is a hard reset.

On Windows, the way GPU lockups are dealt with is also by resetting the GPU, and it's the same there too, if it keeps locking up several times within a certain time span the kernel panics and you either get a BSOD or a complete system lockup.

wouldn't cloud providers just bill you to death if you hogged their machines?

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.

Well, you could load random kernel extensions you find on the internet…

That's the spirit.

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.

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."

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.

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.

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.


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.

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

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.

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...

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.

> 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.

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

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)

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

Worked ok on my iPhone Xs.

GPU is x105 the speed of CPU according to this benchmark.

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.

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.

I am aware of that. I suspect Safari somehow manages to consistently get more GPU priority than Safari-based Chrome.


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

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact